Dealing with DNSDL blacklisting where firewall address masks smtp server IP? RSS Back to forum
@Bazagee:
as per standards, all hosts which through emails are relayed must add their own information to the header as a Received: from line. This allows MTAs to check the delivery path of an email. I guess Proofpoint checks not only the last delivery hop (i.e., the host from which it received the email directly, in this case your MX) - it goes deeper, and finds your firewall IP.
This is very similar to the way the Header analysis of ORF operates (http://vamsoft.com/r?o-hto-headeranalysis): ORF checks the delivery path and tries to determine who the real sender was, by "looking behind" intranet IPs and intermediate hosts. ORF 4.4 and earlier versions used to have a feature which allowed administrators to manually set the header check depth, but most people misused it, so we removed it from the GUI:
http://vamsoft.com/support/docs/knowledge-base/header-check-depth-option
Long story short, I think the Proofpoint service goes deeper in the header than it should, which leads to the problem. What you can try is what you mentioned: configuring the firewall to relay emails in a transparent way (i.e., not to add any Received: from lines to the header), but I am not sure if that is possible and what other things this change may break...
We got ourselves onto a few smtp blacklists after a user clicked on a link in an phishing email and got the PC infected. It must have had its own smtp engine sending out spam which got us tagged (I've since setup firewall rules to disallow any port 25 traffic out except for the legit mailserver and ORF - which we route all mail through).
We are cleared off all the list except to mac recipient addresses in the .me domain. They are using Proofpoint dynamic reputation lookup which sees our retagged email coming from our firewall IP not the ORF public IP. Strange thing is that we haven't 'ever' changed this behaviour of firewall addressing, so this might be something new that the .me domain and Proofpoint have initiated.
What do you guys suggest in this case. I'm not sure I can even have the firewall 'not' re-tag the packets since its a packet filter being used as an outgoing rule from the DMZ where ORF sits.
TIA