Re: To VERH or not to VERH?

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.