Re: whitelist_from_rcvd / trusted_networks
On Mon, 10 Nov 2014 23:30:28 -0500 (EST) Derek Diget wrote: We have a department that has subscribed to a service in the cloud product that is sending email to us via our MX record. The problem is that they appear to be using shared servers/IPs and thus every once in a while mail will source from an IP address that will cause it to score above 5. ... I would like to use whitelist_from_rcvd as the envelope from (RFC5321.MailFrom) and sending system is not exactly static, but close enough that the globing should work. The issue is that SA is running on our MXes via a milter and since SA (and these boxes) only see MX traffic, trusted_networks and/or internal_networks are empty. This causes the whitelist_from_rcvd to never fire. Our MTA does construct a synthetic Received header My question is how can I make this Received header trusted What makes you think it isn't? Most blocklists run on the last-external IP address, the fact that it's being flagged as spam based on IP address suggests it is. Try adding the following to local.cf: add_header all Relays-External _RELAYSEXTERNAL_ The first section of this header should have the parsed information from the MX server. Check that the ip and rdns fields are correct.
whitelist_from_rcvd / trusted_networks
We have a department that has subscribed to a service in the cloud product that is sending email to us via our MX record. The problem is that they appear to be using shared servers/IPs and thus every once in a while mail will source from an IP address that will cause it to score above 5. I would like to use whitelist_from_rcvd as the envelope from (RFC5321.MailFrom) and sending system is not exactly static, but close enough that the globing should work. The issue is that SA is running on our MXes via a milter and since SA (and these boxes) only see MX traffic, trusted_networks and/or internal_networks are empty. This causes the whitelist_from_rcvd to never fire. Our MTA does construct a synthetic Received header as it passes the message to SA via the milter interface. The message is passed to SA before the MTA accepts/rejects the message (scanned before the reply to DATA command). The Received header it creates and adds before sending to SA is what the Received header would look like if the message had been accepted, queued and then handed off to SA via the LDA. Therefore, the from clause is whatever system is relaying the message (HELO, DNS and IP), and the by clause is our system's name. My question is how can I make this Received header trusted or how can I force whitelist_from_rcvd to fire (or some other way to whitelist a sending pair - envelope from, sending IP/host). I don't want to add the IPs of the cloud provider to the trusted_networks. I know that the first/top Received header can be trusted. -- *** Derek DigetOffice of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ ***
Re: whitelist_from_rcvd / trusted_networks
Even in that configuration (which is -very- much like ours) you must have your MXs (at least their IP addrs) in your internal_networks. All kinds of things break if your MXs aren't listed as trusted/internal. Just be sure that synthetic Received header is constructed correctly (the one Achilles-heel of milters). Are the messages DKIM authenticated? (Either DK signed or SPF listed)? IE can you use whitelist_auth ? It's more reliable than whitelist_from_rcvd which depends upon finding the correct DNS names of all the SMTP exit points. It also depends upon the Envelope From address being available to SA. On Mon, 10 Nov 2014, Derek Diget wrote: We have a department that has subscribed to a service in the cloud product that is sending email to us via our MX record. The problem is that they appear to be using shared servers/IPs and thus every once in a while mail will source from an IP address that will cause it to score above 5. I would like to use whitelist_from_rcvd as the envelope from (RFC5321.MailFrom) and sending system is not exactly static, but close enough that the globing should work. The issue is that SA is running on our MXes via a milter and since SA (and these boxes) only see MX traffic, trusted_networks and/or internal_networks are empty. This causes the whitelist_from_rcvd to never fire. Our MTA does construct a synthetic Received header as it passes the message to SA via the milter interface. The message is passed to SA before the MTA accepts/rejects the message (scanned before the reply to DATA command). The Received header it creates and adds before sending to SA is what the Received header would look like if the message had been accepted, queued and then handed off to SA via the LDA. Therefore, the from clause is whatever system is relaying the message (HELO, DNS and IP), and the by clause is our system's name. My question is how can I make this Received header trusted or how can I force whitelist_from_rcvd to fire (or some other way to whitelist a sending pair - envelope from, sending IP/host). I don't want to add the IPs of the cloud provider to the trusted_networks. I know that the first/top Received header can be trusted. -- Dave Funk University of Iowa dbfunk (at) engineering.uiowa.eduCollege of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include std_disclaimer.h Better is not better, 'standard' is better. B{