If, as you said in your original email, the problem seems to happen
with messages that are forwarded or delivered via an alias, then
it's all about emails that were sent back to qmail from qmail-local,
which runs as either the alias user or some other non-privileged
user (the one the message was addressed to), who may not have
sufficient permissions to read your control files.
Maybe. But one thing I forgot to mention earlier is that my qmail-dk
has the setuid bit on. So regardless of who is running it, qmail-dk
should always be running as the same userid (qmailq) which has access
to the control files.
The following code from qmail-dk.c may prove illuminating. Lines 144
through 150:
switch(control_readfile(&dksignature,keyfnfrom.s,0)) {
case 0:
if (keyfn[i]) return;
die(32);
case 1: break;
default: die(31);
}
The keyfnfrom.s variable there is the name of the file it expects to
find the signature in. If that file does not exist, control_readfile
will return 0, which will make qmail-dk die with a return value of
32 (i.e. it will return the message "qq permanent problem
(#5.3.0)"). So, making it sign a message from a domain that it
doesn't have a key for would kill the message, but it wouldn't kill
it with the error message that you're currently getting. What you
can pull from this is that qmail-dk isn't getting that far, because
if it was, it would die differently. Your problem is somewhere else.
OK ... now that's interesting. I had assumed that if it couldn't
find the key file, it just wouldn't sign the message and would pass
it through unsigned. And it does appear to be doing that in some
cases. But in other cases, if your analysis is correct, it's dying
before it gets that far.
I'm not an expert in C, but I might be able to stumble around enough
to do some more testing. But I'm beginning to think my original
approach, setting the qmail-dk environment variables in the
qmail-send startup script to cause it to be invoked for all queued
messages, is fatally flawed. A better approach would be to try to
invoke qmail-dk only when the bounce message is queued, which
probably requires some patching somewhere I'm not familiar with.
Or am I wasting too much time on a problem that doesn't really need
to be solved? How necessary is it to sign bounces? My domainkey
policy DNS records say that all messages from my domains are signed.
To me, that means bounces should be signed. But if I don't, is there
a great risk that my bounces will be rejected as forgeries?
|