Subject: DEPLOY: not at the University of Cambridge

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2004 11:12:02 +0100

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  <[email-masked]>  http://www.cus.cam.ac.uk/~fanf2/
    Mail Support, University of Cambridge Computing Service
     New Museums Site, Pembroke Street, Cambridge, CB2 3QH

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 10 Sep 2004 06:45:53 -0700

> From: Tony Finch [mailto:[email-masked]]

> That's pretty worthless. What we need is a method of identifying
> forgeries, not a method of identifying legitimate email.

That is what Sender-ID is, a means of identifying legitimate mail.
That is the objective.

> On Fri, 10 Sep 2004, David Woodhouse wrote:
> >
> > I don't think an ad hominem attack is really an appropriate 
> response to
> > a concise and technical report such as the one to which you were
> > responding.
> 
> I shouldn't worry about Phillip's silliness. After all he is 
> an Oxonian
> and so should be familiar with institutions that are more 
> concerned with
> the number of angels that can dance on the head of a pin than, say,
> nuclear physics.

Actually I was in the Nuclear Physics department.

---

From: "Sauer, Damon" <[email-masked]>
Date: Fri, 10 Sep 2004 10:42:00 -0500

<snip>
> > 1) When SPF is deployed and used the line between forgeries and 
> > legitimate will be much sharper.
> > 2) In the corporate world, I am actually going to be able to deploy 
> > SPF based on the argument that my MAIL FROM: will not be able to be 
> > forged.
> > 3) Which in turn makes all MY email legitimate. This means if anyone
> > sends with my domain from a source outside of my defined 
> range, you can
> > identify as a forgery.
> 
> The point is that you _cannot_ reliably identify it as a 
> forgery unless you're willing to redefine your meaning of 
> 'forgery' for the purpose; in particular you'd have to 
> redefine your meaning of 'forgery' to include a lot of mail 
> which a lot of people consider perfectly valid and normal.
> 
> Consider the case where you send mail a user at one of my 
> virtual domains, and my mail hosts forward it on to the final 
> recipient. Some definitions of 'forgery' may include the mail 
> which my mail host sends on... but my definition does not.

 In this case it is not my MTA or your MTA that has an issue but one on
the MTA's that you forward to. 
At this point it has less to do with an issue of my SPF record as it is
your issue between your MTA's.
If the receiving MTA does an SPF check, then the MTA that the message is
forwarded to should trust the originating MTA shouldn't it?
If the receiving MTA does not trust the sending MTA in your example,
then why would you allow it to forward through it? Isn't this the same
as an open-relay?
 My internal systems that my gateway systems forward to will not be
doing SPF checks, that is what my gateways are for.
Sounds like an administrative issue that can be resolved.

<snip>

Regards,
Damon Sauer

*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you received this in error, please contact the sender and delete the material from all computers. 113