[pfx] Postfix using proxy protocol outbound?

[Joachim Lindenberg via Postfix-users]

I am running my postfix (mailcow) in my local network and interface to the 
outside via a VPN that is terminated on a VPS with a static address with 
adequate reputation. Historically I used NAT in both directions in- and 
outbound, but I switched to use proxy protocol inbound as I am in fact now 
using two VPS in parallel. Outbound I am still stuck with NAT, and thus limited 
to use IPv4. I looked at several NAT6 variants and also NDP proxy, and all look 
both complex and discouraged. 

Thus I am wondering whether it would be feasible to use proxy protocol outbound 
as well with postfix. Actually I am doing this with other services and I think 
it should be straightforward to add. Are you willing to consider that? Or is it 
already supported and I did overlook an option to use it?

I may have overlooked other options. However what I definitely don´t want to do 
is run a relay server on the VPS.

Thanks,

Joachim

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: mail in SRS-format in destination bypasses postfix rules

[Matus UHLAR - fantomas via Postfix-users]

On 17.12.23 23:12, Kristoff via Postfix-users wrote:
I don't know if this question has already been ask, but I did not find 
anything in the archive of the mailing-list.




I co-manage a postfix-server for an hobby-club. We provide 
email-addresses to our members, which are linked to aliases, so we 
forward the mails to the personal email-address of the member.


(The goal is to provide an email-address to the members, dedicated for 
the hobby, which helps to shield-of the personal email-address of the 
members).




Anycase, while looking into the log-files of postfix for another 
issue, I noticed this:


---
Dec 17 04:32:05 smtp postfix/smtp[725772]: 4F58E6A10A0: 
to=u...@example.com, 
orig_to=SRS0=zxmM=H4=example.com=u...@ourhobbyclubdomain.com, 
relay=mail.example.com[A.B.C.D]:25, delay=0.16, 
delays=0.05/0/0.08/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued 
as 714F7294BB2)

---
(personal information replaced for privacy-reason)
"u...@example.com" is just an email-address
"ourhobbyciubdomain.com" is the domain used by our organization.


So, it looks like somebody is sending use emails with a 
foreign-email-address-in-srs-for...@ourhobbyclubdomain.com as 
DESTINATION.
The net result seems to be that these mails are actually relayed by 
our server, although we normally have a rule that we only relay 
email-addresses of our members ("someu...@hobbyclubdomain.com")



I don't know if this is normal that the SRS is used in the destination 
address? ( "SRS" does mean "SENDER rewriting Sceme" doesn't it?)

What is the configuration to block this?


These may be spams to adress gathered from someone's mail, or maybe delivery 
notifications?


I guess you are reverse-rewriting those SRSed destination addresses using 
postsrs to original address of the sender.


You can redirect these messages to you as an admin in 
smtpd_recipient_restrictions
using regex matchin, so neither of those mails reach original recipient, but 
you as admin of ourhobbyclubdomain.com domain.


I did something similar but use plussed format SRS0+... and SRS1+..., so I redirected 
"SRS0" and "SRS1" address (plus is understood as address extension).


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Nothing is fool-proof to a talented fool.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix using proxy protocol outbound?

[Wietse Venema via Postfix-users]

Did you mean instead of

inside Postix -> outside Postfix -> remote MTAs in the Internet

Use

inside Postfix -reverse haproxy-> remote MTAs in the Internet

Theat is currently not implemented, and no design exists. 

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: mail in SRS-format in destination bypasses postfix rules

[Kristoff via Postfix-users]

Hi Matus,




Thanks.
Yes, I guess it are spam or phishing mails.

The trick with  "smtpd_recipient_restrictions" looks interesting. Thanks!



As I understand it now, there are three steps in this:

1/ the spammer sends us an email with destination 
"foreign-email-address-in-srs-for...@ourhobbyclubdomain.com"
As"outhobbyclubdomain.com" is mydestination, the email is accepted for 
relay.


2/ then the SRS-formated email-address is converted into a normal 
email-address


3/ Then the message is forwarded towards that address.
(instead of postfix doing a lookup for the alias, seeing it does not 
exist and refusing the message).




If step 2 would be done first (or simply not done on destination 
addresses), then this trick would be stopped.



I guess I am not the first person seeing this behaviour, I guess this is 
not a bug (as it would have been fixed a earlier), so I guess there must 
be a postfix configuration for this.


How do I influence this order, or stop step 2 being done on destination 
addresses?





Kr.




Op 18.12.23 om 12:15 schreef Matus UHLAR - fantomas via Postfix-users:

On 17.12.23 23:12, Kristoff via Postfix-users wrote:
I don't know if this question has already been ask, but I did not 
find anything in the archive of the mailing-list.




I co-manage a postfix-server for an hobby-club. We provide 
email-addresses to our members, which are linked to aliases, so we 
forward the mails to the personal email-address of the member.


(The goal is to provide an email-address to the members, dedicated 
for the hobby, which helps to shield-of the personal email-address of 
the members).




Anycase, while looking into the log-files of postfix for another 
issue, I noticed this:


---
Dec 17 04:32:05 smtp postfix/smtp[725772]: 4F58E6A10A0: 
to=u...@example.com, 
orig_to=SRS0=zxmM=H4=example.com=u...@ourhobbyclubdomain.com, 
relay=mail.example.com[A.B.C.D]:25, delay=0.16, 
delays=0.05/0/0.08/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued 
as 714F7294BB2)

