-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 21 July 2004 02:39 am, Paul Howarth wrote:
Where you and I are disagreeing is about your assertion that an SPF
"pass" result implies that the purported sender is accepting
responsibility for the email. So let's forget the analagies and go back
to the specs to see exactly what an SPF "pass" result actually means.
First all, let's consider the "classic SPF" spec.
(http://spf.pobox.com/spf-draft-200406.txt):
Section 3 of this spec. says:
Pass (+): the message meets the publishing domain's definition of
legitimacy. MTAs proceed to apply local policy and MAY accept or
reject the message accordingly.
Note that the definition of legitimacy here is that of the publishing
domain, not of the receiver. So you can't make the assumption that just
because the result is a pass guarantees that the original domain is
sccepting full responsibility/liability for that mail.
So we are quibbling over whether a claim of legitimacy is a claim of
responsibility.
I think we agree that publishing SPF is claiming legitimacy. (The specs say
as much.)
I think we also agree that responsibility implies liability. And whether or
not we can claim liability is what we are discussing.
I say legitimacy implies responsibility. You say it does not. That is the
broken link in the chain of logic.
I ask you to come up with one real-world example where someone does not
claim responsibility but claims legitimacy. I can't think of any.
Note that I know there are instances where legitimate persons acted outside
the claims of their legitimacy, and thus, there was no responsibility for
their actions. IE, an employer cannot be held responsible for their
employee's criminal ctions, unless the employer ordered, condoned, or
otherwise authorized those actions.
Section 1.2 of the spec. also mentions that:
Designated sender schemes are weaker than cryptographic schemes but
provide more assurance than the current SMTP model.
The language used in the newer MARID spec.
(http://spf.pobox.com/draft-ietf-marid-protocol-00.txt) is even weaker:
Yes, cryptographic schemes are stronger. I can't deny that. But many say
they are overkill.
How would DomainKeys work with SPF? As you know, SPF relies on checking the
2821 MAIL FROM line, which means DomainKey checks cannot be made until
after the SPF checks have completed and the entire email has been sent.
There are three designations I can give to a credential:
+ Legitimate: This credential proves that they are legitimate
- Illegitimate: This credential proves that they are illegitimate
? Neutral / Unknown: Further checks are needed as this credential doesn't
prove one way or the other.
SPF checks and DK checks are merely credentials. An SPF PASS result is a +
credential. SPF NEUTRAL is ?. SPF FAIL is -. DK Pass is +. DK Unknown / Not
signed / Not published is ?. And DK fail is -.
This chart will show whether or not an email is legitimate or illegitimate
based on the results of the two tests. I'll explain below.
DK+ DK? DK-
SPF+ + + +
SPF? + ? -
SPF- - - -
(You'll need to view the chart above with fixed fonts)
Since SPF PASS (or my telling you that this server is a legitimate server)
precedes the DK check, then any mail that has an SPF PASS result will be
considered legitimate. If every mail coming from a server can't be
considered legitimate, don't mark it as legitimate!
Since an SPF NEUTRAL result means that I can neither confirm nor deny the
legitimacy of a mail from these serveras, you have to make the DK checks to
see if it is good or not. The result depends on whatever result you get
from the DK check.
Since an SPF FAIL results means that under no circumstances will email from
that server be considered legitimate, then there is no reason to make the
DK checks. Obviously, it is illegitimate. If mail coming from these servers
may be legitimate, don't mark them as illegitimate!
Now consider the four types of receiving MTA configurations.
You have to think of the four kinds of receiving MTAs out there:
(1) Neither SPF or DK checks
(2) SPF but not DK checks
(3) DK but not SPF checks
(4) Both SPF and DK checks
Configuration 1 will always have to apply more checks based on external
criteria. (SpamAssassin or custome white / black lists.) They can't prove
or disprove legitimacy of any email (except those specified by direct
contact).
Configuration 2 doesn't check DK, and so an SPF NEUTRAL result means it will
have to do further checks (SpamAssassin, etc..) But a PASS or FAIL means
the mail is definitely legitimate or illegitimate, respectively.
Configuration 3 doesn't look at SPF, but it relies on DK. It will accept
email from illegitimate servers but subject them to DK checks. This will
mean the bad guys can try and generate mail that has valid DK checks. It
will also subject mail from legitimate servers to unnecessary DK checks.
(If your key-signing, legitimate servers get compromised, DK is compromised
as well. Therefore, you will never see SPF PASS / DK FAIL unless the server
isn't really legitimate.)
Configuration 4 is ideal.
What does this mean? This means that SPF is a way to claim legitimacy of a
sending MTA (which is exactly as advertised). It means that when I do
declare the server to be legitimate, further checks are unnecessary to
determine its legitimacy. Therefore, by publishing SPF records that put a
class of servers as legitimate, I claim responsibility for the emails those
senders send.
If I can't be responsible for all messages coming from a server, or if I
require that further credentials be checked, I MUST publish SPF records
that list them as '?'.
Section 3.2 specifies the results set:
Neutral (?): published data is explicitly inconclusive
Pass (+): the <ip> is in the permitted set
Fail (-): the <ip> is in the not permitted set
SoftFail (~): the <ip> may be in the not permitted set
A "pass" indicates that an IP is *permitted* to send email for a domain.
Nowhere does it say that any SPF "pass" result means that the sending
domain accepts responsibility for email in a complete and legally-binding
way. In fact I would go as far as to wager that if it did say something
like that then the number of domains publishing SPF would shrink
significantly and the technology would never actually take off.
Here again, it supports my argument. If I permit email to be sent in my
name, I am claiming responsibility for it.
- --
Jonathan M. Gardner
Mass Mail Systems Developer, Amazon.com
jonagard(_at_)amazon(_dot_)com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFA/qUlBFeYcclU5Q0RAp3gAJ9omVNtN293+Zva7q7i16O9xM5kWgCg06h4
S3Shkiy2iskEgTPUy1K3vSw=
=HKgs
-----END PGP SIGNATURE-----