--On 24 November 2010 09:01:27 -0800 Dave CROCKER <dhc(_at_)dcrocker(_dot_)net>
wrote:
On 11/23/2010 3:14 AM, Ian Eiloart wrote:
Actually, they're complementary. In places where DKIM fails (mailing
lists rewriting messages), SPF can succeed. And in places where SPF fails
(message forwarding), DKIM can succeed.
This assertion of facts is almost certainly incorrect.
Please specify the details of the scenarios in which you claim these
assertions are correct.
d/
OK: A sender publishes SPF records, with -all, and DKIM signs outgoing
messages.
A recipient checks both SPF and DKIM.
If the message goes through a forwarder, who doesn't alter the message or
the return-path, then the recipient will see an SPF fail, but the DKIM
signature will be good. The sender can ensure that there's something that
the recipient can use to apply domain reputation. I think the second
assertion above is quite simply demonstrated.
With mailing lists, it's a bit more complicated - but there's good reason
for using both when there are no intermediaries at all - see below. Neither
DKIM nor SPF are end-to-end with mailing lists, since the list will change
the return-path (at least you don't get SPF false negatives), and DKIM
signatures are likely to be broken if they protect the full body. Of
course, the list operator might usefully publish SPF records, sign their
outbound messages, or both.
But, with mailing lists, the sender can only do their best to have the
message accepted by the list. Beyond that, there's little influence (other
than that ADSP can harm onward delivery).
However, list managers will want to screen incoming messages. Mailman will
accept messages where the return-path OR From: header address, OR Sender:
header address is a member's email address. So, all these addresses need
protection. DKIM can't protect the return path address, but SPF can. If a
message doesn't have a member's address in the headers, has the address in
the return-path, but SPF is published, but results in a "fail", then it may
be wise to reject the message. Here, DKIM has failed in the sense that it
has failed (by design, so perhaps "fail" is too strong a word) to say
anything about the acceptability of the message.
Without intermediaries
----------------------
There are some simpler use cases, where there is no intermediary. If the
sender and recipient are both using the same mechanism (DKIM or SPF) for
domain reputation, then the mechanism helps both. If they're not using the
same mechanism, then neither is helped. In the absence of knowledge about
which mechanism the recipient is using, the sender is wise to both DKIM
sign, and to publish SPF records. In the absence of knowledge of which the
sender is using, the recipient is wise to check both. Of course these
scenarios are all determined by deployment choices that others have made.
They're not inherent properties of the mechanisms.
Here's a table, where S is a sender who publishes SPF, D is a sender who
DKIM signs. SD does both, but O does neither. Recipients are S if they
check SPF records, D if they check DKIM signatures, SD does both, but O
does neither. + indicates that some information is transferred from sender
to recipient, - indicates that no information is transferred. As long as
there are senders and recipients in all four categories, the people
benefiting most from the available technologies are those that deploy both.
Caveat: they have to deploy them sensibly.
Recipient: O S D SD
Sender
O - - - -
S - + - +
D - - + +
SD - + + +
There's an analogy with blood groups, but the logic is inverted. With blood
donations you want to avoid transferring information (antigens), except
when the recipient doesn't have the antibodies that check for them.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html