|
Andy, Thanks for the kind words. My answer was more so an indirect response instead of a direct one. As far as your points go, please allow me to piece them out. a) It is plain fact that the largest providers do check SPF, which in turn means that Joe-Jobs have a drastically lower impact on the spoofed domain's owner. It depends on the joe-job. Most of them target random domains and not necessarily the largest providers. If providers are rejecting on SPF-FAIL alone, then that is actually even more reason for me to not implement SPF on my own domains and advise customers to skip this as well. There are just too many legitimate exceptions to this that would cause an SPF-FAIL on a strictly defined record. If I was to define the records less specifically, it doesn't have much practical use since this would be like saying it can come from anywhere...and in fact it can. The worst joe-job bounce issues that I see are where the open relay itself is what is bouncing the majority of messages. Open relays are not likely to support SPF. Other servers that bounce the joe-jobs are ones that accept all E-mail without authenticating, which is a huge mistake in this day and age, and I wouldn't expect for them to use SPF either since they can't seem to figure out how to validate addresses which is 100 times more important. b) It is also a fact, that spammers are very SPF aware (to the point that they create SPF records.) Static spammers (where they spam from their own servers) are aware of SPF and abuse it. Zombie spammers can't make use of it and they are a whole different class in terms of what they do. Forging is almost exclusive to zombie spammers. They can be very sophisticated, but they don't cleanse their databases of things like SPF, they just generally rotate through either fake or known addresses as they attack servers with millions of addresses that mostly don't exist in the first place. I have also found that many of these guys cache the IP addresses corresponding to MX records and they don't refresh this data for very long periods of time if ever. I have changed MX records for domains that are still being spammed on the original IP over a year and a half later. This is why we always attempt to lock down our gateway customer's servers, or at least try to get them to change IP's if that isn't practical. c) Based on my personal, admittedly anecdotal, experience (supported by common sense) it further appears to me that SPF protected domains would be less likely to get picked for Joe-Jobs than unprotected domains. This kind of points to my reply to a). I don't think that the zombie spammers care. They will attempt 1 million addresses on a domain with a single valid user, they don't care if every attempt is accepted or rejected, and they aren't even trying to capture the rejected addresses so save themselves processing on future attacks. They aren't really even dictionary attacks by definition, they are just brute-force spam runs. While you might have experienced some anecdotal proof of them caring about SPF, it doesn't make sense to me that they would ignore bigger issues such as repeatedly hitting invalid addresses and not bothering to update their IP cache of MX records. These guys are social misfits, many of them with tens of thousands of zombies in their bot networks, and they don't care to micro-manage things. Success to them is not just spamming a particular site, but also causing a bounce, overwhelming a server, or even just pissing you off. I think that you might have the perception that these guys care. I don't think they do. SPF just isn't anywhere near accurate enough for me to want to use on my system for catching spam, and it would create some double-hit problems with SPAMDOMAINS. I can control SPAMDOMAINS, but I can't control what someone does for their own SPF records. Many domains, especially the larger and more actively used ones, have many examples of fully legitimate use that will fail SPF, and while I might be smart enough to not block on that alone, there are others around here that will most definitely at least hold a message if it hits SPF-FAIL, and again I have no control over that except to either configure SPF records for every address, or not configure it at all. Since SPF has come out, forging spam has dramatically increased, and dictionary attacks have become much more common and fierce. I tag this stuff with much more reliable tests such as Sniffer, enhanced URIBL functionality, DUL lists enhanced by my own data, technical heuristics that find zombie spamware patterns, blacklists, and custom combo filters that know that a combinations like a DUL hit, a Sniffer hit and an XBL hit together is stronger than the three alone. It works incredibly well on my system and I don't feel that I need any more tools to block such things, though tweaking them can help of course. My opinion remains that SPF, while well intentioned, lacks the ability to be accurate enough to be used reliably in real world circumstances, and it can create more issues than it solves on even properly administrated systems. It totally fails at it's original primary goal of authenticating good E-mail. All of these issues should have been obvious since the very beginning. IMO, this effort should have gone into pushing port 587 functionality and adoption in not just mail servers, but also in mail clients as a default config so that we could move towards blocking port 25 on broadband connections without affecting legitimate use. This would cut down on not just spam, but also the viruses that opened the computers in the first place. Resistance to blocking port 25 is totally a consequence of not having a legitimate alternative. Matt Andy Schmidt wrote:
|
