ietf-dkim
[Top] [All Lists]

[ietf-dkim] dkim-lists draft (was Re: Why mailing lists should strip DKIM signatures)

2010-06-01 03:37:29
The masochistic side of me spent some time going through this entire thread 
over the long weekend to fish out the pieces that can be folded into the lists 
draft.  This is a summary of that sifting, which I'm using to generate the -01 
draft.

Please, folks, change the Subject: field for the ADSP-specific part of this 
discussion.  The part of the thread that has to do with what we can tell list 
participants and software developers now must be based on RFC4871 and RFC5617, 
and not on what we think either of those things should have been in the first 
place.  The rest is a totally different conversation, unless we think we need 
to fix those before any list practices get discussed, which I don't believe to 
be the case.

Also, please constrain follow-ups to this posting (with this Subject:) to the 
lists draft, and in particular, +1s, proposed changes to wording, or sections 
that should be added, rearranged or removed.  The more specific you are, the 
more useful the contribution; stuff like "you should say more/less about ADSP" 
isn't really meaningful.

In several places, where there have been suggestions to remove some text from 
the draft because it conveys a bad idea, I intend to leave it in accompanied by 
text explaining that it's a bad idea and why.  I believe it's better to close 
off such a path from a new participant than it is to leave it unexplored.

An interesting point came up late in the thread, and that is a challenge to our 
well-established mantra that the MUA is the slowest thing to change.  With 
Gmail and Yahoo being active-yet-silent participants in all this, and I think 
we can presume the likes of AOL is included, and even open source solutions 
like Horde might not be far behind, is that all still true?  If not, then 
perhaps the lists document might suggest some MUA improvements to assist with 
all of this effort.  Or maybe a separate effort can be started that recommends 
common MUA changes to make them more DKIM-aware and put some of all this work 
to better use.

Finally, a question: So that an MLM can proudly exclaim "We are RFCxxxx 
compliant!" and have it be meaningful, should this document seek the status of 
a BCP, or is Informational sufficient?

Now then:

-----Original Message----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine
Sent: Friday, April 23, 2010 9:41 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Cc: dcrocker(_at_)bbiw(_dot_)net
Subject: Re: [ietf-dkim] Why mailing lists should strip DKIM signatures

[...]
There's no new semantics, deep or othterwise.  Yahoo is treating the
signature as an assertion of responsibility -- it has my signature,
the recipient complained about it, they have reason to think I'm not
evil, so they sent me the complaint.  All that is fine, but the
problem is that for list mail, I'm not the one who can do anything
about it.

I kind of don't buy this as a DKIM-specific problem.  Even before DKIM, a 
provider might decide to send a copy of the complaint report to you since 
you're in the From: even though there's a Sender: or the IP address matched an 
FBL registration or something.  It might be useless, sure.  But it's not a 
fault specifically of DKIM; it's a questionable FBL choice.

If a list adds its own signature and leaves the contributor's, now
it's up to heuristics by the recipient to guess what to do.  For list
mail, the correct guess is to treat the list as responsible.  Wouldn't
it be a better idea to avoid the guessing?

Again, pre-DKIM, that could still happen.

But in the DKIM world, the FBL could take this apparent heuristic one step 
further and identify the list's signature by matching it to other domains like 
the one in List-Post: or such, and thus not bother the author since, as you 
say, she/he can't do anything about it.

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Steve Atkins
Sent: Friday, April 23, 2010 10:07 AM
To: IETF-DKIM WG
Subject: Re: [ietf-dkim] Why mailing lists should strip DKIM signatures

[...]
 Wouldn't
it be a better idea to avoid the guessing?

Yes, by notifying all the responsible parties who have set up a
DKIM based FBL and who have valid DKIM signatures on the
message.

+1 (and there were at least two other +1s)

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Ian Eiloart
Sent: Wednesday, April 28, 2010 2:19 AM
To: McDowell, Brett; dcrocker(_at_)bbiw(_dot_)net
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should 
strip DKIM signatures

[...]

Mailman doesn't check DKIM signatures, or add them. Quite properly, in
my
opinion, this is regarded as the business of the local MTA, not the MLM
software.

