[prev in list] [next in list] [prev in thread] [next in thread]
List: ezmlm
Subject: Re: To VERH or not to VERH?
From: Matt Simpson <net-ezmlist () jmatt ! net>
Date: 2007-01-20 15:09:37
Message-ID: p06240604c1d7db0ef93e () norm ! jmatt ! net
[Download RAW message or body]
One thing I forgot to mention in my previous post is that if you sign
your outgoing list messages with DomainKeys signatures (a good idea,
IMO), VERH may invalidate the signature, depending on how you
implement signing.
If you use the commonly-available qmail-dk program (written by Russ
Nelson, I believe), it signs the message when it is originally
queued. Subsequent modification of the message by verh processing
(or anything else) in qmail-remote will invalidate the signature.
There are a couple of solutions to this. One is to sign each
outgoing copy of the message in qmail-remote when it is sent. This
is the "safest" solution, in the sense that you're sure the message
you're signing is exactly the message you're sending. The downside
is it multiplies your signing overhead by the number of recipients on
the list. If you're interested in this solution, there's a patch,
kindly provided by Richard Lyons when I raised this question on the
qmail list. See
http://test.frob.com.au/qmail/patches/qmail-1.03-remote-verh-dk.patch
I tested this patch, and it seemed to work. I ended up not using it,
because I used another solution, also provided by Richard Lyons
during the discussion of domainkeys vs. verh.
The Domainkeys protocol supports a header-exclusion feature, which
basically tells the signing and validating processes that certain
headers may be subject to modification and should be excluded when
signing and validating the message. This feature is not supported by
Russ Nelson's qmail-dk, but Richard Lyons provided a modified
qmail-dk which uses an environment variable to tell it which headers
to exclude. This is what I ended up using, and it works nicely. See
http://test.frob.com.au/qmail/patches/qmail-1.03-dk-0.54-exclude.patch
A couple of potential downsides to this. If you modify the body of
the message, instead of just the headers, it won't work. VERH
supports body modification, and it may be tempting to do. In my
case, as I mentioned earlier, I opted NOT to VERH the TO header, but
added a List-Unsubscribe header instead. Many subscribers are too
stupid to display the full headers to see this, so there's a
temptation to add a trailer with VERH info. If you do that, then
signing the message when it's queued won't work. I avoided the
temptation. ( A compromise would be to add a trailer which does not
get modified, telling the subscriber to look at the full headers).
Another potential pitfall is if the message is received by a system
which validates domainkey signatures without supporting header
exclusion (e.g. an unmodified qmail-dk), the validation will fail.
I'm not sure how big a risk this is; I haven't seen any rejections
on my lists because of this.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic