ietf-dkim
[Top] [All Lists]

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

2009-03-09 11:51:08
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.  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.

strong proponent for both SPF and DKIM (+ADSP) is that it provides a way
to scale beyond one to one out of band correspondence between sender and
receiver.

Once it scales, given the complexity - and the heavy push for
reputation, it will be extensively gamed.

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

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