On Thu, Nov 04, 2004 at 12:11:07PM +0100, Tollef Fog Heen wrote: > * Matthew Palmer > | Uhm, having just read through the supplied URL, I can't agree with the > | sanity of the proposal. > > | It appears to require that headers not be modified at all in transit > | (which means that forwarding becomes impossible), > > Uhm, which headers are modified by a forwarding agent? New headers > can be prepended just fine, and you don't have to sign all the > headers.
See, that's the thing that the FAQ was unclear on. If you don't have to sign all headers, then you're OK. I was thinking the attachment of Received: headers as being particularly problematic. To quote the FAQ: "Mailing lists that do not change the content or re-arrange or append headers will be DomainKey compatible with no changes required. Mailing lists that change the message and headers should re-sign the message with their own private key and claim authorship of the message." That suggests to me that sticking new headers into the mix would screw up the signature. > | and suffers from the same problem as most mail server crypto issues > | -- domain names (and the associated keys) are trivial to obtain. > | It's just too easy to get a new domain to spam from, and rejecting > | mail from unknown domains reduces the system to a fancy whitelist. > > It gives you traceability and it can be used to prevent joe-jobs. > It's not a silver bullet solution against spam. And yet it's being touted as one. I predict that the effect of this system on spam levels will be about as detectable on a spam vs time graph as a fart in a hurricane. > | If the "signed headers" problem isn't as bad as I think it is, then it > | certainly looks saner than SPF, but the FAQ question "How does DomainKeys > | work with mailing lists?" give me chills (and not the good kind). > > Which mailing list systems do you know of that change headers and > don't claim the message (basically using themselves as the envelope > sender). I can certainly imagine there being such beasts out there, > but most of the larger ones certainly don't, as they would then have > no way to catch bouncing members. DomainKeys, by my reading, doesn't use the envelope sender, but instead uses the visible headers (such as From:) to work out what to authenticate. Again, to quote the FAQ: "What does DomainKeys verify? DomainKeys examines the From: and Sender: headers' domain to protect the user and deliver the best possible user experience. Desktop mail clients like Microsoft Outlook show these headers in their user interfaces. If the user establishes their trust based on the these domains, then so should any system built to verify whether that trust is warranted." If I examine the message you sent, both the From: and Sender: point to your domain, but many headers have presumably been added by the Debian mailing list software, which would require a remade header signature. That signature would then fail to verify because the From: and Sender: lines aren't pointing at Debian. I'll reiterate that I haven't read the spec, so if the FAQ is contradicted by the actual spec, I'll stand corrected, but on the basis of what I've read in the FAQ, I have no interest in the spec itself, because it's not going to be any better than SPF in practice. Which is a pity, because the initial idea is quite a decent one. - Matt
signature.asc
Description: Digital signature
