> On Apr 23, 2018, at 12:25 PM, mario.barbosa+postfixus...@gmail.com wrote: > > Upon further inspection, I figured out what is probably obvious to you > by now: the office 365 lists do not change the 'Sender:' header of the > original message, and when it comes back to be delivered to its > '@example.com' members, it bumps into...
Minor correction, the relevant address is the envelope sender, and not any message header such as "Sender:". The envelope is transmitted separately alongside the message, but is not part of the message. > smtpd_sender_restrictions = > permit_mynetworks, > reject_sender_login_mismatch, > check_policy_service unix:private/sender_policy_incoming > > ... namely, that reject_sender_login_mismatch policy, because during the > SMTP session the MAIL FROM is set by outlook.com servers as > 'sending-u...@example.com' (and those servers have obviously not logged > in as that user). Correct. > Temporarily, with help of 'smtpd_restriction_classes' and > 'check_client_access' I have managed to relax the > 'reject_sender_login_mismatch' requirement on mails coming from the > office 365 servers, but I'd like to plug that hole as soon as possible. Actually, that's about the best you can do, unless you sign the outbound mail with DKIM *and* transit through Office365 does not invalidate those signatures, *and* you narrow the scope of your current policy of rejecting potentially forged sender addresses with: http://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch and finally you implement some content or proxy filter that allows external email from your domain if DKIM authenticated, and otherwise rewrites the From: and/or Sender: address or (with proxy filter only) perhaps rejects the message. > So, my question to you is, what is the current best practice to deal > with this? Roughly what you're doing, unless you want to invest some real effort to implement DKIM-based anti-spoofing. -- Viktor.
