This is thomasrutter's Typepad Profile.
Join Typepad and start following thomasrutter's activity
Join Now!
Already a member? Sign In
thomasrutter
Recent Activity
Another point that could be made is that not all these measures are about getting past spam filters. Having a reverse PTR that's not faked definitely will help you, and not just with email. That's the most basic thing you should get working. DKIM and SPF can prove that you are the domain you claim to be, but they don't prove in their entirety that you're not a spammer. There's nothing that says a spammer can't have an IP address and domain name, and due to incompetant or criminal hosting companies they often do. In terms of beating spam filters, passing something like DKIM or SPF is going to be one of a number of factors that a filter may use in their decision, and content-based spam filters are certainly not becoming obsolete any time soon. It's a simple point, but worth saying; there isn't a magic bullet to spam prevention not getting past spam filters. What DKIM and SPF can do, however, is cut down on a particular type of spam, where a spammer falsely poses as some reputable company.
It's a good article, except that in the Gmail section you incorrectly conflate "Reverse PTR" and "SPF" - these are two separate things. Gmail and port25.com aren't actually reporting on whether Reverse PTR checked out. You're right to say that SPF is a nice-to-have these days, and DKIM is more important. Lots of other articles on the web say the reverse, primarily because a few years ago, SPF appeared to have taken the lead. SPF is actually badly thought out - it's debatable as to whether it is even a good idea to use it. Certainly you should never reject any email that fails an SPF check, because there are just too many normal, legitimate situations in which it may report a failure. SPF makes the false assumption that if the recipient server isn't getting the mail delivered directly from the sender's MTA with no hops in between, then the mail is illegitimate. It's not hard to see where this fails: if the recipient has set up his mail account to redirect mail to another, that adds an intermediate server that the sender has no control over. If the final receiving server does an SPF check, it sees that the mail has come from an unrecognised server, which doesn't match the sender's server. This happens even if the mail has not been altered in any way by that intermediate server. The sender has no way of anticipating or avoiding this fail condition, except either to a) not use SPF at all or b) use SPF with "?all" at the end, ensuring mails that fail the check are not penalised. On the other hand, DKIM acknowledges that mail may pass through more than one server on its way to the destination, and even goes so far as to check that it hasn't been tampered with on its way. There's far fewer situations where DKIM is likely to give a false fail, though there are a couple of edge cases. One is where an intermediate server or proxy (such as a virus scanner) adds a footer to the bottom of mails. Another is where a mailing list server alters some of the headers of the mail before sending the mail out. In the first, you could argue that such tampering by intermediate servers /should/ cause a DKIM failure. In the second, there are other options for mailing lists: they could verify and remove the DKIM header, possibly even re-signing the message with its own DKIM header matching the new Sender address and headers.
thomasrutter is now following The Typepad Team
May 2, 2010