On Tue, 8 Jan 2008, SM wrote: >> If you receive an email you only receive one subject so how do you >> compare the original if you don't know it. Could compare it to a z= >> header if the sender added it. > > You can only compare if you have the z= tag.
...or if you can apply some kind of heuristic to the Subject: header thus generating one or more possible originals. >> True - but how do you identify a mailing list compared to a normal >> email reliably? This is the key: You can't. A mailing list could be as simple as an alias that expands to lots of other addresses. In that case the "List-*:" header fields mentioned elsewhere in this thread don't get added, yet there's clearly a change in recipients, the To: header doesn't match anymore, etc. Some MLMs munge Subject: headers, some don't. Some add footers, some don't. Some that do add footers add the same one each time, some select from a rotation of possible footers of possibly different sizes. There's no single uniform behaviour or common property among them to distinguish MLM traffic from "regular" mail. We definitely wish that weren't the case. Similarly, there's no standard or universally applied form for auto-responders (e.g. vacation messages) either. > You are equating verification failures with "bad" mail. I consider the > failures as unsigned mail. I don't reject on failures and as such I > won't lose mailing list emails. If your (one-to-one) email is DKIM > signed and verifies, it's easier for me to whitelist you without having > to track any IP address change at your end. If the email goes through > forwarders, it will still verify successfully. I'm not sure what you > mean by actions and delays. I can also use DKIM for "reputation" > assessments. I cite this paragraph only to indicate that I agree with each of its important points. Moreover, several places in the DKIM RFC make clear that a message whose verification fails should be treated as unsigned, not discarded outright. Of course, the verifier can do whatever it wishes with failures. For example, the SPF/SID filter we wrote was originally intended to add an Authentication-Results: header and be done, but people requested that we add patches to it to actually reject mail that failed either or both tests. Clearly people are looking for anything they can get to stem the tide of spam and phishing, even taking very aggressive measures to do so. But as a result, false negatives then become a big risk. The generally recommended use of all of this authentication work is that a verification "pass" using a method you trust should simply bypass some of your spam or virus checks, a form of whitelisting. Failures can happen for legitimate reasons (Yahoo! DomainKeys signatures break when Yahoo! groups sends mail, for example; some Google mail also fails when it goes through their list distribution service), so you have to take that into account when making your ultimate reject/accept decision. Interesting discussion! -MSK ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
