Subject: RE: [ietf-dkim] Signalling DKIM support before DATA

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 8 Aug 2006 11:32:24 -0700

Host name conventions might be simple but they are not standard and not extensible.

What happens the next time we want to extend SMTP? 

> -----Original Message-----
> From: Douglas Otis [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 2:14 PM
> To: Hallam-Baker, Phillip
> Cc: Scott Kitterman; [email-masked]
> Subject: Re: [ietf-dkim] Signalling DKIM support before DATA
> 
> 
> On Aug 8, 2006, at 10:54 AM, Hallam-Baker, Phillip wrote:
> 
> > The way to do this (if it should be done) would be to use the SMTP 
> > extension mechanism.
> >
> > For example. Define a command option SDATA, Receiver 
> advertises it in 
> > response to EHLO, sender uses it to present signed data in place of 
> > DATA.
> >
> > Might be a better implementation but the point is we should use the 
> > SMTP extension mechanism not invent our own.
> 
> Something a bit simpler that would not require changing the 
> MTA code.  Use a host-name convention.  This would be 
> apparent at the EHLO without requiring negotiations.  In 
> essences, _dkim.mx01.example.com makes an assurance that:
>   1) this host-name will authenticate
>   2) a DKIM client policy can be applied
> 
> In conjunction with the DKIM client policy, there could also 
> be MAIL_FROM policies that offer name relationships.  For 
> example, this list might be a PTR RRset of names.  This might 
> be a lookup of the (_DKIM-MP.<mail-from-domain>, PTR) If a 
> truncation occurs, a subsequent lookup of the (<query- 
> domain>._DKIM-MP.<mail-from-domain>, PTR) extends this list
> indefinitely.
> 
> A domain name of "." might signal that the list is closed.
> 
> -Doug
> 
> 

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 8 Aug 2006 12:20:10 -0700

On Aug 8, 2006, at 11:32 AM, Hallam-Baker, Phillip wrote:

>> Something a bit simpler would not require changing the MTA code.   
>> Use a host-name convention.  This would be apparent at the EHLO  
>> without requiring negotiations.  In essences,  
>> _dkim.mx01.example.com makes an assurance that:
>> In conjunction with the DKIM client policy, there could also be  
>> MAIL_FROM policies that offer name relationships.  For example,  
>> this list might be a PTR RRset of names.  This might be a lookup  
>> of the (_DKIM-MP.<mail-from-domain>, PTR)  If a truncation occurs,  
>> a subsequent lookup of the (<query-domain>._DKIM-MP.<mail-from- 
>> domain>, PTR) extends this list indefinitely.
>>

This does not impact any SMTP extensions or the SMTP extension code.   
This convention is not intended to alter SMTP client/server behavior  
beyond just assuring the address authentication of the client.   
Perhaps "_dkim" is too specific, but DKIM client policy can still  
apply with whatever prefix that is selected for making the  
assurance.   One concern might be the garbage checks in the EHLO  
response.  Perhaps an '_' might prove problematic.  This would need  
to be tested.  A prefix of "DKIM-client" or perhaps just "SMTP- 
client" could be alternative choices.

In the domain of the client:
  DKIM-client-domain-policy: <all-prefix-assured-authentication>,  
<all-dkim-by-this-domain>, <all-dkim-by-any-domain>

Once the DKIM client is authenticated, a domain name relationship can  
be found in a policy for MAIL_FROM and the Signing Domain by using a  
rather concise policy name list.  Such as:

In the domain of the Mail_From:
  DKIM-client-mail-from-policy: <list-of-dkim-clients>, <open/closed>

In the domain of the signing domain:
  DKIM-client-signing-domain-policy: <list-of-dkim-clients>, <open/ 
closed>

-Doug