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: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] 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". [EMAIL PROTECTED] 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." :-) > _______________________________________________ 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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp