Thanks Justin and Daryl.

> > (a) Is "From:addr" rather than "EnvelopeFrom:addr" the right header to
> > use?
> I'd say yes.  DK signs the message, not the envelope.  I'm pretty sure
> the current milters look for a From: header to decide on what
> selector/etc to use.

Right, DK (as well as DKIM) uses addresses in the header, not envelope.
DK would choose Sender if it exists, otherwise a From, to obtain the
signer domain.  DKIM is more sophisticated (could use Resent-From,...), but
basically, for direct mail the From header field is the most important one.

> (b) are Y! signing all mail?  I would have assumed some systems are not
> yet using DK.

This is a key question here. I'd hope yes, since Yahoo was the leading
proponent in establishing this technology (now aiming for DKIM).

Although their policy record still says 'testing' and 'signs SOME mail':

$ host -t txt _domainkey.yahoo.com
  t=y\; o=~\; n=http://antispam.yahoo.com/domainkeys

I think they are just conservative, trying to avoid some broken recipient's 
mailer from rejecting their genuine mail, or to avoid problems with mailing 
lists invalidating signatures when their user posts there. 

> In 3.1.x, you have to set priority manually, unfortunately, to be higher
> than both of the subrules.  in 3.2.x, it'll do that automatically for you.

Thanks for the info.

> Personally I'd cut the score in half.

Ok, perhaps.

> Slow DNS could cause FPs -- I've seen it happen
> on mail from rogers.com which Y! runs. 

Interesting. Further experience is welcome. The _domainkey.yahoo.com
TXT policy record has TTL set to two hours, and one of their public
keys (s1024._domainkey.yahoo.com) has a lifetime of 24 hours - so a
local caching DNS resolver is likely to retrieve the policy from
its cache, or from any one of the 5 registered Yahoo name servers.
As far as I can tell, it is a global Yahoo thing, not something
pertaining to one or another of their servers.

What about gmail.com? They seem to be signing their mail too
(see: host -t txt beta._domainkey.gmail.com) but also avoid full
commitment in their policy (no policy => default policy).
Any experience there?

  Mark

Reply via email to