On Feb 2, 2007, at 8:45 AM, Michael Thomas wrote:

Um, Cisco participates extensively in external mailing list for
standards bodies. And we're not trying to "force" anything; I speak for
myself as one of the authors of the spec.

   Mike

Um, then PGP sign your messages and we will call it all good. =)

Your interest in DKIM and Cisco's interest in DKIM are the same to me
cause you are posting with a Cisco.com email address and because
Cisco is one of the companies pushing the spec.

Sorry, I just don't see DKIM as a good solution for the problem. But
that's just my personal opinion.

jon

I really do not think that a From address should be changed. This is where "Sender" comes in (and Sender is more "behind the scenes" and less important to the end user). So what Mailman does not, I believe, is correct: keep From set to the person who sent the email and set Sender to reflect that the mail list is the sender.

I also do agree with Barry that the responsible party for an email from a mailing list should be the mail list and not the original person who sent it. If you are subscribed to a mailing list, you need to be able to verify that the message indeed came from the list itself (and you can do this if the mail list host adds its own DKIM sig). Ideally, the mail list host would do the initial DKIM check from the original person sending the message and mark the header to reflect that it passed, and then the receiver's host can check the DKIM sig from the mail list. This "chain" of verification would be sufficient to verify the message itself.

Now, what about the original DKIM sig...? If left in the header, the end receiver might try to check it and get a bad match, even if the newer sig added by the mail list would verify. Yeah, I know that a "bad sig is like no sig", but this just seems ugly. Then there's the additional problem of the milter not re-signing if there exists a sig already (these were the two motivations for cleansing the sigs from the mail in Mailman).

Bottom line is that if we let the system do two separate DKIM checks (orig sender -> mail list, and then mail list -> receiver), it avoids all the issues of changes made to the message. Somehow this seems more clean to me.

				-Joe

Michael Thomas wrote:

Barry Warsaw wrote:

...

I'm not sure how much I like that anyway, so comments are definitely welcome. After mulling over this post for an hour ;) I'm starting to believe that it's the mailing list system that needs to vouch for the messages its recipients receive. Of course, it could be Mailman doing the DKIM signing, or it could be Mailman's outgoing MTA, etc. But, ISTM Mailman is ultimately deciding what goes into the list copy, so it is responsible for it.

The big problem with the way that mailing lists interact is that in some scenarios they're not terribly different from a .forward file, and in other cases they for all intents and purposes completely originating a completely new message, cf translators, digestors, etc, etc. The _problems_ arise when the mailing list keeps the 822.From address intact from the original submitter. For things like digests it pretty much does the right thing: it sets the 2822.From to be something related to the list. For normal list traffic it keeps the original 2822.From.

What it seems to me is that maybe we should look close at that behavior of when a list ought to take From: responsibility for a message ala digests. When a list completely mangles a message, is it really reasonable for it to keep acting as if it came from the original From: address? There's probably not a bright line here, but maybe we should force the issue with DKIM in that something that mangles a message in a way that it's impossible to have the original signature survive to... set the From: address to something list related so that it's the lists reputation that's considered rather than getting caught up in no-man's land of "it looks like a forgery because we/they sign all mail, but..."

   Mike

Michael Thomas writes:

What it seems to me is that maybe we should look close at that behavior of when a list ought to take From: responsibility for a message ala digests. When a list completely mangles a message, is it really reasonable for it to keep acting as if it came from the original From: address? There's probably not a bright line here, but maybe we should force the issue with DKIM

"Force"?! You've got the tail wagging the dog here.

From is an *author* header, not property of the MTA. It indicates the *author*, not the editor or delivery agency. If the author approves the message munging (and this is implicit in Internet custom or even the mailing lists terms of use in most cases), DKIM MUST live with it. So there's your bright red line.

I think this points in the exact opposite direction from what you claim: users already understand what From means in the mailing list context, so if From and the DKIM signature are in conflict, the latter SHOULD be adjusted. Since the ML is not in possession of the relevant key, removal is the only option.

The very basic test I use is what's in the From: address. That's the thing that's pretty universally displayed and one that users are most likely to grok. Anything beyond From, and you've probably lost at least half of the user population at least.

If the users don't know the difference between "From" and "Sender", they have little chance of using DKIM as intended *except in the case where From == Sender* (or they are in the same DKIM domain). Doesn't this amount to saying "we don't know what DKIM BCP for mailing lists is---that will be determined by the ability of average users to grok RFC 2822 (and we believe that is quite low)".

So the bottom line is that a valid third party signature from, say, a mailing list is not safe a priori. It requires special handling by the ultimate receiver in the form of a trust relationship with that domain which needs be done out of band. The same is not of a first party signature because you're only vouching for yourself which is already as good you trust that domain (or not).

That's specious IMO. Technically, when the mailing list signs a message, it's vouching for that message as the mailing list re-sent it. This is exactly the same as for the originating domain. From the UI standpoint, if a DKIM-enabled MUA doesn't present information (including their roles as originators or resenders) about *all* of the "DKIM senders" to the user, it is hopelessly broken for use in a resending environment.

DKIM can help here. Eg, if DKIM-enabled clients are told that they SHOULD recognize RFC 2369 headers and try to match the list identity to the DKIM signature, and DKIM is extended to provide for resenders (including lists that move domains---the List-ID will have a different domain then).

Again, your argument bites the other way around. I think it's a reasonable presumption that the user has *already* established the relevant trust relationship with the mailing list, because either the list is run by the user's employer (or similar), or the user opted in. Certainly you can presume that of any mailing list willing to cooperate with DKIM!

I think that all of this really points to issues that need to be resolved in the DKIM specification, not with mailing lists or any other existing infrastructure. It's DKIM that needs to establish BCPs for user interface and user education, not other parts of the infrastructure that need to cover for DKIM's weaknesses at this point. Once DKIM has established its own BCPs, and technical analysis shows that it *requires* cooperation with other protocols to resolve important ambiguities, *then* it's time to ask MLMs etc to help with those issues.

I'm afraid that intransigence from the mailing list community is likely to really backfire. Mailing list traffic is an extremely small percentage of traffic, and most admins are likely to just ignore the collateral damage if it's too much a nuisance. Don't get me wrong: I spend far too much of my day on mailing lists and would really like things to work out. But hard line positions in the face of thorny engineering tradeoffs doesn't help.

   Mike

Hmm, not sure where that statistic comes from, but I'd say 25% of the mail that enters my couple hundred domains I admin originates from mailing lists. They may not necessarily be discussion lists like this (although I'd say perhaps 5-10% is), but also the "targeted marketing" types are also using mailing lists.

Bob

Michael Thomas writes:

