-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of David
Woodhouse
Sent: Tuesday, December 07, 2004 10:59 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Sendmail white paper
On Tue, 2004-11-23 at 12:02 -0500, Scott Kitterman wrote:
CSV operates on behalf of the MTA operator. SPF operates on
behalf of the
domain owner. My guess is that there is a large overlap between
these two
groups. The overlap is not, however, a unity.
You're not thinking holistically and considering the practical
applications. The reason I consider SPF and CSV to be equivalent in what
they offer is because each requires some kind of reputation service in
order to be truly useful in stopping unwanted mail; each serves to give
you a validated 'name' which you can use to look up the mail server
which is offering you the mail.
SPF only really gives you that much; it isn't an end-to-end method of
verifying that the mail really did come from you in the first place.
That's because of SRS, as explained previously -- a recipient can't tell
whether SRS0=xx=yy=kitterman(_dot_)com=spf2(_at_)srs(_dot_)infradead(_dot_)org
is really a
genuine forwarded message from you, or a fake. It's all about how much
the reputation service says you should trust "srs.infradead.org". And
that's why I say that CSV and SPF are basically equivalent in what they
offer.
I understand. Your view is that the collateral damage to forwarding is so
great that rejecting on -all is unreasonable. I have a different opinion.
For the userbase that I am dealing with in my very small domain, as the
domain owner, I find the collateral damage acceptable (so far it's been none
that I am aware of). While mail is a potentially multi-hop system, most
mail is single hop, so single hop validation provides substantial benifit.
If I didn't want you to reject on -all, I wouldn't have put it at the end of
the SPF record. I'll deal with the consequences of that. I don't expect
you to agree that this is a good idea, but it is what I intend.
Your example is exactly why I think that the forwarding problem comes down
to an issue of trust. If I trust "srs.infradead.org" as a forwarder, then I
trust that is correct. If I don't trust "srs.infradead.org", then I have no
idea. You have to trust your fowarder.
But lets just agree to disagree on forwarding. I think it's been hashed out
to death already.
BTW, even if I were to accept your premise, SPF is still superior for me.
My domain name should never appear in HELO/EHLO, so CSV does nothing for me.
If you 'volunteered' them, they may welcome the mail getting rejected
because of SPF ;). If they agreed to take that mail from you, then they
ought to whitelist you from SPF checking if their MX checks SPF.
It is an
additional complexity, I agree, but I believe it to be manageable.
They can't necessarily whitelist it. If their ISP is checking SPF, the
customers don't necessarily have a way to whitelist anything. The
forwarding problem is played down so much by the SPF advocates and the
web site that those few people who do check SPF because they aren't
really thinking for themselves certainly aren't likely to implement a
whitelisting facility.
There are people who rush into SPF. I deal with them on spf-help and we
help them work through their issues and make it work. I am not in favor of
people who don't think it through checking SPF. As part of the transitional
process, ISPs are going to have to work with their customers and do it in a
way that works for them.
Initially starting in the receive side with feeding the received-spf header
into SA is a start. Rejecting on -all should not be the first thing anyone
does. Just becuase some people are bound to get in over their heads doesn't
mean SPF is a bad idea. That's true for almost any new technology.
Nothing is inherently wrong with CSV, but it's not deployed yet and it
doesn't relate to my particular problem.
SPF isn't that widely deployed yet _either_, if you speak of people
actually _checking_ it rather than just publishing a record. I explained
above why in _practical_ terms it's as relevant an answer to your
particular problem as SPF is.
Except that CSV doesn't do anything for any mail identity that legitimately
uses my domain name. For ME, irrelevant. For MTA operators, I think it's a
good idea. If CSV proves to be relatively efficient with DNS resources
compared to SPF, it may be, in the long run, possible to intgrate the two
and reduce the impact of sender authentication on DNS.
Which of these alternatives am I able to deploy now?
DK, IIM, SES. And the new META Signatures which are the result of
William's merge of the best parts of DK and IIM, which looks promising.
A large number of hosts out there stopped accepting forged mail from
dwmw2(_at_)infradead(_dot_)org 9 months ago. Yet they accept real mail which is
from me but forwarded.
IIM/DK aren't really ready for me as far as I can tell.
Why so? Each is being used in the wild already.
I can't do SES because I don't run my own mail server.
Looking at the DomainKeys page that Stephane provided, all I see are MTA
implementations and C source code. Nothing I can download for use in any
MUA:
http://domainkeys.sourceforge.net/
Looking at the IIM page, I get a similar result:
http://sourceforge.net/projects/identifiedmail/
So far only a Sendmail milter.
Are there MUA implementations available elsewhere?
Also, since publishing my -all record, the number of bounces I receive due
to forged spam has dropped about 95%. I consider that a side benifit
(spamassassin was already dealing with them pretty nicely). The main
benifit to me is that if someone forges my name, I have a definite defense
to any accusations made against me as a result.
Scott Kitterman