Qmail
[Top] [All Lists]

Re: Broken DomainKey .. or dead project?

To: qmail@list.cr.yp.to
Subject: Re: Broken DomainKey .. or dead project?
From: Matt Simpson <net-qmlist@jmatt.net>
Date: Wed, 4 Apr 2007 20:05:42 -0400
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Delivered-to: sp-com-lists@consult.net
Delivered-to: gmail-qmail@securepoint.com
Delivered-to: sp.com.list@gmail.com
Delivered-to: mailing list qmail@list.cr.yp.to
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jmatt.net; b=iaCuoJu8qE5k+5/Wwiimb8SoKVVwPdsRF/qQMGfMNfkmzakp2qBTNlKbqAuwxADzS41qeZGE/bdXhJtJOrD2fcc/rJJ/ehThT3qJZiWMEAUGMr6QoZlM4DkpMhaUy9FJhbLvXTQlCYWEkDh/c4ND4BqdEo5xXzitia30RTXrkwQ=; h=Received:Mime-Version:Message-Id:In-Reply-To:References:Date:From:Subject:Mime-Version:Content-Type;
Domainkey-status: bad
In-reply-to: <20070404211936.GI22829@c-76-18-79-168.hsd1.nm.comcast.net>
Mailing-list: contact qmail-help@list.cr.yp.to; run by ezmlm
References: <b86db13f0704011331m4135c427vc934ced0d8b64120@mail.gmail.com> <20070401205313.GA5988@discworld.dyndns.org> <b86db13f0704011429x17f3e0b1w903861f725380af5@mail.gmail.com> <20070401225748.GA6359@discworld.dyndns.org> <1175514940.31108.92.camel@castor.taos-it.nl> <b86db13f0704041207p6b6c548ai617ff192c7d27414@mail.gmail.com> <p06240603c239aa94b54f@[128.163.18.106]> <20070404211936.GI22829@c-76-18-79-168.hsd1.nm.comcast.net>
At 3:19 PM 4/4/07, Kyle Wheeler wrote:
It seems to me that if that's all you want to use it for, it should be re-written as a wrapper around qmail-remote.

Maybe. There's been a lot of discussion here about signing in qmail-remote vs. qmail-queue. There are pros and cons to each approach.

I don't entirely understand this. Does DKEXCLUDEHEADERS apply to signing only?

Well, that environment variable applies only to signing.

 Does it honor exclusions in the DK header?

I don't think it does.  That's another reason not to use it for verification.

 Does it *generate* an exclusion message in the DK header?

No, it generates an INCLUSION message (h=...), which specifies the headers that are not listed in DKEXCLUDEHEADERS. Apparently, that's what the DK specification calls for. Here's what a signature on one of my messages looks like, as generated by the patched qmail-dk:

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=default; d=jmatt.net;

b=GYu6Wo6c4fiBl+AVljlmQ8VsSnWTYee9gUXzFmxdxmS34DqQkwF0rr9RAIyv35sLKtv+SjoG8BgC1GqcUk2O4rDg+o6rQ5VxW2Dh9i0/Z4aZKlIX2T3+2+6ngiNdTcbB30B2/FK7OKf6FkPnAOZpXSaXyKy5UgUq+vOkJ9bzXzE=;

h=Received:Mime-Version:Message-Id:Date:From:Subject:Mime-Version:Content-Type;



And, unless I'm misunderstanding this code, it is very broken for headers that span multiple lines.

It might be.  I don't know.

At 10:49 PM 4/4/07, Phil wrote:
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.
 Anyone else noticed this?

Maybe. I think that's the problem I ran into as an indirect result of trying to sign bounce messages. Normally, I invoke qmail-dk by setting QMAILQUEUE as necessary, either in the qmail-smtpd run script for relay clients, or by setting it in tasks that generate mail locally. But when I wanted to sign bounce messages, it appeared that the only way to happen was to set it in the qmail-send run script, which caused qmail-dk to be invoked every time a message was queued. My bounce messages got signed correctly. And most mail was delivered properly. But incoming messages that got queued more than once, because of aliases, forwarding, etc. got that rejection message. I'm pretty sure that it was that second trip through qmail-dk that caused the problem, although I'm not sure exactly why. Wrapping the signing function around qmail-remote instead of qmail-queue would probably fix that problem.

<Prev in Thread] Current Thread [Next in Thread>