On Fri, 2005-01-14 at 10:49 -0800, Justin Mason wrote:
David Woodhouse writes:
On Thu, 2005-01-13 at 12:41 -0500, John R Levine wrote:
Signature schemes ask yet a different question. Whereas SPF asks "could
the message have come from this domain", signature schemes ask "did the
message come from this domain." That's a different and considerably
stronger assertion.
The way I prefer to see/phrase this is that SPF offers a _whitelist_. It
can say 'yes' or it can say 'maybe'. It can't reliably say 'no'.
The %exists feature thwarts relying upon this to whitelist. : (
It's only a 'no' result which is _really_ useful because that's what
allows us to _reject_ email. SPF can only sensibly be used for bypassing
other checks for known-trusted senders, not for rejecting mail.
Not really. If there is a shared MTA, then even a 'yes' means little.
Well, FWIW, it looks like signature schemes that can't survive mailing
lists or over-aggressive munging MTAs will be in a similar boat, at least
until the servers are fixed to not break the sigs.
A signature provides strong evidence of accountability. This is an
important difference. Path registration can not provide evidence of
accountability.
in other words, a signature-verification failure may be:
1. a spammer attempting signature reuse
2. a list server appending text/munging the body
3. an MTA munging the message in transit
Given the prevalence of 2 and 3, a checking gateway can't assume 1 has
taken place.
If the signature is found valid, it tells you far more than what is
possible from a path registration scheme.
A signature may not be as effective initially with a high failure rate.
Just as there is a fair amount of effort employed to unravel layers of
encoding often used by spammers, forensic efforts on damaged signatures
will likely become a specialty. A recovery effort may go unaided by the
signature mechanism, but there is still the possibility to recognize the
MO of various MTAs.
I suspect it will not take long to arrive at rather robust methods for
data recovery. I worked in the storage field too long to think
otherwise. We can allay fears that a recovery effort would open the
door for abuse by insisting upon a general guideline: Only the original
data will be conveyed following recovery.
So that leaves only the ability to say "this message
has passed signature verification, so therefore it was really sent
by the signing domain".
This is allot. But it may include another feature. ; )
Also, more correctly, both SPF and sig schemes do not offer a whitelist,
themselves; they offer a way to ensure that the sender's address has not
been impersonated, which *in conjunction with* a whitelist of
addresses/domains, can be used to whitelist a message. in other words
we still need reputation services or similar on top.
A whitelist does not need any other input beyond the transport to
perform the whitelisting function. Path registration says the mailbox
purports to use and perhaps shares this address. As such, there is no
assurance the whitelist excludes undesired domains or that the mailbox
is not being impersonated!
With the many records involved with registering the path and the many
operations needed to achieve this function, it is doubtful there is
practical way such a scheme can to the inverse, in saying this address
does not belong to some sub-domain of a mailbox as a means to prevent
phishing. : (
-Doug