ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)

2010-07-25 10:53:24
I'm finally beginning to buy that something akin to DBR may be
necessary, but it's still weird to me that the point is that the
average sysadmin can't be trusted to do ADSP right.  But then why,
for example, can he/she be trusted to do DNS or SMTP or even TCP/IP
right without some sort of vouching or reference service asserting
competence?

It's a perfectly reasonable question.  To me, the problem with ADSP is
that if we imagine the process of delivering a message to be a running
race, ADSP is a gun pointed at your foot offered to you at the finish
line.

As we all know, admins can and do screw up anything, but with most
mistakes, the damage directly affects them.  If you screw up your MX,
your own incoming mail won't work.  If you screw up your ADSP, your
mail will work fine, while other people's mail systems will
mysteriously lose mail.

Experience with SPF -all suggests that people who get it wrong will
insist that it's somenoe else's problem to fix, by baroque workarounds
like SRS and recent proposals to intuit that a message with a broken
signature is coming through a legitimate mailing list and that the
list verified the signature. Also, regardless of what the spec says,
few recipients would ever use it as anything more than a mild hint to
a scoring system.

Standards work well when the benefit from implementing them correctly
is shared, and the pain of screwing up is also shared.  ADSP offers
trivial benefits to the vast majority of domains that are not phishing
targets and to the recipients of mail from them, and pain that
predominantly falls on the other end from the one that screwed up.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html