I'm afraid that intransigence from the mailing list community is likely to really backfire. Mailing list traffic is an extremely small percentage of traffic, and most admins are likely to just ignore the collateral damage if it's too much a nuisance.

We know. Mailing lists have always been vulnerable to such collateral damage by their very nature as bulk transports.

Don't get me wrong: I spend far too much of my day on mailing lists and would really like things to work out. But hard line positions in the face of thorny engineering tradeoffs doesn't help.

First, I don't speak for the Mailman community. I fully expect that the Mailman developers will recognize that they have no choice but to provide DKIM-friendliness options.

Second, you can call me hardline if you like, but you're advocating that we abandon RFC 2822's From-is-not-Sender semantics. You're advocating that the legitimate editorial role currently performed by many mailing lists (analogous to the Editor reflowing lines and fixing typos in letters submitted for the Op-Ed page) be reduced to mere relaying. This is pretty radical stuff, if you ask me.

The fact that you talk about the serious damage being done by mailing lists removing signatures leads me to wonder what was happening to unsigned posts on those mailing lists before they upgraded to a recent Mailman. And the fact that you completely ignore the existing trust relationship that mailing lists have with their members in discussing third party signatures makes me wonder how carefully you and your colleagues have really thought about mailing lists. (Especially since that trust relationship has been explicitly pointed out!)

So I just don't see an existing best practice here. I see an attempt to develop an extension to an existing draft based purely on theory, and theory not really grounded in current practice, to boot. I worry that an attempt to make Mailman conform to DKIM rather than write list-friendly wording into the standard will cause the collateral damage to be set in stone.

Michael Thomas writes:

Let's be clear that I'm advocating a dialog here,

In some sense, there's very little room for dialog, unless it involves substantial amendments to DKIM. This is inherent in the design: the whole message is signed. Preserve it nearly verbatim or break the signature.

This need not be a problem, however, as long as users can be taught not to panic because one signature doesn't verify. See below.

I'm hoping that we can come up with some finesse.

It's not obvious to me that a finesse is necessary or desirable. IMO, the right answer is for mailing lists to sign the posts that pass through them, and to publish a BCP that extols the manifold advantages to lazy admins<wink> of vetting a bunch of mailing lists and then trusting the signatures of the trustworthy ones.

The transition period may be painful, but so is spam.

In any case, if you have some ideas about what list friendly wording is, I'd be happy to hear it.

After reading dkim-base-8, things are a lot clearer. Specifically, the updated Section 4 makes it clear that there's no reason why a mailing list is a second-class citizen:

Of course, a message might also have multiple signatures because it passed through multiple signers. A common case is expected to be that of a signed message that passes through a mailing list that also signs all messages. Assuming both of those signatures verify, a recipient might choose to accept the message if either of those signatures were known to come from trusted sources.

While I could wish for a stronger endorsement, I realize that is about as strong an endorsement as you'll find in an informative section in a standards-track RFC. I guess in the BCP I'd like to see that language (at least) repeated with encouragement to implementers to (eg) have verifiers look for a mailing list signature if RFC 2369 headers are present. The heuristic being the one I've been hammering on: if your users are subscribed to a mailing list, they evidently trust it to a greater or lesser degree. And of course users and ISPs should be encouraged to use MUAs and servers that employ verifiers with those features.

By the way: *WARNING* Most of the links from the DKIM site point to version dkim-base-7b, while the current version is dkim-base-8. The latter has a much more satisfactory Section 4 (on multiple signatures). Most recent version (currently v8) is here:

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=14210

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 3, 2007, at 12:43 AM, Stephen J. Turnbull wrote:

I think this points in the exact opposite direction from what you claim: users already understand what From means in the mailing list context, so if From and the DKIM signature are in conflict, the latter SHOULD be adjusted. Since the ML is not in possession of the relevant key, removal is the only option.

ISTM that the DKIM spec is in agreement with you Stephen:

http://www.dkim.org/specs/draft-ietf-dkim-overview-02.html#anchor61

I think we can say Mailman is in compliance with choice #3 in this
list. I will also agree with the Note at the beginning of this
section that this "may be controversial". Indeed.

...

The very basic test I use is what's in the From: address. That's the thing that's pretty universally displayed and one that users are most likely to grok. Anything beyond From, and you've probably lost at least half of the user population at least.

If the users don't know the difference between "From" and "Sender", they have little chance of using DKIM as intended *except in the case where From == Sender* (or they are in the same DKIM domain). Doesn't this amount to saying "we don't know what DKIM BCP for mailing lists is---that will be determined by the ability of average users to grok RFC 2822 (and we believe that is quite low)".

I'll just also comment that it is controversial that Mailman is
adding a Sender header at all to outbound copies. We've had this
discussion in the past (no time to find the archive threads), and
IIRC we've decided that the relevant RFCs are ambiguous wrt mailing
list best practices. No surprise there, but we also decided that
adding Sender is a valid interpretation of the RFCs and the most
reasonable thing for us to be doing.

However, Sender isn't useful to people because they never see it.
Every MUA I've ever used simply displays the From header as who the
message was originally written by, and I don't think we would provide
clarity to our users if we munged that, under normal circumstances.
We /have/ to do so for digests or anonymized lists, but that's a
different situation.

DKIM can help here. Eg, if DKIM-enabled clients are told that they SHOULD recognize RFC 2369 headers and try to match the list identity to the DKIM signature, and DKIM is extended to provide for resenders (including lists that move domains---the List-ID will have a different domain then).

Agreed.

Again, your argument bites the other way around. I think it's a reasonable presumption that the user has *already* established the relevant trust relationship with the mailing list, because either the list is run by the user's employer (or similar), or the user opted in. Certainly you can presume that of any mailing list willing to cooperate with DKIM!

Agreed! How many of you have trust relationships with the other
members of this list? What about your trust relationship with
python.org, and this mailing list in particular?

I think that all of this really points to issues that need to be resolved in the DKIM specification, not with mailing lists or any other existing infrastructure. It's DKIM that needs to establish BCPs for user interface and user education, not other parts of the infrastructure that need to cover for DKIM's weaknesses at this point. Once DKIM has established its own BCPs, and technical analysis shows that it *requires* cooperation with other protocols to resolve important ambiguities, *then* it's time to ask MLMs etc to help with those issues.

Agreed!

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcjzwHEjvBPtnXfVAQLPOgP/awMIcfI7J92Z9Lqvt7MYdm1mMFoHdpzU VjO8RBTf7d3468TtCVowwKskduRcQazbsXAHnvl4FfoIqVlVI/mnktD0Tr1N0/3h 56CIu5cVbrTZc1wISPvBhs2zzGZNRxy7BfkbK5YZxFZZ9VnaNtcue9C/WgHiQ4HA XosqMDkMm3E= =3MXm -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 6, 2007, at 4:40 PM, Michael Thomas wrote:

