ietf-dkim
[Top] [All Lists]

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

2010-07-25 04:47:29
(More review of old chatter...)

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of J.D. Falk
Sent: Tuesday, June 22, 2010 11:07 AM
To: DKIM List
Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-
00 (fwd)

I still don't get why it's ok for John Levine to publish a list which
says that it's ok to discard unsigned mail from paypal.com, but st00pid
for paypal.com to publish the same thing. That is the essence of his
jihad against adsp.

Because presumably verifiers will trust John's process for compiling
this list more than they'd trust any random schmoe with the ability to
create TXT records.

(If paypal were representative of all domains, this wouldn't be a
concern.)

Personally, I think we'll need lists like this for a while in order to
gain more experience and determine best practices, and THEN we can
decide whether to change (or even scrap) ADSP to reflect those
practices.

I've engaged some of you off-list trying to understand why ADSP is 
fundamentally different than the private agreements known to exist between 
PayPal and some large email service providers.  I get the philosophical 
arguments, but from a standards body perspective I remain stymied.

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?

The whole point of standards is to publish a mechanism for accomplishing 
something so that two parties that have never interacted in that specific way 
before can do so without some kind of out-of-band prior arrangement.  In that 
sense these statements about ADSP create some cognitive dissonance that I 
haven't been able to resolve yet.

-MSK

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