ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Handling the errata after the consensus call

2009-03-09 12:08:36
Suresh Ramasubramanian wrote:
On Mon, Mar 9, 2009 at 7:47 PM, MH Michael Hammer (5304) 
<MHammer(_at_)ag(_dot_)com> wrote:
  
I think your analogy to SPF is not quite correct. The SPF record itself
includes the ability to make a strong assertion (a record that ends with
-all but is not solely -all) as well as a means of indicating that one
does not send mail from a particular domain (publish only -all). The
base DKIM spec does not provide a way to specify one signs all email.
    

I'm happy to leave it at this stage -

  
6.3. Interpret results / apply local policy
(for example, when communicating with a peer who, by prior agreement, agrees 
to only send signed messages)
    

And as for this ..

  
That is your choice as a receiver. I'm not sympathetic to senders that
publish incorrect or broken SPF records just as I'm not sympathetic to
senders who publish incorrect DKIM records. This is no different than
someone publishing incorrect DNS records.
    

I have little or no sympathy for them. But broken spf records were
common enough, and then broken spf checking at various receiver sites
was even more common that we decided to remove our spf records in
2005.

If your sole goal in ADSP is "declare that domain x signs all mail"
then there could be a far simpler and more cut down version of ADSP
that'd fit the bill.  To wit - the "locked ADSP record" part.  

     I don't understand what this means.

And if
that's all that is required .. why then, I dont see why that part of
it cant be shoehorned into the base 4871 spec somehow - perhaps in
-bis as a newly defined tag.
  

the original IIM had bits of what is now ADSP in it. It was divided
and conquered mainly for processes reason. But in fact, they really
are two different pieces of software with pretty different goals. I really
don't see how merging them together into one document would change
either reality.

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

<Prev in Thread] Current Thread [Next in Thread>