---
(personal information replaced for privacy-reason)
"u...@example.com" is just an email-address
"ourhobbyciubdomain.com" is the domain used by our organization.


So, it looks like somebody is sending use emails with a 
foreign-email-address-in-srs-for...@ourhobbyclubdomain.com as 
DESTINATION.
The net result seems to be that these mails are actually relayed by 
our server, although we normally have a rule that we only relay 
email-addresses of our members ("someu...@hobbyclubdomain.com")



I don't know if this is normal that the SRS is used in the 
destination address? ( "SRS" does mean "SENDER rewriting Sceme" 
doesn't it?)

What is the configuration to block this?


These may be spams to adress gathered from someone's mail, or maybe 
delivery notifications?


I guess you are reverse-rewriting those SRSed destination addresses 
using postsrs to original address of the sender.


You can redirect these messages to you as an admin in 
smtpd_recipient_restrictions
using regex matchin, so neither of those mails reach original 
recipient, but you as admin of ourhobbyclubdomain.com domain.


I did something similar but use plussed format SRS0+... and SRS1+..., 
so I redirected "SRS0" and "SRS1" address (plus is understood as 
address extension).
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix using proxy protocol outbound?

[Joachim Lindenberg via Postfix-users]

Hello Wietse,
Yes, exactly, no second instance. Ok, implies I haven´t overlooked something. 
Is this an option you are willing to consider?
The key benefit to guys like me is that one doesn´t have to manage two 
instances, considering setup and maintenance, configuration (like tls 
policies), backup or just trust in your provider.
Thanks,
Joachim

-Ursprüngliche Nachricht-
Von: Wietse Venema via Postfix-users  
Gesendet: Montag, 18. Dezember 2023 13:31
An: Postfix users 
Betreff: [pfx] Re: Postfix using proxy protocol outbound?

Did you mean instead of

inside Postix -> outside Postfix -> remote MTAs in the Internet

Use

inside Postfix -reverse haproxy-> remote MTAs in the Internet

Theat is currently not implemented, and no design exists. 

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an 
email to postfix-users-le...@postfix.org

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: mail in SRS-format in destination bypasses postfix rules

[Matus UHLAR - fantomas via Postfix-users]

On 18.12.23 13:52, Kristoff via Postfix-users wrote:

Yes, I guess it are spam or phishing mails.

The trick with  "smtpd_recipient_restrictions" looks interesting. Thanks!

As I understand it now, there are three steps in this:

1/ the spammer sends us an email with destination 
"foreign-email-address-in-srs-for...@ourhobbyclubdomain.com"
As"outhobbyclubdomain.com" is mydestination, the email is accepted for 
relay.


2/ then the SRS-formated email-address is converted into a normal 
email-address


this is done by using recipient_canonical_maps on postfix which rewrites 
header/envelope recipient.



3/ Then the message is forwarded towards that address.
(instead of postfix doing a lookup for the alias, seeing it does not 
exist and refusing the message).


if you use recipient_canonical_maps, then the srs'ed adress is rewritten 
into original(remote) address, which is why the mail is relayed even if 
sender has no permission to relay



... I have just verified it works like this.
configured as documented on: https://github.com/roehling/postsrsd

note that postsrs keeps temporary address only working for certain amount 
of time (21 days), so those addresses aren't valid permanently.

- you seem to be using postsrs as well.


If step 2 would be done first (or simply not done on destination 
addresses), then this trick would be stopped.


I guess I am not the first person seeing this behaviour, I guess this 
is not a bug (as it would have been fixed a earlier), so I guess there 
must be a postfix configuration for this.


How do I influence this order, or stop step 2 being done on 
destination addresses?


you can disable recipient_canonical_maps, but that will block all mail 
to SRS'ed addresses, and anyone using address verification will block 
receiving srs-forwarded addresses because your MTA will say they do not 
exist.


Note that one of the point why SRS addresses exist is to validate the sender 
and to be able to know what forwarded address fails.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
2B|!2B, that's a question!
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix authenticated sender and From: header verification

[Vijay S Sarvepalli via Postfix-users]

Hello Viktor, Wietse,
(I am copying the Postfix community as the report is out in the public now)

First of all thank you for your help and response to highlight your approach to 
this issue.  This may not be the first time you have observed types of abuse 
that relate to spoofing.

This research work has now been published by Sec Consult company, see link 
below .  The Postfix issues the researcher mentions, we were not able to 
actually reproduce so we did not make a public statement as CERT/CC.  In our 
testing, we used the default Postfix Submission server with 
reject_authenticated_sender_login_mismatch
 and later added milterfrom to prevent Header From: and SMTP MAIL FROM: 
mismatch.  As far as we can tell any way to sneak past the 
reject_authenticated_sender_login_mismatch
 using the methods mentioned in the article did not succeed. It is possible 
specific Postfix configuration that the researcher found used by these major 
providers fails to validate these addresses for other reasons, as we do not 
know their configuration we cannot really comment.

https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

Anyway, if you find it necessary we can help and write up some best practices 
to prevent the claimed abuse, specifically for Postfix.  As this 
“vulnerability” falls between a specific product setup, CERT/CC has a little 
bit more trouble in trying to find a proper closure to a Coordinate 
Vulnerability Disclosure (CVD) process.

Thanks
Vijay


From: Viktor Dukhovni 
Date: Wednesday, November 29, 2023 at 1:40 PM
To: Wietse Venema 
Cc: Vijay S Sarvepalli 
Subject: Re: [pfx] Re: Postfix authenticated sender and From: header 
verification
On Wed, Nov 29, 2023 at 01:02:04PM -0500, Wietse Venema wrote:
> Vijay S Sarvepalli:
> > Hello Wietse,
>
>
> Adding Viktor as co-maintainer and also security geek.

Thanks. :-)  Some comments.

