ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Lists "BCP" draft available

2010-06-14 12:51:43
On 6/14/10 7:07 AM, John R. Levine wrote:
I would appreciate you describing in detail this "collateral damage". If
it involves discarding of mail from the domain in question then it is
not collateral. What else do you have for us?
     
It's collateral to the extent that one's users complain about not getting
perfectly good mail.  "Your friend's mail admins glorp plugh ADSP grungle
bleep" isn't a very satisfactory response to users.  Pointing to
legalistic language in some web page with a three letter acronym won't
help.

There's also the problems that have been noted with people bouncing off
mailing lists.  Yes, in that case both ends are doing the wrong thing, but
if either did the right thing and forgot about ADSP we wouldn't have the
problem.
   
John,

How will "doing the right thing" with ADSP resolve mailing list abuse?
The sooner we stop wasting time trying to fix ADSP and start getting
shared drop lists, the sooner there's some hope of using DKIM to keep
simple forgeries out of peoples' inboxes.
   
Is a shared-drop list an improved "discardable" list, and what does 
"discardable" mean in respect to Author Domain Signing Policy?  Should 
all critical and potentially phished transactions be marked 
"discardable" and not generate DSN?"  Should "all" be receive the same 
delivery treatment as "discardable"?   Does "discardable" mean something 
other "all" and no NDNs?  Should ADSP also indicate whether third-party 
services are being used?

Reputation alone will not resolve abuse issues with a steady increase of 
abuse coming from reputable sources, and reputation certainly will not 
resolve a phishing issue, especially when senders are compelled to 
change email domains without a means to specifically and unilaterally 
authorize third-parties.  Any general third-party authorization would 
increase abuse emitted by mailing lists, which would prove counter 
productive, especially without a defined method to identify third-party 
services.

Of course, it remains possible for senders to make such a list 
themselves and to note how third-party services can be identified.  An 
authorization scheme would leave "drop lists" control in the hands of 
the senders being trusted, or in the hands of their delegated authority 
(detail will be added in the draft to explain this function).

-Doug


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