...

http://www.dkim.org/specs/draft-ietf-dkim-overview-02.html#anchor61

This is not the spec -- and it's not been widely vetted.

Fair enough; it's also out of date as Stephen pointed out. Still, it
does indicate that the DKIM authors acknowledge that there are
compatibility issues with mailing lists. The updated section 4 that
Stephen posted seems to be moving toward resolving those issues.

I really want to see the spec address mailing list issues in a
thorough way, with clear instructions on what such remailers must and
should do. Then we can say "Mailman is broken wrt to the spec" or
"Mailman complies with the spec" or "Can someone please contribute
code to comply with the spec" or "the spec is broken, we don't agree
with it, so we won't support it and everyone should abandon Mailman" :).

...

I think we can say Mailman is in compliance with choice #3 in this
list. I will also agree with the Note at the beginning of this
section that this "may be controversial". Indeed.

The bottom line here is that you are removing signatures that are not broken. In fact, you don't even check to see if they're broken at all. That's bad all around.

We're removing signature that we know nothing about. As I said,
IWBNI we had code that could check DKIM signatures and sign
messages. So a question to ask, in the face of no available code to
do the verifying or signing, is it better to possibly break
signatures because of Mailman transformations or better to not have a
signature at all. And why?

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRckJPnEjvBPtnXfVAQL0KAP9Ejeu+dSdN838rCAlzpumrM4myazKsQ8D Ya7+yOQ5saKbmhFO/eZpeDn7YWRT2MUw2+P+BuFd0QKEOzmkAeowaLfqtz5r8mme NQDyXUsj22YGOGV5nK+i8egnmDVvspb4nJ1j9ahuqLmQ3RMtCoIYq+jRx8sCdWXo 5VQAsYjcNAE= =UnvC -----END PGP SIGNATURE-----

Michael Thomas wrote:

But let's turn this around: why do you think practice is helpful? I really don't understand the motivation at all. Destroying information -- especially when you're charged with forensic exercises like spam filters are -- is *rarely* the right thing to do. It seems to me that the burden of proof should be on why removing them is the right thing, not the other way around.

Hi Mike,

The original rationale for removing the signature lines were the following (at least from my point of view):

1. It was believed that Mailman would almost certainly cause the signature to break, since it [often] adds info at the end of the message, among other possible changes. You have since told us that there are ways around this, but I wonder if there is a sure way for Mailman to know if the "modes" used in signing are compatible with its transformations (see my idea below for having Mailman re-check the sig after transformation and reporting this fact).

2. The outgoing MTA (sendmail) milter seemed to only want to sign emails that did *not* already have a signature. Therefore, Mailman enabled them to re-sign by removing the old (presumably invalid anyway) signature. At least this way *some* valid signature, even a Sender one, could be placed on the message. This "restriction" may not apply anymore or may be milter-specific...

And there is one more thing that, at least in my mind, made leaving the "known bad" sig in there a bad thing: if it is destined to be invalid, especially if there is almost no way to keep it valid, it seemed best to remove the "doomed" signature. Even though DKIM states that bad sigs should be treated like "no sigs", it just seemed wrong to leave known bad sigs to potentially make the receiver think there is something awry. Instead, having the new message signed with a new good signature that makes the MLM responsible certainly seemed OK and better. Also, the results of the DKIM validation by the MTA (before it gets to Mailman) are *not* removed by Mailman, so there is a trace of the fact that (if the MLM host's MTA did DKIM checks) the original signature passed the test before the message was transformed, so there is a chain of trust (i.e. the reciever trusts the MLM, and the MLM host's MTA verifies the original sender and reports that in the header).

Now, after saying all of this, it still may be best to leave the sigs in there. I am not convinced either way yet. I can see your point about the forensic value. Is there a way, somehow, that Mailman could verify the message before transformation (or the MTA could have done this) and then again after transformation - and then indicate in the header if the original signature has now been rendered invalid (through an as-yet undefined header line) - and then re-sign the message again (or maybe the MTA would re-sign it on the way out)? This could perhaps be a way for Mailman to indicate to the receiver that an invalid From signature is to be expected, and no alarm bells would then go off (the receiver could then rely on the chain of trust). But if the From signature proves to be still valid after transformation, the receiver would know this is expected and could check this again and be even more confident, relying on not only the chain of trust but also on the primary signature. This would probably require adding to the DKIM spec, but it might help to make the whole MLM situation more deterministic.

Hope that was clear...? It's hard to tell from re-reading it, since this stuff is a bit mind-bending.

	-Joe

With DKIM, according to my understanding, you are supposed to treat a "bad" sig the same way you'd treat "no" sig. So it would neither help nor hurt to have a bad signature; it would be like having none (or a missing sig).

Personally, I think DKIM would be a whole lot more effective and powerful if we *could* treat bad sigs as bad. Also, I think there is danger of people reacting to bad signatures negatively. Personally, I'd eye a failed sig with a more suspicious eye than no sig.

				-Joe

Bob Puff wrote:

I confess not having read up on Domain Keys.. I did get into SPF a little, but understand its flaws as well.

If a bad DK isn't bad, then how is this supposed to help spam? I mean, if the mere presence of some signature in the headers will increase the likelihood of an email being delivered (or at least help it NOT be tagged as spam), surely the spammers will pick up on this, and the whole benefit lost.

Example:

Spammer takes a legit message from a DK sender, replaces it with his spam, and blasts it out with the original DK headers. The message has obviously been altered, and contains spam. Would it not be right to reject this message, since it fails the DK check?

Now if the DK verification were done on the input side to Mailman (that is, in the MTA), I can see a benefit. But even in that scenerio, unless Mailman is signing, I'd think removal of the DK headers would be the right thing to do.

Bob

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 7, 2007, at 1:39 AM, Stephen J. Turnbull wrote:

Certainly. What we really want is policy agents that are smart enough to say to the user

This message has a signature which verified successfully and one which failed. According to the Received trace and the List-Id header, and correlated with the SENDER_IS_MAILMAN_BOUNCE heuristic, the successful signature was added by the Mailman Users mailing list. The wooz.1april signature failed.

In similar cases in the future for this mailing list, should I

(o) Rely on the verified signature and silently accept the message ( ) Ask how to treat the message ( ) Silently discard the message

[[Accept this message]] [Discard this message]

