Subject: RE: DEPLOY: not at the University of Cambridge

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 9 Sep 2004 09:38:04 -0700

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Tony Finch

> Most of these
> reasons apply to all designated sender schemes, so we won't be
> implementing SPF either.

> 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. 

Looks to me as if you can still deploy an SPF record that says
that A, B & C are authentic university of Cambridge mail servers.
What you are saying you cannot do is to add a final -all to 
exclude the universe of all other mail servers.

This is supported by the spec.

> 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, 

That is why most people who are going to use a whitelist are
going to outsource the process.

VeriSign has started making the Verified Domains List available
to qualified anti-spam companies and we plan to make it available
to everyone via a DNS publication mechanism in the near future.
Both services are free.

> 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.

What this says to me is that even though the central IT dept
at Cambridge is not going to support Sender ID, the same is not necessarily
true of the colleges. The more progressive colleges
such as Porterhouse can choose to issue SenderID records for
their domains even if central IT services do not.

The ancient universities have barely come to terms with the 
consequences of the industrial revolution. If we consider 
the suitability of specifications on the basis of their 
ability to deploy we are not going to get very far.

---

From: David Woodhouse <[email-masked]>
Date: Fri, 10 Sep 2004 12:34:16 +0100

> their domains even if central IT services do not.

:)

> ability to deploy we are not going to get very far. 

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¹.

Especially in this particular case -- are we to assume that you've never
heard the term 'Silicon Fen', and you have little knowledge of the
history of computer science? Perhaps you've never even heard of Alan
Turing? 

Maybe a quote from Microsoft's web site might help...

"The city of Cambridge, England, was the clear choice for the location
of the facilities because of its world-renowned reputation and its rich
history as a center of learning. Cambridge has been the origin of
fundamental advances in nuclear physics, molecular biology and computer
science. Furthermore, Cambridge has become a center for technological
excellence in recent years. More than 300 companies and commercial
laboratories specializing in computing and advanced technology are
concentrated in the Cambridge area."

The reasons which were presented for non-deployment of Sender-ID within
Cambridge were quite clearly applicable to many other sites -- my own
inconsequential domains included. This is not an example of Luddism from
a entity which has 'barely come to terms with the consequences of the
industrial revolution' and I find it astonishing that you are willing to
say such a thing in an email which bears your employer's name.

-- 
dwmw2

¹ Although your mail client doesn't make it very clear which mail you
were replying to, as it ignores the recommendations of RFC2822. Please
use a non-broken mail client if you wish to participate in public fora.

---

From: Tony Finch <[email-masked]>
Date: Fri, 10 Sep 2004 13:33:29 +0100

On Fri, 10 Sep 2004, David Woodhouse wrote:
> 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.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTH UTSIRE: SOUTHWEST BACKING SOUTHEAST 3 OR 4, INCREASING 5. FAIR. GOOD.

---

From: Tony Finch <[email-masked]>
Date: Fri, 10 Sep 2004 14:05:56 +0100

> exclude the universe of all other mail servers.

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

> to everyone via a DNS publication mechanism in the near future.

I can't find any information about the VDL on the web. It sounds like a
list of domains whereas what we need is a list of MTA IP addresses.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL: EAST 4 OR 5 BECOMING CYCLONIC, THEN NORTHWEST 5 TO 7, PERHAPS GALE 8
LATER. RAIN LATER. MODERATE OR GOOD.

---

From: AccuSpam <[email-masked]>
Date: Fri, 10 Sep 2004 21:25:30 +0800

>forgeries, not a method of identifying legitimate email.

Disagree.  I think the PASS case will end up being much more important for anti-spam end game, than the other result cases.  For anti-forgery, maybe you need the binary answer, and those corporations who have a serious problem with forgery (phishing) will be sure to declare "-all" if they need to solve their problem.

---

From: AccuSpam <[email-masked]>
Date: Fri, 10 Sep 2004 21:45:09 +0800

