[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qmail
Subject:    Re: Domain keys question
From:       Matt Simpson <net-qmlist () jmatt ! net>
Date:       2006-05-25 21:22:50
Message-ID: p06230907c09bcb36c6d4 () chowder ! foxhunters ! org
[Download RAW message or body]

At 2:40 PM 5/25/06, Russ Nelson wrote:
>
>Sure!  What should the user interface be, however?  That's what I'm
>saying I don't know.  Or should I just figure out what is the correct
>thing to do in every case, and not give people a choice.  What kind of
>options are needed, if any?
>There are many ways to use this information beyond a binary "deliver /
>bounce".


Tough question.  My answer may be different from most people.  I'm 
not running spam-assassin, or any other rules-based spam filtering. 
So I would prefer for qmail-dk to make a binary "deliver/bounce" 
decision, rather than returning a code to be queried by some other 
software that I'm not running.  But others might prefer more 
flexibility.  If the decision is going to be made in qmail-dk, the 
interface may become hopelessly complex if you want to provide more 
flexibility.


Back to the original question of handling mail with no signature, 
when the policy says all mail is signed, I can think of a couple of 
ways to change qmail-dk to handle the situation with the existing set 
of parameters.  Neither may be popular, but here they are:

1) Treat mail with no signature as a "bad" signature if the domain 
policy says it should  be signed, i.e. reject it if the BADSIG (Bb) 
flag is set.  Semanticists could probably have a field day arguing 
this one.  It could be reasonably claimed that a signature is "bad" 
if it's not there when it should be.  On the other hand, others could 
claim that something could not be bad if it doesn't exist, and that 
mail should not be bounced for lack of signature unless the NOSIG 
(Cc) flag is explicitly set.

2)  If the NOSIG (Cc) flag is set, bounce unsigned mail only if the 
domain policy says all mail is signed, and ignore the Cc flag if the 
domain publishes no policy or public key.  From a practical point of 
view, DomainKeys will (probably) never be so widely used that it's 
safe to bounce all unsigned mail.  So the existing  C option to 
reject all unsigned mail is not something any sane admin would ever 
turn on, and is therefore useless.  It could be more useful if it's 
behavior was conditional.  But again, there's room for disagreement 
here.  Some might disagree with my prediction about the future usage 
of DomainKeys, or the (in)sanity of rejecting all mail that does not 
use a feature that is not widely used.  Some people might want to be 
more aggressive to try to force the use of DomainKeys.  I remember 
the dark ages when most SMTP relays were open, and they might not 
have gotten closed as quickly if the early vigilantes had not been 
willing to lose a lot of legitimate email by blocking all mail from 
open relays to force people to close them.  The same scenario might 
happen with SPF, or DomainKeys.  Some aggressive early adopters might 
be willing to force the issue, and might not like my suggestion of 
changing that  option.

A less controversial option might be to add another flag, which would 
specifically mean  "reject unsigned mail if the domain says it should 
be signed".  This would do exactly what I want.  But from a design 
point of view, I'm not sure it would be ideal.  It might be ambiguous 
if someone used it in combination with some of the other flags.  And 
it might raise the question of how many other combinations of 
circumstances qmail-dk should be expected to check for.  If this 
feature is added, then somebody else might say "Yeah, that's nice, 
but what I'd really like for it to do is ...." and you have to wonder 
where to draw the line on feature creep.  This is where you get back 
to the idea that maybe it's better to just return the information and 
let some other piece of code decide what to do about it.  Not what I 
want, but maybe the most logical design option.
[prev in list] [next in list] [prev in thread] [next in thread]