Part of me agrees that this is what you'd like to see, but my gut
tells me that this will never work in practice. First, no one but an
email geek will even understand the question, let alone know how to
answer it, and second, I fear that most u/i's and policy engines will
boil this down to a very simple choice for the user:

 This message is unverified

 [Accept] [Discard]
 (o) Do the same for all similar messages

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcntrXEjvBPtnXfVAQKCHwP6A1hqINQZj+EFnC0Vr9i49/wdAx3lA3NW +E3LpOALR9rfhmTxr3IM7tK3niPz7BFl4s7aPZhTReHt2HqVuED4ZOZzV7z0s7hc x6UM/Cm05fiGAz0A3aTLtrJiq8zQfu0h8Vc4mBJxlUt4hOUB/In+gDsLAzVqyHOB N2qgM7Wll0w= =B1XG -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 7, 2007, at 11:40 AM, Stephen J. Turnbull wrote:

Barry Warsaw writes:

...

Part of me agrees that this is what you'd like to see, but my gut tells me that this will never work in practice. First, no one but an email geek will even understand the question, let alone know how to answer it,

Agreed. It's a stalking horse for the BCP; for anybody who's not an email geek, I have this simple advice regarding the BCP:

                     Run away!  Run away!

LOL.

...

and second, I fear that most u/i's and policy engines will boil this down to a very simple choice for the user:

 This message is unverified

 [Accept] [Discard]
 (o) Do the same for all similar messages

Make sure no spam gets through your double opt-in list, and you're golden, no?

Ideally yeah. But python.org does get reported occasionally since
while I think we do a pretty good job of blocking most spam, some
nasties gated from Usenet still get through. Sigh.

(Today's rant: overly aggressive blackholes that block /all/ cable
and DSL IPs that reverse to the ISP doman. For FSM's sake, I have a
static IP address already!)

Similar is *not* going to reduce to "is unverified"; too many grandmothers will lose messages from the grandkids.

You might be right about that.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcoAaXEjvBPtnXfVAQIxrwP/XpboY8mzsbw5LG9L+8Un/M4ogwgP4FgO 6JYNwgaMUAl4cWb1uXBgVuICUEP9LJMwj24SnqENV5HSxDWL5ui2jLj4psPS0h3U 9JXVT/gOjrW2Mr6XeGpVhDO5Zwe8I6obJU4zy/Iey7cqkB+uRyVK+00R5DGmvvo+ cKtcxXYv5HI= =W+TD -----END PGP SIGNATURE-----

Joe Peterson wrote:

With DKIM, according to my understanding, you are supposed to treat a "bad" sig the same way you'd treat "no" sig. So it would neither help nor hurt to have a bad signature; it would be like having none (or a missing sig).

Personally, I think DKIM would be a whole lot more effective and powerful if we *could* treat bad sigs as bad. Also, I think there is danger of people reacting to bad signatures negatively. Personally, I'd eye a failed sig with a more suspicious eye than no sig.

Until, of course, you rejected a piece of mail which had an x-million dollar deal in it... one thing we found out is that while people hate false negatives, mail admins *really* hate false positives. The truth of the matter is that shit happens in the mail system and overreacting based on single factors is a great recipe for generating lots of false positives. As an individual decision you can set your own tolerance level, but you quickly become a lot more conservative if you're doing it at a (large) group level.

   Mike

On 2/6/07 5:51 PM, "Bob Puff" <bob@nleaudio.com> wrote:

If a bad DK isn't bad, then how is this supposed to help spam? I mean, if the mere presence of some signature in the headers will increase the likelihood of an email being delivered (or at least help it NOT be tagged as spam), surely the spammers will pick up on this, and the whole benefit lost.

They have. Much of the spam I see from the "new breed legitimate spammers"* contains DKIM signatures. (I have to assume those verify OK, else why put them in.)

• "new breed legitimate spammers": That is, in the US, those who carefully conform to CAN-SPAM as far as one can tell--one can't really tell whether they "share" unsubscribed addresses with other spammers as likely new victims without probing.

  --John

Michael Thomas writes:

I'm afraid that there's not much consensus on how to deal with the mailing list issue; the people who say "resign" are guessing as there is little/no evidence that resigning is actually a viable strategy.

From the point of view of the mailing lists, resigning is *clearly* a viable strategy; the draft mandates that signature processing SHOULD continue until a success or all signatures are exhausted. (And it MAY continue after a success.) Assuming conformant verifiers (and no corruption in the pipeline after the mailing list, of course), resigning by the mailing list guarantees successful verification.

Of course there's the issue that policy agents might choose to put 100% weight on the failure of the trusted domain's signature, and none on the success of the mailing list's signature. See my reply to Joe Petersen for a scenario of how this could be avoided. Whether it will work well in practice depends on whether policy agents (milters and MUAs, mostly, I should think) will offer such options. While clearly you can't make such handling a MUST, I would like to see the BCP specify that policy agents SHOULD provide such a feature to facilitate resigning by resenders.

Finally, with regard to "loopback" verification, that's your local policy problem, really. It's true that munging by a few mailing lists is invalidating your outgoing signatures. Whether that consideration overrides the mailing lists' editorial policies is a question for negotiation among you, your users, and the list admins on a case by case basis. Remember, you always have the option of S/MIME on individual SignedData MIME body parts for this purpose, and your argument for resenders passing things through verbatim would be much stronger in that case.

Let me float this though: how about a "signature friendly" knob that configures the list to not do things that are known to be harmful to signatures (including s/mime and pgp for that matter). I don't think this needs to be _especially_ complicated, but it would probably need to be fleshed out.

[ Actually, for Mailman 3 it would be nice to have a general "theme" engine that handles this kind of thing. ]

I think as a practical matter it's only a matter of time before this becomes a FAQ in *both* directions (people who are having problems similar to Joe Petersen's as well as those similar to Cisco's). So I agree here.

...

...

...

...

"bw" == Barry Warsaw writes:

bw> I really want to see the spec address mailing list issues in a bw> thorough way, with clear instructions on what such remailers must and bw> should do.

I think it would actually work a lot better the other way: with real life experience and real life running code we can make a much better case for what constitutes a best common practice. Part of the problem right now is that a lot of the speculation is just that.

I really really sympathize with Barry (especially since I don't really have the resources to help with implementation of a verifier or signer for Mailman), but I have to agree with you here.

bw> We're removing signature that we know nothing about. As I said, IWBNI bw> we had code that could check DKIM signatures and sign messages. So a bw> question to ask, in the face of no available code to do the verifying bw> or signing, is it better to possibly break signatures because of bw> Mailman transformations or better to not have a signature at all. And bw> why?

Do you remove PGP ascii armor just on the offhand chance that you might destroy a PGP signature with some configurations of mailman?

That's hardly fair. Joe Petersen writes (in a response to your message):

2) The outgoing MTA (sendmail) milter seemed to only want to sign
emails that did *not* already have a signature.  Therefore,
Mailman enabled them to re-sign by removing the old (presumably
invalid anyway) signature.