- RFC5322 and Postfix support "Resent-" headers, for messages that
  thare re-injected (larely as-is) into the mail stream by a recipient.
  A "Resent" message will have someone else's "From" address, and the
  original (most recent) recipient's "Resent-From" address.

- As Wietse notes, enforcing address alignment:

* Does nothing for display name alignment.

it also:

* Does not deal with potentially misleading "Group Name: ;" syntax.

* Does not deal with fancy and misleading body content that distracts
  the recipient's away from all that geeky header information.

And I consider efforts to partly raise the difficultly of using
misleading "From:" headers, without fully solving the problem, as
potentially counter-productive.

I'd rather see MUAs do a better job of signalling that the From
header is just alleged information, and should not be taken
at face value.

Maybe-From-But-Perhaps-Not:
From-Possibly:
Do-you-feel-lucky-from:
...

:-)

--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix authenticated sender and From: header verification

[Bill Cole via Postfix-users]

On 2023-12-18 at 11:31:47 UTC-0500 (Mon, 18 Dec 2023 16:31:47 +)
Vijay S Sarvepalli via Postfix-users 
is rumored to have said:


Hello Viktor, Wietse,
(I am copying the Postfix community as the report is out in the public 
now)


First of all thank you for your help and response to highlight your 
approach to this issue.  This may not be the first time you have 
observed types of abuse that relate to spoofing.


