On Thu, Nov 04, 2004 at 10:37:08PM +1100, Matthew Palmer wrote: > 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. Sticking new headers into the mix, yes. Sticking them after the mix, yes. Adding them _before_ the DomainKeys signature will be fine. Of course, this may require a change in the way some software works at the moment? I have the impression that spamasssassin/amavisd append their headers to the end of the header list... > > | 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: This indeed strikes me as a difficulty in the system... Unless the Sender: header is supposed to be filled in from the envelope sender? To my mind, which ever header this protects, is the one you can use to filter against. My problem is I can't see what we really gain, unless you apply a rule that all email from a domain-keys-enabled domain must have a domain-keys signature. To make mailing lists and forwarders work, it'd have to work off the SMTP envelope sender, not the From: header. Before I can decide if this'll work for me, I have to go check what the SMTP envelope sender is on the emails that come out of my server, which I have postfix doing a canonicalisation-remap on so people don't try to email me on my fetchmail-pickup-only POP box. So as far as I can see, this would allow (if everything falls into place) email rejection from domains that mark themselves as such... Kinda like SPF/SRS, but without having to bone up the From address. ^_^ (And chewing up more CPU load. >_<) > 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. I haven't read the spec either. IE crashed and I didn't bother returning to the site, trusting debian-devel to tell me all I needed to know about it. ^_^ -- ----------------------------------------------------------- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Anu.edu.au "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. -----------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature