Tom Kistner wrote:
> Peter Carah wrote:
>
>> One of the outcomes that is needed is to be able to treat "no
>> signature" as a
>> bad signature error if the domain has a key and the message has no
>> domainkey
>> headers.
>
>
> Only if the domain has set SIGNSALL and !TESTING. (while I think the
> combination of TESTING and SIGNSALL is pretty weird).
I could see that combination during startup of a domainkey setup if there are
multiple mail or name servers involved (hard to do atomic updates when servers
are located all over the country). OTOH both yahoo and earthlink (the main two
users of domainkeys now) have t=y o=~ and both sign everything I've seen so
far. There are lots of yahoo and earthlink customers who work behind
forced-proxy firewalls (bunches of our own wireless customers, for example).
One has to figure out how to handle that kind of thing.
It is still interesting to log no-sig for anyone who uses o=<anything>, even if
one doesn't otherwise act on it. Also to inject a DomainKey-Status header for
spamassassin to look at (just don't make it conclusive unless you have signsall
& !testing).
>
>> This could be detected by looking for DK_FLAG_SET and no signature,
>> since I note by the comments (and looking in the library) that
>> non-participant
>> isn't an explicit outcome of the library (but such a domain would lack
>> DK_FLAG_SET).
>
>
> You should be able to construct your own logic for such cases, the Exim
> DK implementation simply grabs all the interesting bits from the lib and
> sticks them into the ACL system (as queryable conditions or expansion
> variables).
It's missing any reported outcome unambiguously corresponding to
!DK_FLAG_SET... I just added that in as DK_NON_PARTICIPANT if there was no
other outcome.
>
> deny message = DK: unsigned message or missing key from SIGNSALL domain
> dk_policy = signsall
> dk_status = no signature:no key
>
>> Admittedly if o=~ this isn't a "terrible" error, but "no signature" has
>> different meaning for domains with no _domainkey resources at all;
>
>
> If SIGNSALL is unset, there should be no difference in treatment for the
> "no resources" and "no signature" cases.
Logging... I want to log no sig for anyone where I'd expect a sig even though
not actually rejecting the mail. And I want to log (for now) some edge cases
that aren't of interest once many folk start actually using domainkeys.
(like !DK_FLAG_SET on earthlink or yahoo or yahoogroups addresses.) And see
above for spamassassin; you could give it a point or two for no-sig even under
testing (I've not seen any "real" mail out of either earthlink or yahoo that
wasn't signed, though I've only been looking for a day or two.)
>
> If SIGNSALL is set, "no resources" would be a remote configuration error
> and "no signature" would be a cause for rejection (see above).
SIGNSALL is impossible for the "no resources" case.
"no key" is a remote config error in case *any* flags are set, and not of
interest otherwise. OTOH my own domain is generating that. I guess I should
remove the flags record until I publish a key... Under o=~ it is only a
warning, and not an actual error, though.
However, I saw a confusing return in logs this morning, using my extended logic
(see patch attached), where a later 'dig' showed that the domain admin had put
SPF records under _domainkey.hisdomain.com. Admittedly lame, but the domainkey
lib counted it as DK_FLAG_SET. Someone will always find a way to screw up :-)
Maybe we want to lobby yahoo to add a prefix to domainkey txt records to remove
this kind of ambiguity. Like the interesting one between Kerberos 5 and SPF...
(both use TXT records under the bare domain. Always interesting to hit a realm
called spf...) (the spf folk should have used something like _spf.domain.com).
Actually spf is pretty much useless since it badly breaks remailers and the
sender-rewrite is both a kluge and undesirable. If the bad guys couldn't forge
headers it wouldn't be so bad. That is why I'm interested in domainkeys or
some other signed equivalent. (consider a spamassassin header on _sent_ mail.
They already forge virus-check headers on mail containing virii...) (and I am
seeing new versions of sober more than daily now.)
SPF can be of some use if (like aol) you use it to generate static permit data
and not actively filter every message (and especially if one could figure out
how to handle remailers).
Actually I have 't=y o=~' on altadena.net with no keys present... Maybe I need
to pay attention to my own rules (of course I didn't know what all the edge
cases were until logging odd outcomes).
I'm implementing this on only incoming servers for now, will add outgoing
later. At least it should catch yahoo.com forgeries (a large majority along
with hotmail). And I don't know which way google will go with gmail.
>
> Or did I miss something? :)
See above about an impossible case of SIGNSALL.
-- Pete
--- src/dk.c.orig Tue Oct 4 01:55:28 2005
+++ src/dk.c Fri Dec 9 10:53:10 2005
@@ -189,7 +189,10 @@
{
case DK_STAT_NOSIG:
dk_verify_block->is_signed = FALSE;
- dk_verify_block->result = DK_EXIM_RESULT_NO_SIGNATURE;
+ if (dk_flags & DK_FLAG_SET)
+ dk_verify_block->result = DK_EXIM_RESULT_NO_SIGNATURE;
+ else
+ dk_verify_block->result = DK_EXIM_RESULT_NON_PARTICIPANT;
break;
case DK_STAT_OK:
dk_verify_block->is_signed = TRUE;
@@ -220,7 +223,7 @@
dk_verify_block->result = DK_EXIM_RESULT_ERR;
break;
/* This is missing DK_EXIM_RESULT_NON_PARTICIPANT. The lib does not
- report such a status. */
+ report such a status. /PAC/ Use flags-not-set under no-sig... */
}
/* Set up human readable result string. */