This research work has now been published by Sec Consult company, see 
link below .


It is interesting that they seem to be unaware of some SMTP basics, such 
as the fact that message bodies, message headers, and the SMTP protocol 
have different format rules, defined in different RFCs that are clearly 
marked as such. They seem to think that the problem is grounded in 
legitimate misunderstanding of imprecise RFCs, when it seems clear to me 
that there's one right interpretation.


That very much ruins my ability to take what they are saying seriously. 
I believe they tested against the proprietary systems cited and found 
the issue, I find it extremely suspect that they show no examples for 
Semndmail or Postfix, merely an assertion.


The Postfix issues the researcher mentions, we were not able to 
actually reproduce


This is unsuprising.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: mail in SRS-format in destination bypasses postfix rules

[Wietse Venema via Postfix-users]

Kristoff via Postfix-users:
> Dec 17 04:32:05 smtp postfix/smtp[725772]: 4F58E6A10A0: 
> to=u...@example.com, 
> orig_to=SRS0=zxmM=H4=example.com=u...@ourhobbyclubdomain.com, 
> relay=mail.example.com[A.B.C.D]:25, delay=0.16, delays=0.05/0/0.08/0.02, 
> dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 714F7294BB2)

How are you verifying that an SRS-format recipient address is valid?

Quoting from http://www.open-spf.org/SRS/

To prevent bad guys from using forwarders as an open relay, SRS
adds a hash (...). It also adds a timestamp (...) which causes
addresses to expire.

If you simply remove the SRS formatting without checking a hash ot
expiration time, then you will be an open relay and you should fix
that.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix authenticated sender and From: header verification

[Viktor Dukhovni via Postfix-users]

On Mon, Dec 18, 2023 at 02:48:43PM -0500, Bill Cole via Postfix-users wrote:

> > This research work has now been published by Sec Consult company, see
> > link below .
> 
> It is interesting that they seem to be unaware of some SMTP basics, such as
> the fact that message bodies, message headers, and the SMTP protocol have
> different format rules, defined in different RFCs that are clearly marked as
> such. They seem to think that the problem is grounded in legitimate
> misunderstanding of imprecise RFCs, when it seems clear to me that there's
> one right interpretation.
> 
> That very much ruins my ability to take what they are saying seriously. I
> believe they tested against the proprietary systems cited and found the
> issue, I find it extremely suspect that they show no examples for Sendmail
> or Postfix, merely an assertion.
> 
> > The Postfix issues the researcher mentions, we were not able to actually
> > reproduce
> 
> This is unsuprising.

- Postfix 3.9 (pending official release soon), rejects unuthorised
  pipelining by default: "smtpd_forbid_unauth_pipelining = yes".

- Postfix 3.8.1, 3.7.6, 3.6.10 and 3.5.20 include the same supporting
  code as 3.9 snapshots, but the "smtpd_forbid_unauth_pipelining"
  parameter defaults to "no".

  This default avoids breaking compatibility in a patch to stable
  release, in case some fax-to-email machine, or other minimally
  conformant device performs illegal pipeling.

  However, for most users it is IMHO prudent to override the default to
  "yes" in their configuration, after ensuring that that this is
  compatible with their mail flows.

