Συντάκτης: Ian Eiloart Ημερομηνία: Προς: exim-users@exim.org Αντικείμενο: Re: [exim] identify spam from valid 3rd party email services using
our domain as sending address
> On 2 Feb 2016, at 12:13, Wyles, Stuart R. H. <s.wyles@???> wrote:
>
> We run exim on-premises with spamassassin (all external email comes in this way and routes to Exchange online). We also use a number of 3rd party email service providers (for things such as marketing campaigns) used by various departments at our institution. External providers use valid From: addresses pertaining to come from our own domain, but generally use their own domain for Return-Path. This gives us a headache to identify genuine email arriving from external providers (using our From: @domain address) from spam (using forged From: addresses).
>
> The two approaches we have been considering are to develop a list of valid email providers, which will be a task in itself, and either (1) allow only these external IPs (whitelist) to route through our exim servers (if sending address is from our domain) or (2) enforce external providers to authenticate to our on-premises servers (block un-auth connections using our domain).
>
> Departments do have a habit of going out and employing external providers without notice. We are leaning towards option(1) but overhead in maintaining an up-to-date list and possibility of omissions and external IPs changing is a concern. Do others find this? There is SPF, but still require valid server list, and worries of breaking something.
>
> Can I ask what other institutions do in these circumstances? What methods or technologies do you use? Do you maintain 'whitelists', or enforce authentication, or employ different methods 'on-premises' to identify genuine 3rd party emails using internal addresses from forgeries?
We forbid inbound email with an envelope address in our domain unless (a) it has a header that we’ve added when we previously saw the message, or (b) we’ve whitelisted the sender in some way. DKIM and SPF would be usable for these tests, but we don’t do it that way.
This means that external providers have to co-operate from the outset. When we originally implemented the policy, we had no external providers, which made it rather easier.
However, we have run into some absolutely terrible external providers who work heavily in academia. One, for example, offers two email sending methods: direct to the recipient, or relayed (authenticated or otherwise) through our servers. The relay method works without authentication, but when we configure authentication, it falls back to direct delivery without even connecting to our servers!
Without the relay, we have to include their IP addresses in our SPF: three entire /24 IP ranges, 90% of which have no PTR records. Some of the PTR records point to domains that I don’t recognise.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
