[ietf-dkim] Consensus point on ADSP

[Hector Santos]

Mark Delany wrote:
>>>>   Note:   ADSP is incompatible with valid DKIM usage in which a  
>>>> signer
>>>>      uses "i=" with values that are not the same as addresses in  
>>>> mail
>>>>      headers.  In that case, a possible workaround could be to add a
>>>>      second DKIM signature a "d=" value that matches the Author
>>>>      Address, but no "i=".
>>>>
>> I'll start by proposing text that we could use if we adopted an
>> alternate definition of Author Signature based on the d= value only.
>> Then I'll describe what I think we'll lose by going to that  
>> definition.
> 
> Given that i= is an arbitrary value assigned by the signer, the  
> question to me is what value does it add beyond what signed RFC2822  
> headers can do just as well. Eg, why not set an rfc2822.Sender Field  
> and sign that rather than invent i=?
> 
> IOW, what is the value-add in inventing yet another identity called  
> DKIM.i= when we already have rfc2822.From, rfc2822.sender,  
> rfc2822.resent-from, rfc2822.resent-sender and rfc2821.mailfrom?
> 
> Are you suggesting that DKIM.i= should have preference over signed  
> RFC2822 identifiers?
> 
Good points Mark.

I think it may help if we can take a (small) step back into the 
balcony, to better understand what ADSP was designed to over.

Without getting into details, can we summarize what the goals of ADSP are?

 From my POV, I see three goals:

   1) Provide a 1st party signature requirement authority.

   2) Provide a new technical (and indirectly legal) justification
      for the discarding of SMTP accepted message.

      RFC 5321 has  new semantics which relaxes the several decade old
      tradition of requiring a bounce notification. Prior specs
      did not have this relaxation.  See RF5321 6.2.

      For systems that are planning to process DKIM online
      (at DATA stage), this was never an issue.  ADSP will
      help systems that always accept mail and process in
      in a delayed fashion.

   3) Lay the framework for future more advanced (beyond goal 1)
      policy mechanisms, including 3rd party signatures.

It would of been my preference to see a simple YES/NO "Allow 3rd 
party" signature policy that might cater to email services like
gmail.com which allows non-gmail but verified author from addresses
to be used with d=gmail.com signings.

Personally, the ADSP response is to light. If people are concern about 
too many ADSP queries, then at the very least give it more data to be 
returned that can be useful.   I don't think we can cover all 3rd 
party scenarios, but a simple 3rd party policy with a tag contains X 
limited domains would be very useful.

     DKIM=DISCARDABLE; 3PS=gmail.com, mipassoc.org

that will say that all my winserver.com mail will be signed either by 
one of the following domains:

     d=winserver.com  (default signer based on from.domain)
     d=gmail.com
     d=mipassoc.org

I doubt a major amount of the domains will ever need more than 512 
bytes yet alone 80 or 160 bytes! But even so, for these rare larger 
needs, DNS is designed to handle a streaming request when needed.

No "opague" i= to confuse what is being attempted and valid signatures 
will probably still need reputation and trust services.  Good 
signatures is not enough to trump security.

But this will at least allow for a good segment of market to use DKIM 
in 1st and 3rd party authorized manner.

Its not ideal, but I think it would be better what we have now with 
ADSP which is so limited even the authors believe its worthless.

Well, lets get it some reason to exist.


-- 
Sincerely

Hector Santos
http://www.santronics.com