[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian.org e-mail address and SPF/SRS

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

Attachment: signature.asc
Description: Digital signature

Reply to: