[pfx] Re: Postfix authenticated sender and From: header verification
On Mon, Dec 18, 2023 at 17:40:49 -0500, Wietse Venema via Postfix-users wrote: > 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. Hi Wietse, Viktor, Just a small nit: the Postfix 3.9 "experimental" release notes refer to "smtpd_reject_unauth_pipelining" instead of "smtpd_forbid_unauth_pipelining", like the stable 3.[5-8] release notes do. Geert ___ 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: > [. in BDAT payload] > > > If my suspicion is correct, a dwnstream server may receive the > > > normal and suggled content as two separate messages. > > > > I don't see why. It shouldn't matter how Microsoft's MTA ends up > > with a message containing "." or (.), so long as > > they refuse to send the violating sequence to a non-BDAT peer. The > > But that is the problem. Even BDAT payloads MUST have line > endings, unless the client sends BINARYMIME content. Postfix does > not announce BINARYMIME, and as of today's fix will hang up if > . or other malforms appear in BDAT payload. It depends on how the receiving MTA processes the .. If the receiving MTA does not recognize the stray as a line boundary, then such content can result in message smuggling when the MTA forwards the message with the SMTP DATA command to an MTA that does recognize the stray as a line boundary. But that is not how today's fix works. The Postfix 3.9 SMTP server declares a violation of RFC 5321 and hangs up. The plan is to let this fix bake for a few days and then make it available in the stable Postfix releases (3.5 .. 3.8). 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: [. in BDAT payload] > > If my suspicion is correct, a dwnstream server may receive the > > normal and suggled content as two separate messages. > > I don't see why. It shouldn't matter how Microsoft's MTA ends up > with a message containing "." or (.), so long as > they refuse to send the violating sequence to a non-BDAT peer. The But that is the problem. Even BDAT payloads MUST have line endings, unless the client sends BINARYMIME content. Postfix does not announce BINARYMIME, and as of today's fix will hang up if . or other malforms appear in BDAT payload. 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
On Tue, Dec 19, 2023 at 10:42:14AM -0500, Wietse Venema via Postfix-users wrote: > First, there is one mistake in my last quoted paragraph above. In > the smuggled commands, an attacker can avoid an SMTP command > pipelining violation, by using use BDAT instead of DATA. > Below I'm indenting the smuggling-related inputs: > > EHLO ... > MAIL FROM ... > RCPT TO ... > DATA > normal content > . > MAIL FROM ... > RCPT TO ... > BDAT ... > smuggled content > BDAT 0 > . (command syntax error) > QUIT The source of the problem is that it is technically valid to pipeline a second mail transaction after the first without waiting for the initial result, and BDAT removes the synchronisation point at "DATA". At least one of these is IMNSHO a specification error. The BDAT (CHUNKING) ESMTP extension was defined rather a long time ago, in a less hostile environment. It SHOULD have specified that the first BDAT be a pipelining pause, just like "DATA". Without that, the receiving MTA is supposed to tolerate receiving a stream of pipelined BDAT commands of indeterminate length (awaiting an RSET or QUIT) even after rejecting all the recipients and the first BDAT command. That said, I'd expect it is far easier to require a pause between the end of one message and the start of another. While it is reasonable to allow a pipelined QUIT or RSET after "DOT", anything else should require resynchronisation (there's alreadya a resync after RSET and QUIT is of course final). I don't see a legitimate use-case for SMTP clients to stuff a stream of pipelined messages down the wire without any intemediate pauses after the initial EHLO. Is anyone aware of sending MTAs that do that? [ It this is something only some MUAs do, then "message stuffing" could be restricted to submission and trusted clients. ] > Second, speaking of BDAT, I suspect that Microsoft's fix may still > allow stray when the smuggler uses BDAT for the whole transaction. > Again, I'm indenting the smuggling-related inputs: > > EHLO ... > MAIL FROM ... > RCPT TO ... > BDAT ... > normal content > . > smuggled commands and content > BDAT 0 > QUIT [ That "BDAT 0" is of course "BDAT 0 LAST", or, more typically, "BDAT LAST". ] But the reported Microsoft "workaround" is that they won't transmit . to a remote system that does not do BDAT, they will send a non-BDAT .. After a deeper analysis of outbound SMTP servers, a peculiarity in Microsoft Outlook's (outlook.com) SMTP server was observed. When trying to send an . sequence, the message does not get transmitted, and the following error message is returned: Remote server returned '550 5.6.11 SMTPSEND.BareLinefeedsAreIllegal; message contains bare linefeeds, which cannot be sent via DATA and receiving system does not support BDAT' Note that Postfix supports BDAT, and Microsoft will presumably elect to use it when available, so outlook.com->Postfix should never result in SMTP message smuggling regardless of line endings, that requires either the sending or receiving system to not support CHUNKING (BDAT). > If my suspicion is correct, a dwnstream server may receive the > normal and suggled content as two separate messages. I don't see why. It shouldn't matter how Microsoft's MTA ends up with a message containing "." or (.), so long as they refuse to send the violating sequence to a non-BDAT peer. The issue seems to be that they didn't think to apply the logic to both variants, censoring only ., but not .. -- 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: > 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. Unfortunately, the path to hell is paved with partial workarouds. First, there is one mistake in my last quoted paragraph above. In the smuggled commands, an attacker can avoid an SMTP command pipelining violation, by using use BDAT instead of DATA. Below I'm indenting the smuggling-related inputs: EHLO ... MAIL FROM ... RCPT TO ... DATA normal content . MAIL FROM ... RCPT TO ... BDAT ... smuggled content BDAT 0 . (command syntax error) QUIT Second, speaking of BDAT, I suspect that Microsoft's fix may still allow stray when the smuggler uses BDAT for the whole transaction. Again, I'm indenting the smuggling-related inputs: EHLO ... MAIL FROM ... RCPT TO ... BDAT ... normal content . smuggled commands and content BDAT 0 QUIT If my suspicion is correct, a dwnstream server may receive the normal and suggled content as two separate messages. Conclusion: for Postfix, rejecting malformed line endings is the way to go. That includes malformed line endings inside BDAT. 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
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 authenticated sender and From: header verification
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
> 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
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
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
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: 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. 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
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
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: Postfix authenticated sender and From: header verification
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<https://www.postfix.org/postconf.5.html#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<https://www.postfix.org/postconf.5.html#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
Wietse Venema via Postfix-users: > Vijay S Sarvepalli via Postfix-users: > > Hello Postfix community, > > > > This may be a feature request. As far as I can tell it is currently > > not possible to verify if an authenticated user has sent email > > that uses a From: header (After DATA command) that does not match > > his/her credentials. > ... > > The only way I found is using some third party software > > https://github.com/magcks/milterfrom/ > > This is intentional. Apart from simple header/body checks to block > known evil, Postfix generally does not implement configurable > policies on header/body content, leaving such policies up to plugins. Added note: most email 'user' software does not show the From: address, but instead shows the "display name" in the From: header. From: "display name" Or the obsolete form: From: address (display name) Tools like "milterfrom" replace the address without updating the display name. A more sophisticated solution would use a lookup table that maps an envelope sender to a complete new From: header, and thaht would drop the existing From: header if such a mapping exists. 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
On 2023-11-27 at 17:55:32 UTC-0500 (Mon, 27 Nov 2023 22:55:32 +) Vijay S Sarvepalli via Postfix-users is rumored to have said: Hello Postfix community, This may be a feature request. As far as I can tell it is currently not possible to verify if an authenticated user has sent email that uses a From: header (After DATA command) that does not match his/her credentials. The features https://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch allows for SMTP MAIL FROM: address to be verified with the authenticated user. However if a user spoofs From: header inside an email and leave the SMTP MAIL FROM: to be matching, it cannot be inspected or verified using any Postfix configuration parameters. Correct. As Dr. Venema said, this is a design choice. An important and correct one, in my opinion. The only way I found is using some third party software https://github.com/magcks/milterfrom/ Actually there are MANY ways to attack this issue with add-ons for Postfix. For example, if you use any of the mechanisms for integrating Apache SpamAssassin, it has a suite of rules related to the coherence of various sender-related values. So you could just use SpamAssassin with Amavis, MIMEDefang, MailMunge, spamass-milter, or in a simple content_filter to get those rules applied at whatever weights you like. There are also other anti-spam tools that can be integrated with Postfix by its various interfaces. Is it possible to include this as a feature so it is possible for large scale ISP’s to prevent any one user using another user hosted on the same server. This type of spoofing of the From: header inside the email could go unnoticed, potentially get a SPF verified delivery and/or even get a DKIM signature due to the lack of native capability to inspect and reject such misuse. Something like reject_authenticated_from_login_mismatch could be used to distinguish this configuration parameter. Sophisticated analysis of the contents of a message (which may or may not be in a standard format and may even be designed to thwart analysis) is a complicated and potentially dangerous task. As a transport agent, Postfix should not be spending the resources or taking the risk of such analysis. It is much safer to delegate that analysis to specialized external software. -- 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: Postfix authenticated sender and From: header verification
Vijay S Sarvepalli via Postfix-users: [ Charset windows-1252 converted... ] > Hello Postfix community, > > This may be a feature request. As far as I can tell it is currently > not possible to verify if an authenticated user has sent email > that uses a From: header (After DATA command) that does not match > his/her credentials. ... > The only way I found is using some third party software > https://github.com/magcks/milterfrom/ This is intentional. Apart from simple header/body checks to block known evil, Postfix generally does not implement configurable policies on header/body content, leaving such policies up to plugins. > There may be two other minor issues that I can bring up for Postfix community > to comment on > > > 1. The mailbox_command and delivery pipe programs provided > valuable environment variables such as ORIGINAL_RECIPIENT, SENDER, > LOGNAME - is it possible to also provide the ESMTP ID internally > as another environment variable? This is primarily to identify > the delivery transaction via pipe or mailbox_command initiated > (perhaps uniquely) > https://www.postfix.org/postconf.5.html#mailbox_command I suppose that is the RFC 3461 ENVID parameter of the MAIL FROM command? Fortunately, this information is already available in Postfix delivery agents. It takes only two lines of code in src/local/command.to export the value: if (state.request->dsn_envid && state.request->dsn_envid[0]) argv_add(env, "ENVID", state.request->dsn_envid, ARGV_END); It take more text to document this in local(8), postconf(5), and perhaps elsewhere. I have a preliminary iomplementation for Postfux 3.9 that I will finish later. > 2. The example configuration file incorrectly states a configuration > called ./conf/main.cf `default_user` which should be `default_privs` > as I understand > Line 455: # Exception: delivery for root is done as $default_user. Thanks, fixed in Postfix 3.9. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
