ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs

2010-10-03 09:21:31
  On 10/2/10 11:13 PM, Michael Deutschmann wrote:
On Tue, 28 Sep 2010, Steve Atkins wrote:
Putting it in the List-Unsubscribe header that's not displayed
to recipients is pretty much equivalent to putting it in the X-Bamboozle
header that's not displayed to recipients when it comes to displaying
legally required content to recipients.
And there's the rub.  The problem is that a major threat we anticipate,
is that should a means be added to append a footer without breaking the
signature, bad guys will find short legitimate messages and replay them
with a footer containing spam.

Requiring the list garbage (and thus the spam) to be in X-Bamboozle:
headers would make this problem far less likely, since forgery recipients
would not likely see the spam.  But as you say, it is not adequate for the
lawyers.  They demand the same visibility a spammer would want.
Sorry for mixing threads, but in comparison the TPA-Label scheme does 
not depend upon new headers being added by the Author Domain.  
Additional authentication and header requirements applied against 
specific domains is to better isolate mail streams handled by specific 
services such as those of a mailing-list.

The intent of the third-party authorization with authentication methods 
and possible header requirements is to establish restrictive policies 
that can be applied against non-participating mailing-lists.  When a 
domain can not be confirmed via DKIM, then TLS, EHLO, or SPF 
verifications can be required instead, where additional header fields 
containing a specific domain (which can differ from the verified domain) 
can be used to confirm a specific service being authorized.

In general, once the mailing-list service has been confirmed, and the 
Author Domain knows the mailing-list confirms subscriptions, it would be 
reasonable to assume that messages from the list will be handled 
differently from those messages received directly.  The third-party 
authorization can also act as a fall-back method that might be desired 
to recover from damaged DKIM signatures.

Over time, signature damage should be less of an issue, but third-party 
services such as mailing-lists, e-vites, etc. can not be permitted using 
the simplistic ADSP restrictive assertions based solely upon the From 
header field.  The time before mailing-lists change their handling may 
be forever, since many recipients would like to see current practices 
continue, so the TPA-Label scheme is not expecting these services to change.

The TPA-Label scheme enables the practices needed to combat phishing.  
It would be a bad practice to utilize multiple sub or cousin domain 
lacking any acceptance restrictions.  It would not be reasonable to 
assume recipients are  able to make sense of the resulting mail streams, 
where the current trend shows their dissatisfaction with them not 
continuing to use the service.

-Doug


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