With illegal pipelining blocked by default, the described attempts to
inject multiple messages into Postfix as a receiving system will fail.
This is because with very high probability any "." will be
immediately followed by some part of the rest of the original message
content in the same TCP frame, or the next TCP frame in same TCP window.

To succeed, the sending TCP would have to exactly fill a TCP window with
content up and including the ., and would have to be stalled
waiting for missing ACKs.

As an outbound server, Postfix will never send ..  Its output
will always be RFC-conformant.  So any impact falls largely on systems
that send illegal bare LF in (non-BDAT) SMTP.

It should also be noted that the piggybacked message will not have a
matching DKIM signature, and can only succeed via SPF alignment.

It may be time to consider ditching SPF.

And of course, all that this "attack" achieves is "From:" header
"forgery", in cases where the outbound server would normally not allow
the submission client to use a "From:" header of their choice.

My personal view is that phishing attacks largely rely on distracting
the user with flashy message content that draws attention away from any
"From:" header that suggest the message is not "authentic".

None of the fake "Geek Squad" bills I receive on a steady basis actually
have a related domain in "From:".  They work to defraud some of their
marks by presending artfully constructed content with all the right
logos that looks like a plausible "Geek Squad" bill.

So I don't see much point for phishers to try to achieve "From:"
alignment when they can simply not bother.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix authenticated sender and From: header verification

[Wietse Venema via Postfix-users]

Bill Cole via Postfix-users:
> On 2023-12-18 at 11:31:47 UTC-0500 (Mon, 18 Dec 2023 16:31:47 +)
> Vijay S Sarvepalli via Postfix-users 
> is rumored to have said:
> 
> > Hello Viktor, Wietse,
> > (I am copying the Postfix community as the report is out in the public 
> > now)
> >
> > First of all thank you for your help and response to highlight your 
> > approach to this issue.  This may not be the first time you have 
> > observed types of abuse that relate to spoofing.
> >
> > This research work has now been published by Sec Consult company, see 
> > link below .
> 
> It is interesting that they seem to be unaware of some SMTP basics, such 
> as the fact that message bodies, message headers, and the SMTP protocol 
> have different format rules, defined in different RFCs that are clearly 
> marked as such. They seem to think that the problem is grounded in 
> legitimate misunderstanding of imprecise RFCs, when it seems clear to me 
> that there's one right interpretation.
> 
> That very much ruins my ability to take what they are saying seriously. 
> I believe they tested against the proprietary systems cited and found 
> the issue, I find it extremely suspect that they show no examples for 
> Semndmail or Postfix, merely an assertion.
> 
> > The Postfix issues the researcher mentions, we were not able to 
> > actually reproduce
> 
> This is unsuprising.

Perhaps, but the story is a more complicated, and that was not clear
at the time that this issue came up first.

The idea appears to be that some mail services will accept and
forward messages that contain a malformed end-of-data sequence
(, with one or more  or  missing), which
is then followed by well-formed SMTP commands to send email from a
spoofed sender to a victim recipient.

The crucial part is that the service will think that it is forwarding
one message in a single SMTP MAIL/RCPT/DATA transaction.

Some forwarding services might repair the malformed end-of-data
sequence while forwading the message. From the receiver's point
of view they receive two well-formed messages. This specific
form of the problem, if it exists at all, can be fixed only at
the forwarding server's end.

Some receiving servers including Postfix will treat a malformed
end-of-data sequence as a valid one, and will receive the smuggled
message as a SEPARATE message, which would be subject to relay
access checks just like the recipient of the non-smuggled message.

Relay checks will pass if the same SMTP service hosts both the
recipients of the non-smuggled and the smuggled message.

SPF checks will pass if the MAIL FROM sender of the smuggled
message is from a domain that is hosted at the forwarding mail
service. DKIM checks will find no signature.

The countermeasure that can be taken on the Postfix side:

- Don't accept mail with a broken end-of-data sequence (Postfix
currently allows zero or more  followed by ). Or more
generally, don't accept  or  that aren't part of a 
sequence. Postfix does not support BDAT with BINARYMIME, so there
is no valid use of stray  or  bytes.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix authenticated sender and From: header verification

[Vijay S Sarvepalli via Postfix-users]

Hello Wietse,

>> - Don't accept mail with a broken end-of-data sequence (Postfix
currently allows zero or more  followed by ). Or more
generally, don't accept  or  that aren't part of a 
sequence. Postfix does not support BDAT with BINARYMIME, so there
is no valid use of stray  or  bytes.

If Postfix pursues a way to not accept “broken end-of-data sequence” as you 
state. Will plain . and  be the only 
sequences Postfix will accept? I can see potentially some clients breaking that 
I looked into (mostly scripting shell/perl/ etc.), a lot of them seem to use 
. and no  at all. That’s the only issue I can see as potential 
compatibility problem.

While it seems like a strange issue not of Postfix itself but potentially the 
mail from a Submission configured Postfix to another relay server that is 
“vulnerable” could still unfold message and behave in unexpected ways. We all 
live in the ecosystem anyway.

Thanks
Vijay Sarvepalli


From: Wietse Venema via Postfix-users 
Date: Monday, December 18, 2023 at 4:15 PM
To: Postfix users 
Subject: [pfx] Re: Postfix authenticated sender and From: header verification
Warning: External Sender - do not click links or open attachments unless you 
recognize the sender and know the content is safe.


Bill Cole via Postfix-users:
> On 2023-12-18 at 11:31:47 UTC-0500 (Mon, 18 Dec 2023 16:31:47 +)
> Vijay S Sarvepalli via Postfix-users 
> is rumored to have said:
>
> > Hello Viktor, Wietse,
> > (I am copying the Postfix community as the report is out in the public
> > now)
> >
> > First of all thank you for your help and response to highlight your
> > approach to this issue.  This may not be the first time you have
> > observed types of abuse that relate to spoofing.
> >
> > This research work has now been published by Sec Consult company, see
> > link below .
>
> It is interesting that they seem to be unaware of some SMTP basics, such
> as the fact that message bodies, message headers, and the SMTP protocol
> have different format rules, defined in different RFCs that are clearly
> marked as such. They seem to think that the problem is grounded in
> legitimate misunderstanding of imprecise RFCs, when it seems clear to me
> that there's one right interpretation.
>
> That very much ruins my ability to take what they are saying seriously.
> I believe they tested against the proprietary systems cited and found
> the issue, I find it extremely suspect that they show no examples for
> Semndmail or Postfix, merely an assertion.
>
> > The Postfix issues the researcher mentions, we were not able to
> > actually reproduce
>
> This is unsuprising.

Perhaps, but the story is a more complicated, and that was not clear
at the time that this issue came up first.

The idea appears to be that some mail services will accept and
forward messages that contain a malformed end-of-data sequence
(, with one or more  or  missing), which
is then followed by well-formed SMTP commands to send email from a
spoofed sender to a victim recipient.

The crucial part is that the service will think that it is forwarding
one message in a single SMTP MAIL/RCPT/DATA transaction.

Some forwarding services might repair the malformed end-of-data
sequence while forwading the message. From the receiver's point
of view they receive two well-formed messages. This specific
form of the problem, if it exists at all, can be fixed only at
the forwarding server's end.

Some receiving servers including Postfix will treat a malformed
end-of-data sequence as a valid one, and will receive the smuggled
message as a SEPARATE message, which would be subject to relay
access checks just like the recipient of the non-smuggled message.

Relay checks will pass if the same SMTP service hosts both the
recipients of the non-smuggled and the smuggled message.

SPF checks will pass if the MAIL FROM sender of the smuggled
message is from a domain that is hosted at the forwarding mail
service. DKIM checks will find no signature.

The countermeasure that can be taken on the Postfix side:

