--On 24 November 2010 09:01:27 -0800 Dave CROCKER <d...@dcrocker.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