First, note that the admin has explicitly stated that the existing signature is presumed invalid. He may be wrong, but this isn't an "offhand chance".

Much more interestingly, note that the milter is broken with respect to mailing lists. IMO, Section 5.1 of dkim-base should get language that says a signer SHOULD NOT refuse to sign a message merely because there is an existing signature. Without that, Barry's question is very relevant.

I would answer Barry that Mailman SHOULD preserve existing signatures because the spec will get language saying

o signers SHOULD NOT refuse to re-sign o policy agents SHOULD report only successes by default o policy agents MAY provide an option to acquire information about failures

In particular, in section 6.1,

  INFORMATIVE NOTE:  The rationale of this requirement is to permit
  messages that have invalid signatures but also a valid signature
  to work.  For example, a mailing list exploder might opt to leave
  the original submitter signature in place even though the exploder
  knows that it is modifying the message in some way that will break
  that signature, and the exploder inserts its own signature.  In
  this case the message should succeed even in the presence of the
  known-broken signature.

I'd like to see that last "should" in all uppercase<wink>. Then (sorry, Barry!) IMO the burden is clearly on Mailman and other list manager projects to either implement signing themselves, or publish their own BCPs strongly recommending use in combination with an MTA that will do the signing.

By removing signatures you go from having about a 99% success rate to a 0% success rate.

That's false. You go from a 99% success rate *on "loopback" messages* to 0%. On other messages the ex ante success rate will be much lower because the trust relationship is on average much weaker. However, the vast majority of *deliveries* are not "loopbacks", and those non-loopbacks are likely (see (1) below) to suffer from rejection on the basis that signatures fail.

With this change there will be a lot more people getting useless false positives. Is that of no consequence?

Of course it is of consequence. You keep ignoring the fact that Mailman has already experienced systematic useless false positives without this change. Is that of no consequence?

But let's turn this around: why do you think practice is helpful? I really don't understand the motivation at all.

What I really fear is that

(1) everybody's intuition is that a failed verification is a
    positive indicator for spam (as compared to no signature, as
    well as compared to verified signature), and they want to
    apply policy filters based on that---we can expect that lots
    of people (and let's not forget AOL) will (ab)use the
    information that way, and

(2) we've already seen list-hostile implementations in the wild---
    we can expect that there will be more.

Both of these are evidently conformant to the current spec.

Destroying information -- especially when you're charged with forensic exercises like spam filters are -- is *rarely* the right thing to do.

True, but this is a Pythonic bunch. "Practicality beats purity." :-)

What should MM2.1 do now? Here's a proposal for 2.1.10: Add an
mm_cfg.py variable that controls whether DKIM headers are stripped or not.

+1, with it defaulting to strip the DKIM.

Bob

Barry Warsaw writes:

What should MM2.1 do now? Here's a proposal for 2.1.10: Add an
mm_cfg.py variable that controls whether DKIM headers are stripped or
not. I think Mark suggested that this should be a site-wide
variable, and I tend to agree.

I've expressed my reservations regarding list-specific issues like internationalization (especially random 7<->8 bit transformation), but on the one hand we don't have any practical experience showing it's needed, and on the other hand turning site-wide Mailman options into list-specific options is well-understood. Ie, it's a YAGNI until proven otherwise.

What about the default? My strong inclination is don't strip, and word the docstring to discourage stripping.

On 2/7/07 8:46 AM, "Barry Warsaw" <barry@python.org> wrote:

Should we strip DKIM by default or not?

Not strip by default.

Even though that changes the default vs the most recent Mailman, it leaves the default alone for everyone who jumps to 2.1.10 from earlier versions.

--John

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 7, 2007, at 8:20 PM, Mark Sapiro wrote:

John W. Baxter wrote:

...

On 2/7/07 8:46 AM, "Barry Warsaw" <barry@python.org> wrote:

...

Should we strip DKIM by default or not?

Not strip by default.

Even though that changes the default vs the most recent Mailman,
it leaves the default alone for everyone who jumps to 2.1.10 from earlier
versions.

I think I am swayed by the arguments in this thread to favor Not Strip as the default, and I agree with John WRT its not being a behavior change for many.

Me too. Here's my discussion on the topic, including a concrete
proposal for Mailman 2.1.10 and 2.2/3.0. Feel free to comment on the
wiki on in this thread.

http://wiki.list.org/x/OgM

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRctro3EjvBPtnXfVAQIHMAP/X4kZL4llpLMLf0rtePsf15092VsF8Old AMZmEvkJ/MtFT1mTm+cFjWg6i4/wUHfP2LIBr8AwNcO8MIUHUbjOB7fLCn41v93n FIKLIlFp6liFqjv3167Mz1SRRnb5r5KAReyCoyRww+ogo/AgVn8HmekoG74DOwGp v/SJuD1YcPQ= =CuhH -----END PGP SIGNATURE-----

Barry Warsaw writes:

Me too. Here's my discussion on the topic, including a concrete
proposal for Mailman 2.1.10 and 2.2/3.0. Feel free to comment on the
wiki on in this thread.

I'll try to post to the wiki later (I'm not a member yet and I'm suffering mail delays---I expect I'll need to do an email confirm), but assuming "on" should be "or" I'll reply here first.

In "Problems with Mailman signing headers" you write that a Mailman signature could potentially "legitimize otherwise illegitimate message". Technically, this is confusing language. "Legitimate" is a local policy decision and will surely vary from site to site. I would prefer that this kind of idea be expressed as "result in recipients accepting spam and undesired messages that they otherwise would reject."

You suggest as a solution not signing gated messages. This has its own problems, specifically that (1) the list is deliberately not signing some of its output, which will cost the host site the advantages of the claim that all of its mail is signed, and (2) many sites that know that this list signs, and will drop all unsigned posts. I think a plausible alternative strategy would be to sign Usenet-gated posts with a different key. I don't think this is generally going to be more than minor extra effort, as any decent signing agent will be prepared to deal with selectors. (I suppose this is mandated by DKIM, but I haven't checked.)

In "Proposal", the language for 2.1.9 is excellent.

For 2.2/3.0, I think that all RFC 2369 headers must be signed to prevent phishing attacks. Sender should be signed for Mailman's own potential benefit, I think, and of course DKIM itself mandates signing From.

The discussion of the DKIM status header should note that DKIM does not even suggest a format for these headers, so they will be implementation-dependent. I think a call for Mailman advocates to participate in specification of a standard header, as well as to help with implementations' headers in the meantime, may be warranted.

