Hi
Yest this is e-mails body from test - only when sender domain have SPF
set ~all or SPF not exist
W dniu 8.01.2024 o 15:08, Damian via Postfix-users pisze:
SMUGGLING WORKS with '\r\n\x00.\r\n' as "fake" end-of-data sequence!
SMUGGLING WORKS with '\r.\r\n' as "fake" end-of-data sequence!
SMUG
SMUGGLING WORKS with '\r\n\x00.\r\n' as "fake" end-of-data sequence!
SMUGGLING WORKS with '\r.\r\n' as "fake" end-of-data sequence!
SMUGGLING WORKS with '\r.\r' as "fake" end-of-data sequence!
SMUGGLING WORKS with '\r.\n' as "fake" end-of-data sequence!
Are those really standalone emails with subj
I'm running on Ubuntu 22 which ships postfix 3.6.4 .
I've tried the short term solution, but this test tool still can send forged
emails:
$ postconf -n | grep -E "smtpd_data_restrictions|smtpd_discard_ehlo_keywords"
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_discard_ehlo_keywords
W dniu 8.01.2024 o 13:35, Damian via Postfix-users pisze:
I create test VPS (outside my infrastructure) and install all for
python3 for testing
root@hanz:~# python3 smtp_smuggling_scanner.py --sender-domain
gmail.com piot...@mydomain.ltd
Don't use a sender-domain you don't have control over. T
I create test VPS (outside my infrastructure) and install all for
python3 for testing
root@hanz:~# python3 smtp_smuggling_scanner.py --sender-domain
gmail.com piot...@mydomain.ltd
Don't use a sender-domain you don't have control over. The default
should be good enough for basic smuggling tests
Hi
Sorry for stupid question but I dont realy undarstand
I create test VPS (outside my infrastructure) and install all for
python3 for testing
root@hanz:~# python3 smtp_smuggling_scanner.py --sender-domain gmail.com
piot...@mydomain.ltd
[*] Getting MX record for domain: xx
[*] Running SMTP
On Sat, Jan 06, 2024 at 20:10:34 -0500, Wietse Venema via Postfix-users wrote:
> People are welcome to test tools against postfix-3.9-20240106.
With postfix-3.9-20240106 (with smtpd_forbid_bare_newline=yes but
smtpd_forbid_unauth_pipelining=no) all smuggling tests now fail,
including CRCRL tests.
People are welcome to test tools against postfix-3.9-20240106.
I could test against a 3.7.9 codebase if you posted a patch for it.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.o
People are welcome to test tools against postfix-3.9-20240106.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
On Sat, Jan 06, 2024 at 14:47:59 -0500, Wietse Venema via Postfix-users wrote:
> Damian:
> > If I remember correctly, on the wire there was \r\n\r\n.\r\r\n
>
> Viktor Dukhovni:
> > Does that also need to be more strict? :-(
>
> Indeed, and as usual the fix is trivial. This process is backwards,
Damian:
> If I remember correctly, on the wire there was \r\n\r\n.\r\r\n
Viktor Dukhovni:
> Does that also need to be more strict? :-(
Indeed, and as usual the fix is trivial. This process is backwards,
it is what we get with publication before the analysis, tooling,
and software fixes are compl
On 6 Jan 2024, at 12:04 pm, Damian via Postfix-users
wrote:
>
> If I remember correctly, on the wire there was \r\n\r\n.\r\r\n
>
> I will assemble a pcap and some logs when I'm back home.
That's expected, Postfix will accept one *or more* CRs before LF as CRLF.
https://github.com/vdukhovn
If I remember correctly, on the wire there was \r\n\r\n.\r\r\n
I will assemble a pcap and some logs when I'm back home.
> In other words, I need to see proff in the form of a PCAP file and
> NON-VERBOSE logging, or it did not happen.
___
Postfix-users
BTW All smuggling tests are invalid when the client is allowlisted
with smtpd_forbid_bare_newline_exclusions (default: $mynetworks).
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-
Wietse Venema via Postfix-users:
> Damian via Postfix-users:
> > > The recommended settings are:
> > >
> > >
Damian via Postfix-users:
> > The recommended settings are:
> >
> >
> >
smuggling for the `\r\n.\n` case.
Sorry, that was a bad copypaste, I meant '\r\n.\r'.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
The test tool [1] revealed that my 3.7.9 Postfix using `smtpd_forbid_bare_newline = yes` admits smuggling for the `\r\n.\n` case.
One still needs `smtpd_data_restrictions = reject_unauth_pipelining` to close that one as well.
After a small adaptation to the tool to use BDAT one can see what Wiet
On 2024-01-04 at 11:15:17 UTC-0500 (Thu, 4 Jan 2024 17:15:17 +0100)
Geert Hendrickx via Postfix-users
is rumored to have said:
My point was not about SMTP smuggling, but about potentially revealing
DISCARD rules to the outside world (since they cause later rules to be
skipped entirely). Eg. a
Geert Hendrickx via Postfix-users:
> On Thu, Jan 04, 2024 at 10:36:23 -0500, Wietse Venema via Postfix-users wrote:
> > Wietse Venema via Postfix-users:
> > > Geert Hendrickx via Postfix-users:
> > > > I just found an unexpected side effect of this particular configuration
> > > > (unrelated to SMT
On Thu, Jan 04, 2024 at 10:36:23 -0500, Wietse Venema via Postfix-users wrote:
> Wietse Venema via Postfix-users:
> > Geert Hendrickx via Postfix-users:
> > > I just found an unexpected side effect of this particular configuration
> > > (unrelated to SMTP smuggling).
> > >
> > > [...] Or stated d
Wietse Venema via Postfix-users:
> Geert Hendrickx via Postfix-users:
> > On Thu, Dec 21, 2023 at 07:51:31 -0500, Wietse Venema via Postfix-users
> > wrote:
> > > * With all Postfix versions, "smtpd_data_restrictions =
> > > reject_unauth_pipelining" will stop the published exploit.
> >
> >
Geert Hendrickx via Postfix-users:
> On Thu, Dec 21, 2023 at 07:51:31 -0500, Wietse Venema via Postfix-users wrote:
> > * With all Postfix versions, "smtpd_data_restrictions =
> > reject_unauth_pipelining" will stop the published exploit.
>
>
> Hi
>
> I just found an unexpected side effect
On Thu, Dec 21, 2023 at 07:51:31 -0500, Wietse Venema via Postfix-users wrote:
> * With all Postfix versions, "smtpd_data_restrictions =
> reject_unauth_pipelining" will stop the published exploit.
Hi
I just found an unexpected side effect of this particular configuration
(unrelated to SMT
On Sat, 2023-12-30 at 16:14 +, Scott Kitterman via Postfix-users
wrote:
>
>
> On December 30, 2023 3:17:52 PM UTC, "Håkon Alstadheim via Postfix-
> users" wrote:
> > Just FYI, I got postfix 3.7.9-0+deb12u1 from bookworm-updates (i.e.
> > Debian) today.
> >
> For those still using Debian Bul
Am 30.12.23 um 18:42 schrieb Mike via Postfix-users:
On 12/30/2023 12:08 PM, Wietse Venema via Postfix-users wrote:
"Hakon Alstadheim wrote:
Just FYI, I got postfix 3.7.9-0+deb12u1 from bookworm-updates (i.e.
Debian) today.
Scott Kitterman:
For those still using Debian Bullseye (oldstable), p
On 12/30/2023 12:08 PM, Wietse Venema via Postfix-users wrote:
> "Hakon Alstadheim wrote:
>> Just FYI, I got postfix 3.7.9-0+deb12u1 from bookworm-updates (i.e.
>> Debian) today.
>
> Scott Kitterman:
>> For those still using Debian Bullseye (oldstable), postfix
>> 3.5.23-0+deb11u1 is also availabl
"Hakon Alstadheim wrote:
>Just FYI, I got postfix 3.7.9-0+deb12u1 from bookworm-updates (i.e.
>Debian) today.
Scott Kitterman:
> For those still using Debian Bullseye (oldstable), postfix
> 3.5.23-0+deb11u1 is also available from bullseye-updates. Both
> of these stable updates were released yest
On December 30, 2023 3:17:52 PM UTC, "Håkon Alstadheim via Postfix-users"
wrote:
>Just FYI, I got postfix 3.7.9-0+deb12u1 from bookworm-updates (i.e. Debian)
>today.
>
For those still using Debian Bullseye (oldstable), postfix 3.5.23-0+deb11u1 is
also available from bullseye-updates. Both of
Just FYI, I got postfix 3.7.9-0+deb12u1 from bookworm-updates (i.e.
Debian) today.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
On Fri, Dec 29, 2023 at 10:16:20AM +0100, natan via Postfix-users wrote:
> Hi
> In postfix-3.4.23 (debian) I set
>
> (I use always)
> smtpd_data_restrictions = reject_unauth_pipelining
>
> And today I put
> smtpd_discard_ehlo_keywords = chunking
>
>
> And I get many many logs like:
> ...
> Dec
Hi
In postfix-3.4.23 (debian) I set
(I use always)
smtpd_data_restrictions = reject_unauth_pipelining
And today I put
smtpd_discard_ehlo_keywords = chunking
And I get many many logs like:
...
Dec 29 10:10:13 msmtp postfix/submission/smtpd[11064]: discarding EHLO
keywords: CHUNKING
Dec 29 10:1
In the past, I have had messages coming in (via port 25) claiming to be
Helpdesk, Personnel, etc
So I had incorporated into my sender_access file the line:-
cidercounty.org.uk permit_sasl_authenticated, reject
Do you think something like this would be beneficial WRT the smuggling probl
Damian via Postfix-users:
> > It really does not matter much, but leaving BDAT enabled can help in
> > some cases. It is not necessary to go this deep down the rabbit hole.
>
> So what could be smuggled into a Postfix that defines
> "reject_unauth_pipelining" but does not define
> "smtpd_discard_
It really does not matter much, but leaving BDAT enabled can help in
some cases. It is not necessary to go this deep down the rabbit hole.
So what could be smuggled into a Postfix that defines "reject_unauth_pipelining" but does not define "smtpd_discard_ehlo_keywords
= chunking"?
__
On Wed, Dec 27, 2023 at 11:40:56PM +0100, Damian via Postfix-users wrote:
> > The attack can be mitigated by using BDAT.
>
> Can someone clarify?
It really does not matter much, but leaving BDAT enabled can help in
some cases. It is not necessary to go this deep down the rabbit hole.
If both t
SHORT-TERM WORKAROUNDS
A short-term workaround can be deployed now, before the upcoming long
holiday and associated production change freeze.
NOTE: This will stop only the published form of the attack. Other forms
exist that will not be stopped in this manner.
* With all Postfix versions, "s
Pedro David Marco:
> To my understanding, the Smuggled email contains SMTP data plus
> headers, plus body... , so what is the problem if filters check
> them as well?
Wietse:
> The problem is that Postfix receives TWO messages.
> https://www.postfix.org/smtp-smuggling.html#impact
Pedro David Marc
Thanks Wietse, yes it is clear in your doc, but both messages go through
filter?? despite what the MAIL FROM is?
Thanks,
Pedro.
On Tuesday, December 26, 2023 at 03:34:34 PM GMT+1, Wietse Venema via
Postfix-users wrote:
Pedro David Marco via Postfix-users:
> To my understanding, the Sm
Pedro David Marco via Postfix-users:
> To my understanding, the Smuggled email contains SMTP data plus
> headers, plus body... , so what is the problem if filters check
> them as well?
The problem is that Postfix receives TWO messages.
https://www.postfix.org/smtp-smuggling.html#impact
W
Geert Hendrickx via Postfix-users:
> On Sat, Dec 23, 2023 at 18:09:10 -0500, Wietse Venema via Postfix-users wrote:
> > Note that only the encapsulating message can contain a DKIM signature
> > by the authenticated sender's domain. The smuggled message caannot
> > contain a DKIM signature by the im
On Sat, Dec 23, 2023 at 18:09:10 -0500, Wietse Venema via Postfix-users wrote:
> Note that only the encapsulating message can contain a DKIM signature
> by the authenticated sender's domain. The smuggled message caannot
> contain a DKIM signature by the impersonated sender's domain unless
> the att
John D'Orazio via Postfix-users:
> I believe some users are in fact confusing DMARC and DKIM. DMARC is a
> policy that lets receiving servers know how to deal with mail that seems to
> be coming from your server but has *not* passed SPF and DKIM checks. From
> the Google support forum:
>
> DMARC (
I believe some users are in fact confusing DMARC and DKIM. DMARC is a
policy that lets receiving servers know how to deal with mail that seems to
be coming from your server but has *not* passed SPF and DKIM checks. From
the Google support forum:
DMARC (Domain-based Message Authentication, Reportin
Bill Sommerfeld via Postfix-users:
> On 12/22/23 17:30, Vijay S Sarvepalli via Postfix-users wrote:
> > Arguably the second server is at fault
> > here for "SPF" signing two emails, nevertheless the vulnerability is due
> > to the combinatorial or Composition Attack as Wietse has identified.
>
On 12/22/23 17:30, Vijay S Sarvepalli via Postfix-users wrote:
Arguably the second server is at fault
here for “SPF” signing two emails, nevertheless the vulnerability is due
to the combinatorial or Composition Attack as Wietse has identified.
SPF does not involve any per-message signatures.
Tim Weber via Postfix-users:
> I think this is a very good way to look at it, and a helpful lesson
> from this situation. Especially since, reading the article as it
> was published, it is obvious that SEC must have known the impact
> to Postfix and Sendmail. I understand their urge to notify Cisco
11:48:56 AM
To: Vijay S Sarvepalli ; Postfix users
Subject: [pfx] Re: SMTP Smuggling disclosure process & VINCE
Warning: External Sender - do not click links or open attachments unless you
recognize the sender and know the content is safe.
Hi Vijay,
thank you very much for this deta
Hi Vijay,
thank you very much for this detailed explanation. I found it especially useful
to learn about CERT/CC's workflow, since people like me, who are neither
security researchers nor maintainers of well-known software projects, have
little insight into this. While I was able to reach VINCE
(or how much bigger the research
had become) and potentially delayed the disclosure to give Vendors more time.
Thanks
Vijay
From: Wietse Venema via Postfix-users
Date: Friday, December 22, 2023 at 7:57 PM
To: Postfix users
Subject: [pfx] Re: SMTP Smuggling disclosure process & VINCE
Wietse Venema via Postfix-users:
> Wietse Venema via Postfix-users:
> > Tim Weber via Postfix-users:
> > > Hi Wietse,
> > >
> > > thanks for getting back to me so quickly. Please rest assured that
> > > I'm not looking for someone to blame. My motivation is to try to
> > > find out whether SEC's r
Wietse Venema via Postfix-users:
> Tim Weber via Postfix-users:
> > Hi Wietse,
> >
> > thanks for getting back to me so quickly. Please rest assured that
> > I'm not looking for someone to blame. My motivation is to try to
> > find out whether SEC's release process really has been as responsible
>
Tim Weber via Postfix-users:
> Hi Wietse,
>
> thanks for getting back to me so quickly. Please rest assured that
> I'm not looking for someone to blame. My motivation is to try to
> find out whether SEC's release process really has been as responsible
> as they claim:
Sorry, you are talking to th
Hi Wietse,
thanks for getting back to me so quickly. Please rest assured that I'm not
looking for someone to blame. My motivation is to try to find out whether SEC's
release process really has been as responsible as they claim:
> We strictly adhere to our responsible disclosure processes
> (ht
We had no indication thet there was a succesful spoofing attack
that required the composition of TWO servers with specific differences
in their handling of non-standard line endings in SMTP.
Otherwise, we would certainly have convinced SEC Consult to change
their time schedule until after people h
[Reposted, as I din't see the response show up]
CERT/CC reached out to Postfix developers. At no point were we made
aware that there was a successful SPF spoofing attack that required
the combination of TWO email services with SPECIFIC DIFFERENCES in
the way they handle line endings other than .
Till W. via Postfix-users:
[ Charset ISO-8859-1 converted... ]
> Dear team,
> we enabled smtpd_forbid_unauth_pipelining in our Postfix, but unfortunately
> it still accepts \n.\n (.) as EOD. This is our configuration in
> main.cf:
>
> smtpd_forbid_unauth_pipelining = yes
> smtpd_discard_ehlo_key
Till W. via Postfix-users:
> Dear team,
> we enabled smtpd_forbid_unauth_pipelining in our Postfix, but unfortunately
> it still accepts \n.\n (.) as EOD. This is our configuration in
> main.cf:
>
Of course it does. It is supposed to reject message content that is
received IN THE SAME PACKET as
still possible to use: 'MESSAGE 1\n.\n' as EOD.
Thanks in advance for any feedback.
Best regards
Till Wigger
Von: Carsten Rosenberg via Postfix-users
Gesendet: Donnerstag, 21. Dezember 2023 11:04
An: postfix-users@postfix.org
Betreff: [pfx] Re: SMTP
Hey,
it seems you're still offering
250-PIPELINING
Both options work as exspected on my side (Postfix 3.7.6).
best regards
Carsten
On 21.12.23 10:29, Till W. via Postfix-users wrote:
Dear team,
we enabled smtpd_forbid_unauth_pipelining in our Postfix, but
unfortunately it still accepts \
Phil Biggs via Postfix-users:
> Thursday, December 21, 2023, 10:05:41 AM, Wietse Venema via Postfix-users
> wrote:
>
> > Viktor Dukhovni via Postfix-users:
> >> smtpd_data_restrictions=reject_unauth_pipelining.
>
> > That will, as Viktor observes, on port 25 mitigate the published attack.
>
>
Thursday, December 21, 2023, 10:05:41 AM, Wietse Venema via Postfix-users
wrote:
> Viktor Dukhovni via Postfix-users:
>> smtpd_data_restrictions=reject_unauth_pipelining.
> That will, as Viktor observes, on port 25 mitigate the published attack.
Will postscreen's opportunistically enabled pipe
Viktor Dukhovni via Postfix-users:
> smtpd_data_restrictions=reject_unauth_pipelining.
That will, as Viktor observes, on port 25 mitigate the published attack.
I'll update the text at https://www.postfix.org/smtp-smuggling.html
Wietse
___
Postf
On Wed, Dec 20, 2023 at 05:48:43PM -0500, Wietse Venema via Postfix-users wrote:
> Wietse Venema via Postfix-users:
> > As part of a non-responsible disclosure process, SEC Consult has
> > published an email spoofing attack that involves a composition of
> > different mail service behaviors with r
Wietse Venema via Postfix-users:
> As part of a non-responsible disclosure process, SEC Consult has
> published an email spoofing attack that involves a composition of
> different mail service behaviors with respect to broken line endings.
Also on-line at httpps://www.postfix.org/smtp-smuggling.ht
On Wed, Dec 20, 2023 at 09:12:47PM +0100, John D'Orazio via Postfix-devel wrote:
> I recently encountered on a server of my own a case of SMTP smuggling.
I am very sceptical that this is in fact the case. Which is to say,
very confident it is not.
> I was befuddled by the fact that I received a
Thanks, Bill. That did it. :)
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
I assumed it should be in main.cf. I meant which section. I tried to
redefine it in smtpd_helo_restrictions since that seemed reasonable.
Running postconf shows it, as you say set to no but I cannot set it to yes.
--
Dave Stiles
Linkcheck Bristol Web Design
Tel: 0117 9248413
https://www.bristolw
Linkcheck via Postfix-users:
> On 20/12/2023 3:51 pm, Wietse Venema via Postfix-users wrote:
> > "smtpd_forbid_unauth_pipelining = yes
>
> I tried that (3.7.6) and got...
> warning: unknown smtpd restriction: "smtpd_forbid_unauth_pipelining"
>
> Where should I have placed it?
Ask your vendor. Th
On 20/12/2023 3:51 pm, Wietse Venema via Postfix-users wrote:
"smtpd_forbid_unauth_pipelining = yes
I tried that (3.7.6) and got...
warning: unknown smtpd restriction: "smtpd_forbid_unauth_pipelining"
Where should I have placed it?
___
Postfix-user
John Levine via Postfix-users:
> This paper describes a clever hack that uses defective line endings to embed
> a second SMTP session inside a first one, which has the practical effect
> of letting you send fake authenticated mail from anyone else who uses the
> same mail system you do. If that sy
71 matches
Mail list logo
