ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Consensus point on ADSP

2009-03-31 12:46:46

On Mar 30, 2009, at 10:13 PM, Jim Fenton wrote:

Concern #2 in my message has to do with messages where the signing  
address is a different address in the same domain as the From  
address.  The correct test case is:

From someone(_at_)foo(_dot_)example
Valid signature from ietf-examples(_at_)foo(_dot_)example

Let's also use "all" instead of "discardable" as the test case  
because it's the harder problem to solve.  As you point out, the  
mailing list should be acting on the Discardable practice rather  
than trying to send the message to the list.

It should not matter whether "all" or "discardable" is used since the  
signature has been applied by the correct domain.

Let's say that ietf-examples(_at_)foo(_dot_)example is a mailing list that 
re- 
signs mail sent to the list (or it could be a forwarder or similar  
agent).  foo.example's mail server gets a message from an address in  
the same domain, someone(_at_)foo(_dot_)example, that has no Author Signature 
 
or has a broken one.  In accordance with the domain's policy, it  
subjects the message to additional scrutiny because of the "all"  
practices and lack of an Author Signature.  The message passes this  
test and is sent to the mailing list manager.

A best practice should only annotate full email-addresses when  
included within the i= value.  In the case of the mailing-list, 
"someone(_at_)foo(_dot_)example(_dot_)com 
" has a valid author signature (one by the correct domain), but the i=  
value does not affirm that the signature was added on behalf of the  
author.  Normal semantics established for all DKIM signatures will  
differentiate these two message sources.

At this point, the mailing list manager would normally sign the  
message.  Let's examine this with the i= and d= choices:

Using i= as the basis for Author Signature, the list can sign the  
message, and the eventual verifier/assessor that does an ADSP check  
will see that it (still) lacks an Author Signature since 
ietf-examples(_at_)foo(_dot_)example 
 does not match someone(_at_)foo(_dot_)example(_dot_)

This would be wrong.  The Author Signature should only require a  
signature by the correct domain, and then expect the receiver to  
depend upon the i= value to differentiate on whose behalf the message  
was signed.

Using d= as the basis for Author Signature, if the list signs the  
message, an eventual verifier/assessor will erroneously see that  
signature as an Author Signature, and therefore might not give the  
message the desired treatment.

The desired treatment is always under the control of the signing  
domain.  The domain retains control when limiting valid "author  
signatures" to being by domains at or above the email-address domain.

Another option would be for the mailing list manager not to sign  
this message, which means it needs to do a special case not to sign  
messages if they're from the same domain and lack an Author  
Signature.  This is certainly possible, but would be more  
challenging if the MTA manages many domains.  I also think it's the  
wrong place to solve the problem.

The cleanest solution would be for the mailing-list to include  
"i=ietf-examples(_at_)foo(_dot_)example(_dot_)com 
" rather than "i=someone(_at_)foo(_dot_)example(_dot_)com".  An assessor can 
easily  
determine that the message was on behalf of the mailing-list rather  
than someone at "foo.example.com".   There does not appear to be any  
problem not handled by existing DKIM semantics.

It's up to the WG to decide whether this is a problem that deserves  
a solution or whether it's too much of a corner case to bother with  
(mailing list manager with users in the same domain that uses  
ADSP=all).  I do not like the idea of "just change someone's domain"  
or "just change the list's domain" because it has always been DKIM's  
goal to operate with existing addresses.

There does not appear to be any corner case?

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html