Regarding the call for verifiers to "look favorably on" verified list signatures, I'm of two minds. Technically, I think it's a bug in the DKIM spec that it doesn't thoroughly distinguish between verifiers and policy agents (not to mention that it fails to mention the role of policy agents for the signing decision at all!) So I don't like language that suggests that verifiers make policy decisions. There's planty of precedent for it in the latest draft, though. :-(

I think that language to the effect that verifiers MAY make extra effort to find a valid list signature in the case where broken signatures are found is definitely appropriate, though.

As Michael has repeatedly emphasized, very little is known about the pragmatics of re-signing. Nonetheless, I think that a better way to try to accomplish this is to have a Mailman implementation that wants to take responsibility for broken signatures is to sign those signatures. (Remember, it can also create another signature without signing them. Then the signature signature might fail due to an intermediary reordering DKIM signatures, but the signature of the mail itself would succeed.)

Then the BCP for policy agents could say that the presence of a broken signature which is nonetheless verified by a valid signature SHOULD be considered an indication that the verified signer verified the broken signatures on the way in, and that the verified signer then broke them. (This doesn't mean that a policy agent should trust the broken signature. That depends on how much it trusts the verified signer.)

I think your current language is a non-starter without signing the signatures. It's an obvious veector for reply attacks.

Barry,

Nice document. I still feel like I do not know enough about the ramifications of stripping or not stripping the DKIM signature to be sure of the right default, and I still think we could use some more information and understanding of all of the factors. However, Your proposed default of not stripping the signatures seems reasonable, since at least it preserves the forensic information. At least Mailman sites will have the opportunity to adjust this should we find that one way or the other is clearly correct.

Thanks for putting the effort into studying this. Clearly, these (DKIM-like) technologies are not yet mature and there is a lot to consider (email and all of its possible interactions are quite complex), and I hope that the interaction (what has happened and what is to come) between the Mailman developers and the DKIM developers can help to make it all really workable! To make DKIM, or something like it, widely accepted as a standard, it clearly has to be able to handle mailing lists, and ideally, with good integration and good specs, it will be able to do so elegantly and deterministically (and not just "99%").

					-Joe

Barry Warsaw wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 7, 2007, at 8:20 PM, Mark Sapiro wrote:

...

John W. Baxter wrote:

...

On 2/7/07 8:46 AM, "Barry Warsaw" <barry@python.org> wrote:

...

Should we strip DKIM by default or not? Not strip by default.

Even though that changes the default vs the most recent Mailman,
it leaves the default alone for everyone who jumps to 2.1.10 from earlier
versions. I think I am swayed by the arguments in this thread to favor Not Strip as the default, and I agree with John WRT its not being a behavior change for many.

Me too. Here's my discussion on the topic, including a concrete
proposal for Mailman 2.1.10 and 2.2/3.0. Feel free to comment on the
wiki on in this thread.

http://wiki.list.org/x/OgM

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRctro3EjvBPtnXfVAQIHMAP/X4kZL4llpLMLf0rtePsf15092VsF8Old AMZmEvkJ/MtFT1mTm+cFjWg6i4/wUHfP2LIBr8AwNcO8MIUHUbjOB7fLCn41v93n FIKLIlFp6liFqjv3167Mz1SRRnb5r5KAReyCoyRww+ogo/AgVn8HmekoG74DOwGp v/SJuD1YcPQ= =CuhH -----END PGP SIGNATURE-----

---

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/joe%40skyrush.com

Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Stephen J. Turnbull wrote:

Michael Thomas writes:

...

I'm afraid that there's not much consensus on how to deal with the mailing list issue; the people who say "resign" are guessing as there is little/no evidence that resigning is actually a viable strategy.

From the point of view of the mailing lists, resigning is *clearly* a viable strategy; the draft mandates that signature processing SHOULD continue until a success or all signatures are exhausted. (And it MAY continue after a success.) Assuming conformant verifiers (and no corruption in the pipeline after the mailing list, of course), resigning by the mailing list guarantees successful verification.

I'm not saying I think that resigning is a Bad Thing, I'm saying that it's speculative whether it's a Good Thing. You seem to keep ignoring the inherent attack involved with resigning:

From: good@guy.org Sender: bad@fooledyou.com Dkim-Signature: d=fooledyou.com; [...]

If all it takes to get preferential treatment (FSVO preferential) is adding any old third party signature, then we can pretty much guarantee that spammers will start doing that when it's in their interest. The draft specifically refers to "acceptable" in this case for that reason. This is the achillies heel of third party signatures: it presupposes that you -- or much worse your mail infrastructure -- knows what constitutes "acceptable". In practice I know that we as an organization have no clue who is acceptable, and I also know that even if we did, there's no infrastructure use/maintain it. I doubt that we're especially unique here.

...

Do you remove PGP ascii armor just on the offhand chance that you might destroy a PGP signature with some configurations of mailman?

That's hardly fair. Joe Petersen writes (in a response to your message):

2) The outgoing MTA (sendmail) milter seemed to only want to sign
emails that did *not* already have a signature.  Therefore,
Mailman enabled them to re-sign by removing the old (presumably
invalid anyway) signature.

That is just an implementation detail of the sendmail milter. Mine doesn't have that restriction and neither do others that I've seen. This is new code in a new area so getting all worked up about how a particular implementation behaves is not fair.

First, note that the admin has explicitly stated that the existing signature is presumed invalid. He may be wrong, but this isn't an "offhand chance".

I think the question is quite apt: there are lots of transforms that might damage PGP signatures as well: why aren't you stripping them en masse like you are dkim signatures? Could it be that it's because in reality they normally go through just fine? Well, the same is true of dkim signatures; that you've come to the opposite conclusion seems to be based off of experience with exactly one implementation that doesn't produce mailing list friendly signatures. But that implementation isn't inherent in the spec.

Something to note is that a *lot* of the difference between DK and DKIM was our insistence that DKIM be far more robust through manglers than DK was. This was purposefully so that survival through mailing lists was much more likely -- something that a lot of people frankly didn't care about.

I'd like to see that last "should" in all uppercase<wink>.
In RFC-speak, should and SHOULD are identical.

Then (sorry, Barry!) IMO the burden is clearly on Mailman and other list manager projects to either implement signing themselves, or publish their own BCPs strongly recommending use in combination with an MTA that will do the signing.

As I mentioned, part of the DKIM work is the SSP work as well. Being able to say that "I sign everything" is a pretty powerful indication that you should be more suspicious if you get a broken/unsigned piece of mail. So while I think it would be great if mailman pushed signing too, I think that there are other incentives for domains to bring mailing lists into the fold too.

...

By removing signatures you go from having about a 99% success rate to a 0% success rate.

