Yeah, it do break forwarding where stupid mailservers (or more correctly, mailservers configured by stupid admins) just forward the mail verbatim, and even forge the MAIL FROM to the destination server.
That is the thing that causes SPF to fail when for example: My server --> Receivers Company server --> Receivers Private address (not DKIM aware). And "Receivers Company server" is stupidly configured and forges the MAIL FROM (instead of replacing it with a own address), and thus the Private server reject the mail due to a SPF failure, which causes the "Receivers Company Server" to return a DSN (since it knows that SPF is OK from their point of view) where private server complains on the SPF. OFCOURSE the "Receivers Company server" is not authorized to send with my domain as MAIL FROM according to my SPF record, SPF works exactly as expected. Same with this policy suggestion with rejecting local forgeries. Its nothing wrong with such a policy, its the forwarding mailserver that are doing things wrong if the mail gets rejected due to forwarding. Yes, forwarders could use Sender Rewriting Scheme, but better is to actually rewrite the mail to be able to pass the SPF policy from their own point of view, eg rewrite MAIL FROM to actually contain the address the mail was originally sent to. Like a mail sent MAIL FROM sebast...@sebbe.eu to somegr...@mycompany.org should be forwarded as MAIL FROM somegr...@mycompany.org to finaldestinat...@privateserver.org So if this breaks forwarding in some cases, blame it on the servers who are forwarding the mail. Have had a few such failures when I send mail due to my "Reject local forgeries" and SPF policy, then I have wrote a oozing mail to the postmaster of the forwarding server where I tell them why their server is so badly misconfigured. In some cases they have fixed the problem, and in other cases they told me that it would break <insert something else> here (for example filter rules). >Wietse: The advantage with my example (Where I use permit_mynetworks or permit_sasl_authenticated inside the sender_access file in addition to reject), is that authenticated senders cannot spoof the sender domain to something else either. So if us...@example.com tries to send as rolexwatc...@watchcompany.com to a remote receiver (relaying), the permit_sasl_authenticated will never be returned by the sender_access file, and thus it will not accept the mail. This can then be combined with the policy that only allows authenticated senders to send as the same username as they have logged on with, which then makes a rock solid defense against spambots running on client computers, as they will be forced to send as the original user, and the problem can be traced much more easily when abuse happens. -----Ursprungligt meddelande----- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Richard James Salts Skickat: den 19 maj 2016 01:07 Till: postfix-users@postfix.org Ämne: Re: Telnet auth On 19/05/16 00:38, Wietse Venema wrote: > Wietse Venema: >> A brief example: >> >> /etc/postfix/sender_access: >> example.com reject Sender address requires authentication >> other.example reject Sender address requires authentication >> >> Do "postmap /etc/postfix/sender_access", then add this to main.cf: >> >> smtpd_sender_restrictions = >> permit_mynetworks >> permit_sasl_authenticated >> check_sender_access hash:/etc/postfix/sender_access >> >> With this, only senders in a trusted network, or authenticated >> senders, can do "MAIL FROM:<u...@example.com>" etc. >> >> This does not restrict the address in the From: message header. > BTW this means that you have to do your "telnet" tests from a remote > IP address! > > Wietse And it will also break forwarding for your users. e.g. u...@example.com sends to a mailing list that they're a member of and the mailing list doesn't alter the envelope sender, or sends to their friend at user2@alumni.example who has their mail forwarded back to us...@example.com. A way to allow this but prevent forgeries would be to set up DKIM or BATV and reject email with an invalid signature for the email or the envelope sender.
smime.p7s
Description: S/MIME Cryptographic Signature
