> From: Chris Aseltine <[email protected]> > > We have an opportunity here to determine the form of the > > `Authentication-Results' header so that it can be most useful to DCC. > > I'd like to do this right. > > I wonder if, because Vernon considers DKIM and its ilk to be "homeopathy", > that indeed, he just does not care...
That is not my view. Whitelisting by DKIM is much the same as whitelisting by SMTP client (mail sender) IP address. You wouldn't whitelist all IP addresses just as you wouldn't whitelist all X-Authentication-Results headers. In practice, IP client IP addresses are harder to forge than DKIM. (which are easier today, TCP sequence number or DNS games?) It is reasonable to prefer DKIM to IP address when one or a few DKIM signatures cover an organization that with SMTP clients at many IP addresses or with IP addresses that change more frequently than its DKIM signatures. Consider the currently common reasonable (as opposed to original FUSSP nonsense) use of SPF in which a mail receiver maintains its own white (or somewhat white) list of domain names whose SPF records are used to verify that mail from example.com comes from the right IP addresses. It's a lot easier to maintain a list of domain names whose SPF records specify IP addresses to maintain the same list of IP addresses. Gary Mills also wrote: > >It's because the checksums need to be stable once I determine that a > >message with a DKIM signature has an e-mail domain that I trust not to > >send spam. I can't just copy them indiscriminately because those > >so-called e-mail marketing sites use signed messages too. I want to > >add them once to a file included in `whiteclnt' and not have to touch > >them again. If the header value changes in some minor way, the > >checksums will no longer match. I strongly disagree with the idea of "add them once to a file ... and not have to touch them again." The idea of writing any authenticator in stone raises red flags. You *must* plan for key expirations and revocations. Because X-Authentication-Results* headers are local and so not standardized, I don't understand the idea of getting them right or just stable except for a little while at some installations. There wouldn't be much more hope if they were standardized instead of locally defined and subject local changes. Because DCC doesn't decode DKIM headers except trivially such as ignoring whitespace, any X-Authentication-Results header format is as good as any other for DCC white- or blacklisting. Any format is as good for DCC as any other provided the header is constant for a given sender. So I recommend treating X-Authentication-Results like any other header or envelope value. Use the ones that tag mail you want to white- or blacklist, but be prepared for changes in IP addresses, domain names, DKIM keys, and the formats of X- headers added by your other milters. As a matter of general sane design, I'd omit irrelevant details from X-Authentication-Results headers. Nothing outside the DKIM module cares how many bits of key were used or which flavor of DKIM worked. Outsiders care only whether the DKIM module says the message is authentic. The question of what to do when DKIM, SPF, and other authenticators conflict should be decided inside the mail authenticating module, along with how many bits, which headers are covered by the signature, and the rest. The DKIM module should report on its summer vacation in a log and not an SMTP header. However, nothing in DCC needs more than a header that doesn't change on every message. Vernon Schryver [email protected] _______________________________________________ DCC mailing list [email protected] http://www.rhyolite.com/mailman/listinfo/dcc
