Sounds like its just not worth the trouble. Funny, I was expecting to
get a lot of "works for me" comments, as I had searched high and low
for info on this patch. So far I've only gotten messages on this list
from users who also have qmail-dk issues.
Erik
On 4/4/07, Kyle Wheeler <kyle-qmail@memoryhole.net> wrote:
On Wednesday, April 4 at 10:49 PM, quoth Phil:
>> [..] A message can end up with multiple DK
>> signatures that way, but that's not a bad thing. If anything, it means
>> there's more verifiable information about the path of the email.
>> ~Kyle
>
> Have you seen qmail-dk sign a message that is already signed?
I should point out that I was referring to the DomainKey specification
rather than the qmail-dk implementation; Charles asked if bounces
could possibly be signed according to the spec, and I responded
in-kind with an answer based in the DK spec.
> I don't think qmail-dk can sign a message that already has a DK
> signature - when I set it up to sign all messages that were being
> relayed through my server, qmail-dk would sign and forward mail that
> didn't already have a signature, but die with "554 mail server
> permanently rejected message (#5.3.0)" for mail messages that
> already had a signature.
Yes, qmail-dk can sign a message that already has a DK signature. Or
rather, put another way, qmail-dk doesn't check for a DomainKey header
before signing a message, if it has been told to sign a message. But I
haven't double-checked that doing so is bug-free recently. I remember
having a problem like you describe a while back, and as I recall the
real cause of the problem is that qmail-dk can't both sign AND verify
the same message, and will either segfault or die horribly in some
other way (e.g. reject the message) if you try. Part of the problem, I
think, is that it does not have any provisions for rewinding its I/O
stream. But it's possible (and even likely) that there are other bugs
in there...
My workaround has been to patch it to do only one or the other, and to
make sure that it's environment is all set up to do only one or the
other (and to refuse to verify DK signatures if RELAYCLIENT is set).
Unless it's broken in a different way than what I found---and, hey, I
would not be terribly surprised---it should be possible to make it do
both (if that's what you need) by wrapping it in a bunch of shell
scripts that carefully manage its environment variables.
> This was painful to detect and troubleshoot, because no trace of the
> failure was left in any logs, I had to capture the offending
> messages and manually play them back, with and without DK signatures
> to confirm the problem. Anyone else noticed this?
Heh, I ended up patching qmail.c and qmail-dk.c so that qmail-dk
returned unique error numbers which were understood by qmail.c's big
switch statement; that way I could find out more precisely why it was
dying.
~Kyle
--
The whole art of government consists in the art of being honest.
-- Thomas Jefferson: Rights of British America, 1774
|