I work for the University of Cambridge Computing Service where I define
and implement our anti-spam and anti-virus policies on the central email
relays. We will not be implementing Sender-ID for reasons mostly related
to the forwarding problem, explained in more detail below. Most of these
reasons apply to all designated sender schemes, so we won't be
implementing SPF either.
Our central message store has about 32,000 users. The relays are used by a
few thousand more users in various departments and colleges. We also have
an alumni forwarding service with something over 20,000 users.
As well as the alumni forwarding service, about 7% of our message store
users forward their email off-site. These users are likely to lose
legitimate email because of Sender-ID checks at the destination sites. We
can mitigate this problem by adding Resent-From: fields to the headers of
messages we handle, but this will interfere with the resend function of
MUAs in common use in the University since they generally follow 822
semantics not 2822 semantics for this field. There are also serious
problems deciding what address to put in the field without de-optimising
messages with multiple recipients and without confusing users.
We do not know how many of our users forward email to Cambridge from other
sites, and it is very difficult to find out. We can only implement
Sender-ID checks if we also whitelist sites that forward to Cambridge, in
order to avoid erroneously rejecting legitimate email. It will be
extremely difficult to create and maintain the whitelist, both because it
is hard to find out which sites should be on the list and because it is
hard to keep up with changes in the list of outgoing MTAs at those sites.
Sender-ID records won't make it easier to maintain the list because
forwarding sites that are Sender-ID compliant won't need to be on the
list.
We are doing all the things that are necessary to be able to advertise
Sender-ID: we have always kept tight control over which machines are
permitted to send email directly to the public Internet and we block port
25 for the rest; and we have an authenticated submission service for
roaming users (though it is taking time for users to find out about it).
However we expect that because of the prevalence of forwarding in academia
and because of the likelihood that recipient sites will not properly
mitigate the forwarding problem, to advertise Sender-ID records will cause
legitimate email from our users to be erroneously rejected.
The University is a federal organization with a strongly delegated
management structure. The Computing Service does not have a monopoly over
the provision of email services, so the colleges and departments use the
central email services to a greater or lesser extent at their choice. We
would have to perform a much more detailed liaison exercise than usual to
work out what the implications of implementing Sender-ID would be for
email travelling between the various parts of the University.
My colleague Philip Haze, who wrote the MTA that we use, has already
stated that Exim will not be able to support Sender-ID because of
Microsoft's intellectual property licence.
--
Tony Finch <fanf2(_at_)cam(_dot_)ac(_dot_)uk> http://www.cus.cam.ac.uk/~fanf2/
Mail Support, University of Cambridge Computing Service
New Museums Site, Pembroke Street, Cambridge, CB2 3QH