weird scenario with filtering forwarded mail. RSS Back to forum
@christopher.low:
if adding the MXs of globaldomain.com to the Intermediate Host List and assigning all blacklist tests to On Arrival did not help, that probably means the forwarder server at globaldomain.com removes the original sender information and delivery path from the email headers, so ORF cannot check who the real sender host was and IP-based tests (such as the DNS Blacklist test) will not work.
The only way to address this issue is to configure the forwarder server to preserve the original sender information (Received: from lines in the header), so ORF could identify the real sender during its header analysis (related Help article: http://vamsoft.com/r?o-hto-headeranalysis).
We have seen similar issues with Forefront/ISA servers: http://vamsoft.com/support/docs/faq#header-issue
Hi, just checking.
we belong to a global organisation which means we have a global brand identity external to our own local brand/domain.
this means.. eg: we have. . and I do forwarding (via their web options) to
the problem is. @globaldomain.com doesn't really filter spam. so spam is forwarded over. via
the problem is. because the forwarded mail actually adds Return-Path: to the forwarded email. therefore. orf logs show the source of spam and the spamming ip to be from @globaldomain.com . to change this is beyond my control.
the bulk of such spam seems to originate from adamo.es , various russian sites and .it sites.. the russian spam is usually blocked by the cyrilllic filter regex that you've given me before, I've already blocked those where *.es *.it is mentioned in the user defined url blacklist, but those which is plain text spanish spam literally goes through.
sad to say, spf is also not an option (cos the @globaldomain.com doesn't have one/ or can't have one for some reason.)
I've tried adding the globaldomain.com main ips as intermediate hosts, but it doesn't really help/do anything)
any suggestions?