>> What we need is a method of identifying forgeries, not a method of 
>> identifying legitimate email.
>
>I share that desire. However, as a practical matter it may be easier to 
>get legitimate senders to cooperate than would-be forgers.

Exacto!

For anti-spam, the future reality is that any successful anti-forgery will eliminate the forgery case as useful input.  Spammers will morph.  The PASS case is going to be much more useful in long run.  We have a proprietary algorithm in mind, which I can not detail in public.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 10 Sep 2004 15:24:34 +0200

Arnt

---

From: David Woodhouse <[email-masked]>
Date: Fri, 10 Sep 2004 15:07:00 +0100

[ Please make sure your attributions are present and correct, and
  that you limit your lines to a sane number of characters. For a
  mailing list used to discuss technical matters relating to email,
  I'm amazed at the lack of consideration shown by the posters. Is it
  September again already? ]

On Fri, 2004-09-10 at 21:25 +0800, AccuSpam wrote:
> <...fanf2 wrote:...>
> Disagree.  I think the PASS case will end up being much more important
> for anti-spam end game, than the other result cases. 

I think both are correct. I think the PASS result will end up being much
more widely used in practice than the FAIL result, as Shelby claims. For
example, I would consider bypassing SMTP verification callouts for
sender addresses when there is an SPF/Sender-ID 'PASS' result, yet I
would never consider actually rejecting mail due to a 'FAIL' result.

However I agree with Tony that this renders the whole thing pretty
worthless.

We already have ways to rate the trustworthiness of IP addresses.

We're introducing all this breakage, requiring hosts to 'upgrade' to
join the Brave New World by performing SRS or some abuse of Resent-*
headers which is inconsistent with RFC2822, and what do we achieve at
the end of it? We get spammers publishing their own records quicker than
legitimate users do, proving that the only thing we've achieved at the
end of it all is to 'reduce' it to... almost precisely the same problem
-- only now we get to rate the trustworthiness of _domains_ rather than
IP addresses.

If we really want to check domains instead of IP addresses, and to limit
the 'permitted' mail servers for outgoing mail, surely we'd just do
better to mandate the use of TLS and check the sender's certificate
against our 'trust' database? 

Oh yeah... the world hasn't actually noticed ESMTP yet, and there are
still mail hosts out there which aren't TLS-capable.... and yet you
think they're going to notice whatever changes SPF/Sender-ID require of
them?

You're living in a dream world.

-- 
dwmw2

---

From: Mark <[email-masked]>
Date: Fri, 10 Sep 2004 14:45:12 GMT

David Woodhouse wrote:

> I would consider bypassing SMTP verification
> callouts for sender addresses when there is an SPF/Sender-ID 'PASS'
> result, yet I would never consider actually rejecting mail due to a
> 'FAIL' result.

You would never? I do; on SPF "classic" FAIL, that is. And with no qualms 
about it either. "Be-FAIL ist be-FAIL", as a German would say. :)

I mean, seriously, I do so on the grounds that I am not even executing MY 
local policy, but that of the remote domain owner. Worried about losing 
legitimate mail? Why, that is a consideration made by the domain owner who 
published the "-all" SPF record. He apparently felt comfortable with that. 
And I just respect his wishes.

Furthermore, I attach the greater legal risk at accepting mail, in case 
where FAIL was prescribed. Not perhaps with your average vanity domain 
(Lord, I hate that term); but if a large financial institution says "FAIL 
this fake email, pretending to be from me, coming from a relay I have not 
authorized to send mail on my behalf," you can bet I will err on the side of 
caution, and REJECT according to their policy.

> We get spammers publishing their own records quicker
> than legitimate users do, proving that the only thing we've achieved
> at the end of it all is to 'reduce' it to... almost precisely the
> same problem -- only now we get to rate the trustworthiness of
> _domains_ rather than IP addresses.

Which is a hundred times more easy than managing individual, ever changing 
IP addresses/ranges. Blocklists based on domain names were pretty useless 
before SPF. But now they are hopefully coming back in fashion. And will make 
the New World perhaps not Braver, but easier, I hope. :)

Regards,

- Mark