Re: [exim] Use of hashes to fix forwarding

--On February 2, 2005 16:58:34 +0000 Jethro R Binks
<jethro.binks@???> wrote:

> While I can't give any other examples, it being a very long time since I
> considered implementing a rule like this, eBay isn't the only service
> that does this sort of thing.
>
> I'm surprised in implementing this rule you haven't had complaints.
>

Well, that's us that implemented it.

It's true that we use a simple header. This is designed to stop spam, not
sophisticated identity theft. However, we probably will replace it with a
hashing scheme - perhaps based on the recipe that Matthew provided. We
would appreciate that extra level of protection.

We do, of course, offer MSA; but on the wrong port at the moment, as we
weren't aware of RFC 2476 when we implemented it. Here's what we implement
right now:

We use Mulberry as our main mail client, and can distribute it
preconfigured with the SMTP host. Currently we require connections
from off campus to use TLSv1 and to authenticate, on ports 25 or
225 OR to use SSL with authentication on port 465 - as some clients
can't use TLS. We also require encryption and authentication from
some parts of campus where we've seen virus outbreaks - and intend
to spread this requirement across campus.

We're deploying a cluster of Apple XServes with Exim for SMTP/MSA - using
Apple's surprisingly easy to configure IPFailover for resilience.
These will support MSA on port 587 as well as the current ports.
When they're out, we'll be reconfiguring our default Mulberry
settings to use port 587 - and changing all our documentation to
recommend port 587 to all users: that seems to be easier than
trying to separately identify those users whose ISPs block port 25.
We may even change all the preferences on our IMSP server - but
we'll have to consider whether that might break more than it fixes.

Ah, and complaints. Yes, we do get them, but we get far more complaints
about viruses and spam. So, the new XServes use clamav anti-virus, and
we'll try to improve our bogofilter setup. We also get quite a few
complaints about sender verification callouts breaking incoming mail. I've
always resolved this by persuading the other postmaster to fix their
system; though recently I was surprised to hear that other institutions
have been granting exemptions to one UK university which has (IMHO) broken
mailing list software. As far as I can tell, each person who has granted an
exemption has probably done as much work as it would take to fix the lists.

So here's what I do. I monitor sender verification failures from .edu and
.uk addresses. When I see them, I try to judge whether they're due to
forgeries or not 99% are. If not, I email a complaint to their postmaster,
and bcc it to both the sender and the intended recipient. The email makes
it clear that the sender's mail is broken in several ways by their
postmaster. If my email isn't ignored, the problem always gets fixed by
them. I use a standard text - with hints on how to fix certain mailers -
and this is just as easy as adding an exemption rule.

Anyway, I take the same approach to third parties that forge our addresses.
We do stamp outgoing mail to allow it back in from certain mailing lists,
or forwarding services, though.

If I get any serious complaints, I may add a checkbox to our web based exim
filter editor saying something like: "Allow other people to steal my
identity"! Oh, and in this case, it wouldn't edit the exim filter, it would
set an attribute in our LDAP database.




--
Ian Eiloart
Servers Team
Sussex University ITS