That's false. You go from a 99% success rate *on "loopback" messages* to 0%. On other messages the ex ante success rate will be much lower because the trust relationship is on average much weaker. However, the vast majority of *deliveries* are not "loopbacks", and those non-loopbacks are likely (see (1) below) to suffer from rejection on the basis that signatures fail.

Huh? There's no difference between "loopback" and anything else: either a signature verifies or it doesn't; we don't treat our own signatures any differently than any other signatures. When using the l= option, almost all signatures will verify. The only substantial difference between dkim and pgp signatures is when a mailing list annotates the subject line of a new thread, but this too can be worked around by intelligent use of z=. The only reason this isn't in the draft is because we didn't want to get bogged down describing heuristics in a standard (rightfully). All in all, I see no justification for doing anything different for DKIM that you wouldn't also do the corresponding thing to PGP.

...

With this change there will be a lot more people getting useless false positives. Is that of no consequence?

Of course it is of consequence. You keep ignoring the fact that Mailman has already experienced systematic useless false positives without this change. Is that of no consequence?

Which false positives? I don't remember seeing that, and I've certainly not seen anything in our deployment that suggests that bad signatures are causing FP's on other domains incoming mail. After a year of deployment signing millions of messages a day, I'd expect that I'd have heard at least *one* report of that. Heck Y! and Google signing billions of messages a day with DK which is a lot more fragile and I've never heard from either of them that they are having FP problems due to broken signatures.

...

But let's turn this around: why do you think practice is helpful? I really don't understand the motivation at all.

What I really fear is that

(1) everybody's intuition is that a failed verification is a
    positive indicator for spam (as compared to no signature, as
    well as compared to verified signature), and they want to
    apply policy filters based on that---we can expect that lots
    of people (and let's not forget AOL) will (ab)use the
    information that way, and

Yet all evidence in my experience is that that is not correct. Also: last I talked with the AOL guys they were planning to deploy DKIM as well, so they'd have a reasonable amount of incentive to understand the implications on FP's and signature breakage. In any case, I think it's unreasonable to be held to a standard that somebody, somewhere may have an overly aggressive filter; it's their problem honestly.

(2) we've already seen list-hostile implementations in the wild---
    we can expect that there will be more.

Both of these are evidently conformant to the current spec.

There are legitimate reasons to be "list hostile". Statements@bigbank.com could probably care the least whether it survives a list, and in fact probably thinks that it's a feature not a bug. Note that there is a significant faction of DKIM proponents who are coming at it from that angle and from their perspective it's a correct stance. We, on the other hand, want DKIM to work in the more general user population case. So it shouldn't be surprising that different sites/implementations will have different signing policies.

   Mike

...

Destroying information -- especially when you're charged with forensic exercises like spam filters are -- is *rarely* the right thing to do.

True, but this is a Pythonic bunch. "Practicality beats purity." :-)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

BTW, synchronicity is a weird thing. A friend of mine -- totally
unaware of the current discussions -- just sent this to me:

http://it.slashdot.org/comments.pl?sid=218726&cid=17752748

LOL.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcoLMXEjvBPtnXfVAQKQHwP+LHBd+K8kS0WP1D/YsZ9SCSzSqgXzqiY+ jjk1cPzvM5diDb9C5j1rkebZHKmHJtLlmgUHb5skxNr2OYz4uvVKFvm1eSWCGASW V8F9wATj0uO/Hiro+grBLoJsGuVc5+TBRjORqMXp3PPIhQy5rahobhTJSXu/Wya7 txI0BoqSQNY= =SCfD -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 7, 2007, at 5:06 PM, Michael Thomas wrote:

...

...

I'm not saying I think that resigning is a Bad Thing, I'm saying
that it's speculative whether it's a Good Thing. You seem to keep ignoring the inherent attack involved with resigning:

From: good@guy.org Sender: bad@fooledyou.com Dkim-Signature: d=fooledyou.com; [...]

So wait, taken to its logical conclusion, doesn't this mean that
really the only thing that DKIM cares about protecting is the
sanctity of the From header? No, it doesn't. All it means is that you shouldn't blindly allow a
third party to vouch for a first party (or any other party for that matter).
This is just common sense: you need to have some trust in a third party before you trust what they have to say about another party, right?

Sure. I guess my point was, that in your example above, what's being
signed is the Sender header, and for that header, fooledyou.com /is/
the first party. So fooledyou.com is making no assertions about the
From header. Is there a requirement in DKIM that the Sender domain
is the same as the From domain?

For a non-anonymized non-digest message, where Mailman isn't going to
change the From header, it obviously cannot sign the From header. It
will set its own Sender header, and is able to sign that. In that
scenario there's no third party signing going on. Maybe the
confusion is in the term "resigning". I'm not actually proposing
Mailman (or its downstream MTA) resign anything; I'm proposing that
we add another signature for the headers that Mailman does control.
Like Sender.

If we leave the original DKIM-Signature header alone, but simply add
ours to match our Sender header, then we'll have at least one valid
DKIM-Signature header, right? The one for the From header may indeed
be broken. Maybe Mailman broke it or maybe some other system
component broke it.

Is that what you thought I meant? Is the scenario I just outlined
inherently unsafe?

So now in fact, this leads to a concrete proposal that is simple, MLM- friendly and requires no changes to existing standards: a mailing
list BCP is to DKIM sign the List-Id header. You policy engine than
can add weight for a message with a valid DKIM signature of the List- Id, even if other signatures, say by the original author are broken.

I think for now I'll cut this response short, because I'd like to
know what you think about that.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcpVpHEjvBPtnXfVAQKEagP/WbWH5+rQuAofi5QrWgabibU8RRXZ8yqs 3nY1sZlYB616N6vuJoY4aqVN6Ud4AiXIS4gZPOsX5IEXiihK2XLYEL+JPtHMINHZ al4aa/6sRxrizDGHDQH8db19umD0R9vYceBAoyjRwrE1b1XbBDh8+ALavXZ0Lum6 sD4/KOQC4+w= =IUsC -----END PGP SIGNATURE-----

Michael Thomas wrote:

Frankly I think you'll be screwed even if you remove them too; removing them will not allow you to fly below the radar. Consider if Y! and Gmail had a bilateral agreement that they expect each other's mail to be signed and to put it in the bit bucket if it wasn't. It makes no difference whether you removed it or not: it lacks a valid signature in both cases. In that case, the only thing you could do is not destroy and/or remove the signature.

Consider the headers and structure as follows (From: munged) of a message I just received from a Y! user.

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;

h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;

