Qmail
[Top] [All Lists]

Re: Domain Key signature on bounce messages?

To: Qmail mailing list <qmail@list.cr.yp.to>
Subject: Re: Domain Key signature on bounce messages?
From: Kyle Wheeler <kyle-qmail@memoryhole.net>
Date: Wed, 21 Feb 2007 07:56:26 -0700
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=memoryhole.net; b=QiRueJnbjnauzPaKbmYaX2CnFq4vf3jx+JUxuI0R+1BTfDUtd1+yBujtnxIUvXv6qWwmiSaFoOBpBq+lJ8EDRZhwDbTDbH28PZY0QxPLKiSljkqGjwXgf8S8uJVPHEVnWhhd/kNcRFtK1FrcJhUP7Us/GU+TAq7S0uvtw+S6kr4= ;
Domainkey-status: good
In-reply-to: <p06240600c201f7189ece@chowder.foxhunters.org>
Mail-followup-to: Qmail mailing list <qmail@list.cr.yp.to>
Mailing-list: contact qmail-help@list.cr.yp.to; run by ezmlm
References: <p06240608c1fc25a65d43@norm.jmatt.net> <20070220180432.GF20321@c-76-18-79-168.hsd1.nm.comcast.net> <p06240600c20168bbdcd1@norm.jmatt.net> <20070221083739.GB4080@aleut.local> <p06240600c201f7189ece@chowder.foxhunters.org>
User-agent: Mutt/1.5.13 (2007-02-12)
On Wednesday, February 21 at 08:33 AM, quoth Matt Simpson:
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.

Ahh, hmmm, that would make permissions a bit less likely of a problem.

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 would examine those cases where it succeeds, and see what is common between them that the failures do not have.

The real "problem" here, if you can call it that, is that qmail-dk relies on things like the "Sender:" and "From:" headers, which don't have to be anything in particular (and can be faked). It has no other way of distinguishing between virtual domains. What you would have to do to get around this is to set up different qmail installations for each virtual domain, and hard-code the DKSIGN variable to a specific key for that domain.

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.

Possibly. I haven't given it enough thought to have a concrete opinion on that part.

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.

Hardly. All it would really require is a wrapper around qmail-inject (in the language of your choice, including things like perl or bash).

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?

I would say that, if you want to be strict in your DK policy DNS record, you have to do exactly what you're trying to do. That's one of the biggest reasons why my policy still says "some" emails are signed: because making sure *all* of them are signed seems like a bit of a pain in the butt at the moment. Once I start using something like outbound signing, then things may be a bit different, but as it stands...

Good luck!

~Kyle
--
If after I depart this vale you ever remember me and have thought to please my ghost, forgive some sinner, and wink your eye at some homely girl.
                                            -- H.L. Mencken's Epitaph

Attachment: pgpaghQc7Mi1W.pgp
Description: PGP signature

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