I find this a particularly important point to framing of the problem.  And this 
is in part exactly what RFC5451 was for.  Unfortunately to provide a lists BCP 
in general, we have to consider that some MLMs will be forced to do that work 
as their MTAs are not DKIM-aware, so we need to be general about this (i.e. say 
that verification should be done, but not specify which agent in the local 
chain does it).

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of MH Michael 
Hammer (5304)
Sent: Wednesday, April 28, 2010 8:03 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should 
strip DKIM signatures

[...]

2) One possible recommendation to list managers is that if a message to
the list is DKIM signed AND has an ADSP discardable policy AND the
signature cannot be maintained intact then the list should bounce the
message.

We seem to have rough consensus on this point, and it's in the draft.

3) Is there a way for us (perhaps in a future version) to provide for
some sort of "encapsulation" that will allow the original
signature/message to be maintained even as the list does certain (as
yet
unspecified) actions which might currently break the signature? Just
blue skying here.

Technically yes: The MLM could MIME-ify the original message as a 
message/rfc822 part in a larger message that contains anything else it cares to 
add -- headers, footers, new header fields, whatever -- and that encapsulated 
message could include its original author signature, which presumably would 
continue to validate if evaluated over that encapsulated message.  That would 
probably solve a lot of problems, although it's ironic that we'd be encouraging 
an even more substantial change to the message to get around the problem of 
messages being changed.

But as I recall, we have text in various places saying DKIM signatures inside 
MIME parts shouldn't be evaluated anyway.  Maybe that should be revisited given 
the possible value of it in this context.

4) I recognize the chorus which says "mail lists have always done
things
a certain way and who are you to tell us how or what we have to do".
Having given that recognition, in creating an authentication model it
seems self defeating not to provide mechanisms for the authentication
to
survive things like maillists (for those maillists/software providers
willing to adopt whatever we come up with). Those lists which have
always done thigns a certain way and wish to continue could do so - no
harm no foul.

That would be ideal, but we've created an authentication mechanism that relies 
on MLMs not doing things they've been doing for a long time.  Maybe a mechanism 
like what you're describing could be concocted, but DKIM isn't it.  The best 
shot at this would be an alternate canonicalization, which has been proposed, 
that is more likely to survive the myriad modifications that are described in 
the lists draft (and others we may not have mentioned), but specifying, let 
alone implementing, such a thing would be a small nightmare.

I suspect if we want to design an authentication mechanism that is specifically 
transparent to lists, we need to start over.

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Ian Eiloart
Sent: Tuesday, May 04, 2010 1:48 AM
To: DKIM List
Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

[...]
I agree it's hypothetically possible, but have you ever seen an actual
need for this in practice, a list where the recipients filter out
messages that a more competently managed list would have rejected?

I've seen spam posted to mailing lists. Recently, I've seen lists
targetted
in more intelligent ways by spammers. For example, by using sender
addresses in the domain of the list (quite a useful way of attacking
academic lists, which tend to have lots of local users, but some non-
local).

Though I've not witnessed this myself, I think it stands to become a more 
common attack vector if it is found to be even marginally successful, because 
it's free to try.

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Alessandro 
Vesely
Sent: Tuesday, May 18, 2010 5:55 AM
To: John Levine
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Lists "BCP" draft available

[...]

Yes, of course.  The signature means that this message really truly
came from the mailing list, as opposed to being a random piece of
spam
that happened to resemble list mail.

+1. However, may I ask how does the verifier know which signature is
the one that belongs to the list? I can think of

* look at the MAIL FROM domain, à la SPF (breaks forwarding),
* have the list's domain in a white list (requires maintenance),
* use some of the "List-*" fields (which one?)

Apparently, section 5.4 doesn't cover this point.

Quite right.  And at the risk of doing something drastic like tying "d=" to 
something else in the message, I suggest the latter.  (Dave suggested something 
like that, and it was +1'd at least once anyway.)

And with that, draft-kucherawy-dkim-lists-01 has been posted for your perusal 
and feedback.  This thread was enormous so it's possible I missed something.  
If so, please do point it out.

-MSK


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

<Prev in Thread] Current Thread [Next in Thread>