- View Sourcehowdy-
i just re-joined the list after a few years because i was asked for
my opinion on the potential patch to qmail-dk.c described in this
while looking at the patch and the code it modifies, i think i may
have found an issue with how the code is written.
according to the documentation, and from walking the code, it looks
to me like this is how it ends up working:
if DKSIGN is set
sign the message using the explicit key location
else if DKVERIFY is set
verify the message
sign the message using the default key location
i'm like jeremy, i have no RELAYCLIENT machines- the users on my
server all use AUTH, and the AUTH patch i'm using is one that i found
several years ago and modified so that it checks the qmail-smtpd
command line arguments, and will not advertise or accept the AUTH
command unless the command line is correct AND the connection is
secure (or it also sees an ALLOW_INSECURE_AUTH variable.)
i had never thought of exporting RELAYCLIENT in the case of a
successful AUTH, but the idea makes sense at first glance... i'll
have to look into that. i wonder if there's any reason that a
QMAILQUEUE program (simscan, qmail-scanner, etc.) would need to know
the difference between a message accepted because of RELAYCLIENT and
a message accepted because of AUTH... maybe for statistical reasons,
or maybe the AUTH status would bypass certain phases of being
checked... again, at first glance it looks like a good idea, but i'm
not sold on it.
i can also see a case where a given IP address may have RELAYCLIENT
status but you would want to verify the message instead of trying to
sign it. consider an ISP with a client who runs their own mail
server, on a non-static-IP connection, and the client's mail server
adds domainkeys signatures as it sends mail out.
if the client's mail server hands a message to the ISP's mail server,
the ISP might want their own mail server to verify their domainkeys
signature before accepting the message- particularly if the client's
domainkeys record states that any non-signed messages should be
considered forgeries and dropped. but where the client is using a
dynamic IP address, the ISP's mail server would ordinarily have the
RELAYCLIENT variable attached to their IP so that they can relay...
which would seem to mean that RELAYCLIENT may not always be a
reliable indicator of whether to sign or verify a given message.
granted, it's a rather contrived example, but i'm sure we've all had
clients who wanted/needed stranger things.
having qmail-smtpd explicitly set DKSIGN when a successful AUTH is
done is not the best answer either- what should qmail-smtpd add for
the value? what if the server operator wants to store the keys
somewhere other than the default /etc/domainkeys/%/default files? i
don't like the idea of compiling the details of my filesystem into
the code- i like having the flexibility to change the locations if
needed, or to specify different values in the tcprules file without a
client's un-necessary AUTH command changing the value back to some
i think having the DKSIGN variable serve two purposes- specifying the
location of the key files, as well as being a "sign or verify" flag-
may not have been the best design decision. i think that if a server
administator wants to store their keys in a non-standard location,
they should be able to set that globally if they like, without it
affecting the decision whether to sign or verify.
i'm not sure what the "right" answer is- i wanted to throw this out
there on the list and see how others, particularly russ, feel about
this. maybe i'm missing something and i'm concerned about a problem
which doesn't exist...
another idea is this- how about a cdb file which associates sender
email addresses (or domains) to specific key files? this would make
it possible for different users within a given domain to have their
own specific key files, if there's a need for that sort of thing (and
obviously there must be, the domainkeys standard makes a provision
for it.) this isn't just an idle suggestion- if there's an interest
in it, i will write the patch to implement it.
| John M. Simpson - KG4ZOW - Programmer At Large |
| http://www.jms1.net/ <jms1@...> |
| Mac OS X proves that it's easier to make UNIX |
| pretty than it is to make Windows secure. |
- View SourceOn Thu, 2005-09-01 at 02:28 -0400, John Simpson wrote:
> another idea is this- how about a cdb file which associates senderWhat we did was to have our qmail-dk use environment variables to
> email addresses (or domains) to specific key files? this would make
hold the key and selector; a database lookup using the 821.sender
or 822.from is used to set these variables (as well as others).
This allows us to have default policies that are override-able
on a fine grained basis.