At 11:04 AM 2/20/07, Kyle Wheeler wrote:
How about moving the DK-signing to qmail-remote? I haven't tried it,
but I've seen things like this:
http://test.frob.com.au/qmail/patches/qmail-1.03-remote-verh-dk.patch
That would probably work. I actually tried that patch before, and it
seems to work as advertised. I quit using it and switched back to
qmail-dk, for reasons that may be just superstitious. I felt a
little more comfortable with a "plugin" like qmail-dk than with a
patch, and I didn't have to worry about it conflicting with other
patches. Also, since I run some ezmlm-lists, I liked the idea of
signing each message once when it was queued, rather than signing all
the outgoing copies when they were sent. I'm not really sure the
extra overhead of signing a message 500 times instead of once was
really going to hurt me, but it just seemed cleaner to sign it when
queued.
Hmmm, find out why DK is rejecting those. In the default qmail-dk,
that message will be generated when:
1. verifying messages with bad DK syntax
2. Unreadable control files
3. dk_sign/dk_verify library functions return NULL
Of the three, the only one you can really do anything about is make
sure that all the various pieces/users of qmail can read the
qmail-dk control files.
And that's probably the only one I can rule out as the source of the
problem. As I said before, it seems to work OK when the message is
delivered the first time through the queue; it only fails when a
message is re-queued because of an alias or forward. And it doesn't
seem to fail consistently in that case. It may only be failing if
the incoming message was signed, but I haven't done enough testing to
confirm that. But there's obviously no difference in control files
and permissions between the times it works and the times it doesn't.
What's baffling to me is that qmail-dk really shouldn't be trying to
do anything when it fails. I have an incoming message.
DKSIGN=/etc/domainkeys/%/default, DKVERIFY is not set. So it
shouldn't try to verify the message. It might be trying to sign it,
but the sender domain is not one of mine, so there will not be a
matching key file. So I thought it would do nothing. But instead it
bounces the message for some reason. And then, since the sender on
the bounce is my domain, it successfully signs the outgoing bounce.
|