ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] forward to friend, was besides mailing lists...

2010-05-05 10:36:51
On 5/5/10 1:23 PM, Jeff Macdonald wrote:
On Tue, May 4, 2010 at 8:27 PM, Douglas Otis<dotis(_at_)mail-abuse(_dot_)org> 
 wrote:
   
A) a hash label mechanism scales to any number of third-party services
within a single transaction.
     
I don't see how this would work with mailing lists. A domain owner
would have to know all the lists his users may want to be on. His
users would need to know to notify him when they joined a new list.
   
Jeff,

Use of ADSP "all" or "discardable" for transactional, institutional, or 
corporate messages would differentiate these domains from those for the 
general public.  These domains would be asserting restrictive ADSP 
policies to limit recipient exposure to confidence schemes by reducing 
acceptance of messages lacking an Author Domain Signature.  
Unfortunately, limiting acceptance of messages lacking these signatures 
disrupts mailing-list participation and makes the desired protections 
generally impractical.

Before ADSP can be broadly utilized, a solution to mitigate message loss 
with acceptable third-party services is needed.  This could mean 
automating the publication of hash labels from user requests.  In most 
cases, sharing keys would not be practical.  Unilateral hash label 
authorizations can be specifically for a domain with messages having 
headers indicative of a mailing-list, for example.  The third-party 
authorization draft also allows authorizations to be managed by other 
domains through use of DNAME at the "_adsp." node.  An important aspect 
of this mitigation is that it requires the same overhead used to collect 
the ADSP policy.

-Doug




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