- Don't accept mail with a broken end-of-data sequence (Postfix
currently allows zero or more  followed by ). Or more
generally, don't accept  or  that aren't part of a 
sequence. Postfix does not support BDAT with BINARYMIME, so there
is no valid use of stray  or  bytes.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: omitting the X-Google-Original-From header

[Steffen Nurpmeso via Postfix-users]

Bill Cole via Postfix-users wrote in
 <6039ed61-2c8f-4a12-b736-994d32632...@billmail.scconsult.com>:
 |On 2023-12-17 at 09:27:36 UTC-0500 (Sun, 17 Dec 2023 06:27:36 -0800 
 |(PST))
 |saunders.nicholas--- via Postfix-users 
 |is rumored to have said:
 |
 |> How is this header populated?
 |>
 |> X-Google-Original-From: nicho...@mordor.saundersconsulting.tech
 |
 |By Google. Exactly what their algorithm is for it is not known. The "X-" 
 |prefix is the clue: it's an experimental or local-use header.

Note that the X- prefix is deprecated by RFC 6648 from 2012:

  Deprecating the "X-" Prefix and Similar Constructs in Application Protocols

I have a standard to save toilet paper by washing my back to the
pore, but i cannot name an according RFC number.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|
| Only in December: lightful Dubai COP28 Narendra Modi quote:
|  A small part of humanity has ruthlessly exploited nature.
|  But the entire humanity is bearing the cost of it,
|  especially the inhabitants of the Global South.
|  The selfishness of a few will lead the world into darkness,
|  not just for themselves but for the entire world.
|  [Christians might think of Revelation 11:18
|The nations were angry, and your wrath has come[.]
|[.]for destroying those who destroy the earth.
|   But i find the above more kind, and much friendlier]
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix authenticated sender and From: header verification

[Wietse Venema via Postfix-users]

Viktor Dukhovni via Postfix-users:
> - Postfix 3.9 (pending official release soon), rejects unuthorised
>   pipelining by default: "smtpd_forbid_unauth_pipelining = yes".
> 
> - Postfix 3.8.1, 3.7.6, 3.6.10 and 3.5.20 include the same supporting
>   code as 3.9 snapshots, but the "smtpd_forbid_unauth_pipelining"
>   parameter defaults to "no".

Indeed, setting "smtpd_forbid_unauth_pipelining = yes" prevents
Postfix from accepting a smuggled message after it has allowed a
malformed end-of-data.

This has the potential to break mail from poorly-implemented clients,
just like a stricter enforcement of  line boundaries would.

wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix authenticated sender and From: header verification

[Viktor Dukhovni via Postfix-users]

On Mon, Dec 18, 2023 at 05:40:49PM -0500, Wietse Venema wrote:

> > - Postfix 3.8.1, 3.7.6, 3.6.10 and 3.5.20 include the same supporting
> >   code as 3.9 snapshots, but the "smtpd_forbid_unauth_pipelining"
> >   parameter defaults to "no".
> 
> Indeed, setting "smtpd_forbid_unauth_pipelining = yes" prevents
> Postfix from accepting a smuggled message after it has allowed a
> malformed end-of-data.
> 
> This has the potential to break mail from poorly-implemented clients,
> just like a stricter enforcement of  line boundaries would.

To be more precise: just like it could break a potentially *different*
set of poorly-implemented clients.  My instinct is that fewer clients
would be broken by strict enforcement of pipelining than by strict
 enforcement, but that's a guess, and it behooves each site to
determine their own situation.

For now, enforcement of pipelining is actually available, while
enforcement of  vs.  is still only a hypothetical.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix authenticated sender and From: header verification

[r.barclay--- via Postfix-users]

> For now, enforcement of pipelining is actually available, while
> enforcement of  vs.  is still only a hypothetical.

