On Tuesday, February 20 at 10:31 PM, quoth Matt Simpson:
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.
The next step, if you're really interested in getting to the bottom of
it, is to modify qmail-dk, so that instead of returning 31 in the
three places that it does, make it return something else for each
instance (namely, unused numbers that you can add to the big switch
statement in qmail.c---for example, 95, 96, and 97). Then, have it
spit out something useful for each case, and start trying to see what
you can see (i.e. find a way to keep track of those error messages,
either in the bounces they generate or add logging or something else).
Of course, this is rather involved, and requires both an understanding
of C and a willingness to get one's hands dirty with the innards of
qmail.
But there's obviously no difference in control files and permissions
between the times it works and the times it doesn't.
Not at all. If the difference is that one of them happens when
qmail-dk is invoked by qmail-local/qmail-lspawn (i.e. either as a
regular user or as root) and the other happens if qmail-dk is invoked
by qmail-remote/qmail-rspawn (i.e. as qmailr), then you can see how
the permissions on the control files might make a difference.
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.
Of course, this is trivial to test with judicious use of chmod.
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.
So we can eliminate the first possibility. You are dealing with either
incorrect permissions or a libdomainkeys failure.
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.
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.
~Kyle
--
Imagine what it would be like if TV actually were good. It would be
the end of everything we know.
-- Marvin Minsky
pgphmPrNZtoY4.pgp
Description: PGP signature
|