b=Cz7v0Jd51rc72THmOlqA/rac152bUZdiFm2T2IAFflFuxVHHKJmabS0rzD2tU5zVSofVoc0rVg0g7t0NaDGRMt7JxXK8reox7TzMephYOxI0zcr5iWGejG57Fn/gcQtqng8uG0vAJLw1mfXHMaCcz726cj4iYQOYzbCb6UxXH4g=; X-YMail-OSG: 9QE.IHIVM1k8MHil45oNbkt10TvkD0DVytKmI1Ki4W.WDhIT4Qq6HnLM6dCWNcikXlMu.1lftQrfhq1fgEKml97AoKamDnsG4bZNT_FRLyHVTcU_cuUp7W04PgOjiNd9HJK6MSNeJsfDUfVqrnegItcDfJ1Kjs5tGYyMqDp084T22mRvpc3swag- Received: from [69.232.227.173] by web82813.mail.mud.yahoo.com via HTTP; Wed, 07 Feb 2007 15:00:43 PST Date: Wed, 7 Feb 2007 15:00:43 -0800 (PST) From: xxxxx Subject: Re: feb. 25th To: Mark Sapiro <msapiro@value.net> In-Reply-To: <PC1760200702061639520756a77058a8@msapiro> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1589639226-1170889243=:32077" Content-Transfer-Encoding: 8bit Message-ID: <276441.32077.qm@web82813.mail.mud.yahoo.com>

--0-1589639226-1170889243=:32077 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

<snipped>

--0-1589639226-1170889243=:32077 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

<snipped> --0-1589639226-1170889243=:32077--

(My MUA will mung the DomainKey-Signature: by wrapping, but it looked OK as I received it)

I submit that there is nothing that Mailman could do to this message in the way of filtering content or adding msg_footer that wouldn't break the signature.

I also submit that this message structure is typical of the vast majority of mail that originates from Y!

Thus, it seems that the choice is break the signature or make no changes whatsoever to the message other than adding more headers.

Mike talks about the l= parameter allowing adding trailing content, but I don't see Y! and Gmail using it, and even if they did, how would we (could we) add a footer without breaking either the signature or the MIME structure of the message.

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Michael Thomas writes:

I'm not saying I think that resigning is a Bad Thing, I'm saying that it's speculative whether it's a Good Thing. You seem to keep ignoring the inherent attack involved with resigning:

Have you actually read my posts, or just enough to feel defensive?

I have specifically referred many times to the user-list trust relationship implicit in a double-opt-in list. I have provided examples of how the receiving system can acquire information about such relationships, as well as acknowledging that getting such information is a nontrivial problem in the context of busy admins and slow implementation cycles.

The standard specifies that whether to trust a signature is a local policy decision. It seems to me that Mailman's decisions about whether to put signing and verification capabilities into Mailman itself will depend on the developers' estimate of whether list signatures will be trusted in those local policies. It seems to me that Mailman's decisions about how to default the signature-stripping functionality depend on our estimate of whether broken signatures will be given negative weight compared to no signature.

My position is that Mailman lists[1] SHOULD participate in the DKIM protocol, because I think that if Mailman lists are important to users, they will respond to DKIM-related obstruction of their traffic by demanding that their MTAs trust their Mailman lists. If that's a PITA for the admins, too bad---that's the flip side of the admin benefits that come with use of DKIM to filter spam. And of course admins and MUA developers *will* develop trust management tools. Maybe you have less confidence in your vendors, of course---I *know* mine will rise to the occasion.

So far, you talk out of both sides of your mouth. On the one hand, you fault my proposal because of the attacks inherent in trusting any old re-signature; on the other, you claim that you don't have trust in anybody's signature, and you don't even treat your own specially! Elsewhere you have implied that for you verification == trust if "From == signing domain". Just generalize that to include "List-Id == signing domain" in the policy agent software! And "Sender == signing domain".

From header. Why not recommend that UIs SHOULD treat *any* of the

Users need never know that the "sender" who was verified is not the three conditions above as "sender verified", until experience shows that's a bad idea? I suspect that naive users will happily accept it if policy agents tell them "sender was verified, so we present you with this mail for your consideration." They may misconceive that the

From header was verified, but why should that matter?

If it *does* matter to them (eg, because they know that "Mom would never send me porn spam"), then here's the recommended UI for spam discards when the sender has been verified as a mailing list:

Treat similar messages as spam?  [[yes]] [no]

Note: this message was verified to have been relayed by the Mailman
Developers mailing list at python.org, which accepts responsibility
for relaying it to you.
( ) I am not a member of this list.  Treat messages from this list
    as spam in the future.
(o) I am a member of this list.  Carefully scan messages from this
    list in the future.

Something similar could be recommended for other cases where the verified sender is in a different domain from "From" (as I am, for example). Isn't that the way it's supposed to work? Do you really think that users will care as long as you explain that they're not blacklisting their mothers, and the spammer does get blacklisted?

Footnotes: [1] Whether Mailman itself should be a signer or verifier is another question; I'm agnostic on that.

Barry Warsaw wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Excellent post Steve, thanks.

I think we're converging on a solution for Mailman both in the short term and in the long term. See my previously posted wiki link for my current thoughts on the matter. I just wanted to add one other thing...

On Feb 8, 2007, at 12:41 AM, Stephen J. Turnbull wrote:

...

"From == signing domain". Just generalize that to include "List-Id == signing domain" in the policy agent software! And "Sender == signing domain".

I definitely agree that "List-ID == signing domain" should be added for interoperability with mailing lists. I'm not sure about Sender, only because Mailman's addition of Sender itself is not without some controversy (mostly over interpretation of RFC 2822 language IIRC).
But there's no doubt that well-behaved mailing lists should include List-ID, so that makes a natural header to sign. See my discussion in the wiki page for situations where we might /not/ want to sign List-ID though.

I wouldn't get all hung up about what you're signing "for", per se. The right thing to do for a mailing list signature that, say, adds both ListId and Sender would be to:

h=From:ListId:Sender:[all of the other headers like mime stuff, etc]

and

i=mailing@list.org

Note that the i= is the way to assert which address if any you want to take responsibility, which in the mailing list case is the ListID or Sender. It is definitely not harmful to sign things like From too, and you definitely should do that (I believe it's a MUST anyway). The only trickiness is that you shouldn't sign things like Sender or ListID if they are empty and it's acceptable for them to be modified in flight (ie, by a mailing list)... that probably doesn't affect you unless there are signatures where you add ListID but don't add Sender or something like that.

Michael, since you're a DKIM spec insider, can you please relay this discussion to that community (if you agree with us of course!). We're making a good faith effort to do our part, and I'd like to see the DKIM specs acknowledge the mailing list use case more strongly.

I'm not entirely sure what I'm being asked to do -- did you have anything in particular you want me to relay? I remember the part of wanting to have better guidance, but did I miss anything else? I will forward on your wiki entry though...

   Mike