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

From: Michael Deutschmann <[email-masked]>
Date: Sat, 2 Oct 2010 23:13:55 -0700 (PDT)

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.

DKIM has the unfortunate problem of coming late to the party.  If DKIM
had got there first, before it became near universal to add footers,
mailing lists would have been faced with unacceptable delivery rates when
they tried, and it would be seen as completely *their fault*.  If the
lawyers did persist, all the list-managers could do is shut down until all
their clients hand over their keys....

But DKIM presently has the lawyer's car parked in front of its driveway,
and can't complain because that car parked before the house was built.

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sun, 03 Oct 2010 07:18:32 -0700

> 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

---

From: "John R. Levine" <[email-masked]>
Date: 3 Oct 2010 10:50:33 -0400

I'm really having trouble understanding what problem you're trying to 
solve here.  Could you describe it in under 100 words?

I think I understand the problems that people see with lists and ADSP, so 
please just explain what the problem is with lists and DKIM.  You can 
assume that lists will put DKIM signatures their outgoing mail, to help 
recipients recognize mail from the list.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sun, 03 Oct 2010 11:15:35 -0400

John R. Levine wrote:
> I think I understand the problems that people see with lists and ADSP, 
> so please just explain what the problem is with lists and DKIM.  You can 

How does it help "recipients recognize mail from the list?"

In what way does it do this?

All we heard is "words" that this is the type of thing a user wants.

In other words, John, maybe it would be "useful" for example, using my 
junk gmail.com account, to have a gmail.com user setting or filter 
that says:

    IF MAIL IS SIGNED,  AND
    IF LIST-ID is "ietf-dkim.mipassoc.org"
    THEN MOVE TO INBOX WITH 5 STARS

If this is what you speak of, then great. I would like for the ESP/ISP 
to offer user rules like this.

But I would like for may to have a more generic rule:

    IF MAIL IS SIGNED, AND
    IF ASL/ATPS/TPA is FAIL
    THEN MOVE/KEEP TO SPAM BOX

or

    IF MAIL IS NOT SIGNED, AND
    IF ASL/ATPS/TPA is FAIL
    THEN MOVE/KEEP TO REALLY BAD SPAM BOX

All I am hearing is "words", lets begin translate this into sound 
rules that people can use.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Douglas Otis <[email-masked]>
Date: Sun, 03 Oct 2010 09:28:57 -0700

>> solve here.  Could you describe it in under 100 words?
Provide a restrictive acceptance policy for Author Domains so they are 
able to allow domain specific exceptions where possibly different domain 
authentication or authorization might be used, and where specific header 
fields such as List-ID or Sender headers may be required to help further 
isolate different mail-streams within the authorized domain.

This mechanism is to avoid the bad practice of using sub or cousin 
domains when confronting a phishing problem with the application of 
restrictive acceptance policies.  This approach should also improve 
delivery integrity over using the simplistic ADSP discardable assertion, 
even when no other third-party domain is being authorized.

>      THEN MOVE TO INBOX WITH 5 STARS
IMHO, it would be a mistake to only permit third-party services that 
employ DKIM and then only request rejection of non-complaint messages.  
Alternative authentication or authorization schemes could be allowed to 
better encompass existing services that enterprise domains might wish to 
use.  By not DKIM signing with the Author Domain, the third-party 
authorization could even then stipulate use of TLS as an acceptance 
basis.  The TPA-Label scheme would allow email to gracefully transition 
to different methods.
> rules that people can use.

Domains being flooded with phishing attacks have an incentive to offer 
additional information to assist in the evaluation of messages 
containing their Author Domain.  As such, it would not be the ISP 
offering the rules.  However, there are any number of organizations able 
to assist in the publishing and monitoring of these Third-Party 
services.  The problem with VBR is that it only considered the Author 
Domain independent of an informal third-party domain service that might 
be desired, where publishing public keys with pre-arranged selectors is 
not a practical solution.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 04 Oct 2010 11:43:10 +0100

> with a footer containing spam.

I would suppose that an added footer will usually take the form of an  
extra part with Disposition: inline in a multipart/mixed. Insofar as this  
is not the current convention it ought to be (if only so that users can  
filter out those annoying footers).

In that case, the clean solution, in lieu of the little-used 'l=...',  
would be to have some mechanism for speciffying exactly which  
parts/atachments of a messsage had been included in the signature.

Whether it is now too late to add such a fundamental enhancement to DKIM  
is an interesting question, even though it might enable various useful  
possibilities. But at least it ought to be looked into.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html