[ietf-dkim] Should DKIM drop SSP?

[Douglas Otis]

On Oct 26, 2005, at 8:30 PM, Hector Santos wrote:


> So as a SMTP vendor, I really don't care what your mail is about,  
> who is
> from, etc, as long as you are who you say you are and if need be,  
> you can be
> contacted and/or mail can be returned (bounce).  In other words,  
> "play by
> the rules" of the transport and email system.

Fortunately, the policies established by the recipient can be much  
stronger than those established by the government or SMTP vendors.   
Playing by the rules should include not sending unsolicited bulk email.


> So to me, DKIM with a strong SSP checking concept, provides another  
> level of
> transaction consistency checking that may be used by the SMTP-DATA or
> POST-SMTP process to perform a final PAYLOAD check.  I don't  
> believe this
> checking should include a "REPUTATION" concept at this level.  I  
> think "DKIM
> signing consistency" is the key goal.

I am not against the repudiation aspect of non-signed messages. The  
objection results from not considering which domain introduced the  
message.  The current SSP is not compatible with current email  
practices and aimed specifically at establishing unfair reputation  
assessments on email-address domains, rather than signing-domains.   
Ask yourself why SSP precludes a signature that is is not bound to  
some email-address.  There could still be assertions that all servers  
within a domain signs all messages.  See I-D.crocker-csv-csa-00 for  
an example.


> In all cases, it is about verification of the transport process  
> entities and
> since we lack this with the current SMTP protocol, augmenting it  
> with DKIM
> should at the very least be strongly offer a consistency model, not  
> a weak
> one.

DKIM should identify the domain associated with the email message  
transport.  It is over-reaching, to say the least, when attempting to  
use this mechanism to verify the author of the message.  Leave that  
effort to OpenPGP and S/MIME.  By establishing the accountable  
domain, abuse can be handled in a more efficient manner than it is  
today.  This would also afford opportunistic identifications akin to  
that used with SSH.   I don't think this aspect has been given any  
consideration.

-Doug