As an average user without any special or legacy systems, I'd appreciate if one 
could configure Postfix as safe and secure as possible regarding this issue. So 
I'd value being on the safe side over being interoperable/lenient with non 
standard clients.
If that means to convert all standalone CR or LF to CRLF (?) or reject 
suspicious SMTP dialogues, I'd opt-in to whatever is necessary. :)

Reg
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix authenticated sender and From: header verification

[Wietse Venema via Postfix-users]

Wietse:
> - Don't accept mail with a broken end-of-data sequence (Postfix
> currently allows zero or more  followed by ). Or more
> generally, don't accept  or  that aren't part of a 
> sequence. Postfix does not support BDAT with BINARYMIME, so there
> is no valid use of stray  or  bytes.

Vijay S Sarvepalli:
> If Postfix pursues a way to not accept 'broken end-of-data sequence'
> as you state. Will plain . and 
> be the only sequences Postfix will accept? I can see potentially

Postfix would reject the first form, which contains stray  (i.e.
 that is not immediately preceded by ).

> some clients breaking that I looked into (mostly scripting shell/perl/
> etc.), a lot of them seem to use . and no  at all.
> That's the only issue I can see as potential compatibility problem.

Indeed.  is the native UNIX end-of-line byte, and may be sent
by naively implemented scripts. The use of  as the 'native'
end-of-line byte has ceased as MacOS 9 deployments fell to dust.

Rejecting stray  and  while receiving mail will prevent
Postfix from receiving "smuggled" SMTP commands after a malformed
end-of-data sequence, and thus, it will prevent Postfix from
forwarding them.

So would rejecting an SMTP command pipelining protocol violation
when the SMTP server receives a "smuggled" DATA command that is
immediately followed by message content, but an attacker may
try to position DATA immediately before a packet boundary.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix authenticated sender and From: header verification

[Viktor Dukhovni via Postfix-users]

On Tue, Dec 19, 2023 at 12:20:57AM +0100, r.barclay--- via Postfix-users wrote:
> > For now, enforcement of pipelining is actually available, while
> > enforcement of  vs.  is still only a hypothetical.
> 
> As an average user without any special or legacy systems, I'd
> appreciate if one could configure Postfix as safe and secure as
> possible regarding this issue. So I'd value being on the safe side
> over being interoperable/lenient with non standard clients.  If that
> means to convert all standalone CR or LF to CRLF (?) or reject
> suspicious SMTP dialogues, I'd opt-in to whatever is necessary. :)

If you reject unauthorised pipelining, you're fine, and may even
occasionally turn away some sloppily implemented botnet spam.


-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix using proxy protocol outbound?

[Wietse Venema via Postfix-users]

Wietse;
> inside Postfix -reverse haproxy-> remote MTAs in the Internet
> That is currently not implemented, and no design exists. 

Joachim Lindenberg via Postfix-users:
> Hello Wietse,
> Yes, exactly, no second instance. Ok, implies I haven't overlooked
> something. Is this an option you are willing to consider?  The key
> benefit to guys like me is that one doesn't have to manage two
> instances, considering setup and maintenance, configuration (like
> tls policies), backup or just trust in your provider.  Thanks,

I think what you are looking for is called a forward proxy. That
typically involves SOCKS or HTTP. The reason it is not implemented
is lack of demand - this is a very narrow use case. Cost/benefit:
there are features that benefit a larger population.

Some concerns:

- Different SOCKS or HTTP proxy implementations will have different
  limitations with respect to bugs, stability, and performance.

- Some SMTP client features cannot be proxied, such as smtp_bind_address
  (or smtp_bind_address6).

- More concerning, the Postfix SMTP client will not be able to
  manage the TCP send buffer size, which is needed to avoid deadlock
  with SMTP command pipelining (the client must occasionally stop
  sending commands to receive server responses, otherwise the server
  might block, and that would block the Postfix SMTP client). There
  is a rather long comment on this in the SMTP client's protocol
  engine. Ths means the client needs to use a pessimistic estimate.

I expect that a SOCKS5 client would not use much code, compared to
the code that was needed with HaProxy.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org