--On January 21, 2006 1:27:53 PM -0800 Joe Emenaker <joe@emenaker.com> wrote:
Stephen Gran wrote:If mail admins can't be bothered to do these most basic of things, what makes you htink the entire world is going to switch to using one of many competing ideas about sender verification?Um... because AOL, Yahoo, and MSN are already implementing it?
Have you even looked at AOLs SPF record? notice the ?all at the end? The net result of that is that even with systems using SPF it's a 0 change, except for yet another dns lookup. AOL knows that if they removed the ?all tag from the end they'd break a LOT of accounts using aol and sending to places implementing SPF. So SPF doesn't really help AOL either.
I think they were hoping that there would be some sort of improvement in it and were/are of the mind htat something is better than nothing. SPF is definitely flawed. Yes for some domains providing outbound mail is only an incremental additional load, for places that have either historically not, or have been forced by ISPs to tell their customers to use the ISPs mail server that represents huge additional amounts of incoming email.
Also, *YOU* try walking 5000+ random people through setting up outlook to use anything other than port 25. See how much time that takes you, then do the math for aol.com, earthlink.net, msn.com, hotmail.com etc.
Now I'm not saying SPF is a bad thing, I'm saying SPF doesn't work for a *huge* chunk of people. Hell on wgops.com I use SPF because it works for me for that domain. Not that it seems to have stopped any, or many, joe jobs. The places that get hit by the forged sender joe jobs that backscatter crap and are the most painful are also mostly the places that aren't doing anything else anyway. And the places that the SPF record helps block, they probabyl wouldn't have accepted the mail anyway because they're likely doing more than just SPF already.
SPF isn't a cure-all, it does help to limit/prevent forged senders, that's it. It's a step, not a cure. I'm not sure if there is a cure, I hope there is.
Several years ago, you probably would have asked the same "why would they bother?" about admins turning off open-relay. In retrospect, the reason why they bothered is because their failure to do so started affecting mail delivery. Same thing goes for SPF. If it starts affecting delivery of your system's mail, your admin is going to start catching heat until he/she gets with the program.Not to mention that of course spf has major implementation problems (forwarded email being the main one, but there are others).Granted. This is the big gotcha to SPF, that all forwarders have to be turned into remailers. But that's not that big of an issue. Change your flat alias files so that they feed into a script.
Try this.... Scale that up to...holdon let me check how much mail we forward because of AOL subscribers requesting their accounts forwarding.... Looks like atleast 60k/day on weekends and double that during the week from the one mail front end I checked. It's not a small nor trivial problem. It has to be supported in the MTA, and not by some small hack of a script, by a large distributed database, for my case alone, to work. We have a cluster of incoming mail servers, not one. Also those numbers are just AOL forwards. That doesn't include anyone else.
Also, you can't do it with patterns, atleast not anything remotely like anyone else is using, because if you do, they'll figure out the pattern and abuse it somehow to get mail forwarded through you. So it has to be a database, and whatever tagging you do on the rewritten envelope has to be reversible only by you, but has to be trivially reversible by you because your'e handling lots of email already.
Maybe spamming entities and ISPs should be disconnected and treated like the criminals. In the US, if you run a stop sign or speed, etc, because you didn't see the sign, you still can get the ticket. Ignorance of the laws and regulations does not provide immunity to them. Perhaps that's the stance that should be taken.
Right now, at modwest, we dump at LEAST 50% of the attempted SMTP transactions based on a decision that happens prior to receiving MAIL FROM or RCPT TO. These 50% are zombies on various internal and external *automatically* maintained blacklist. Granted, we do only a 4xx/tempfail message, but even still we get little to no complaints about missing email because of these filters. We reject up to a further 10% because the recipient is invalid. And up to another 20% or sometimes more is dropped by the various malicious content checking, virus scanning. Another pretty large chunk overall is either dropped, flagged, or put into a suspected spam folder spam rules on our users mailboxes based on their preferences, this last one depends on the user. I know of one user who, without the benefit of the last step of rules based preferences directed spam filtering goes from 3-8 messages/day that maybe one might be spam to over 50, almost all of which are spam.
Don't get me wrong I like the idea of SPF, but it's not a simple solution and doesn't solve any real problem for me as the Ops Manager of a large hosting company. It does require a lot of work and changes to mail architecture. Yes the same thing could possibly be said of the open relays, but at the time they fell into disfavor there was largely an already developed base of software that had the simple switch that only that mailer needed to use to become a not open relay, SPF is not that simple. Open relays only needed the open relay to stop being open. SPF requires that me, you, and everyone else invest a significant amount of time, money, and effort to develop, test, and deploy it, and methods related to it, such as the remailing forwarders. Without that significant investment SPF's small change is not even felt.
Like I said, my biggest problem with joe jobs has been to systems that wouldn't implement SPF anyway. The systems that didn't pass along the joe job were already doing other things that worked better than SPF, or instead of SPF.
SPF only provides the possibility of preventing a forgery from a non-qualified system, without the use of any sort of 'heavy' call backs like verizon does.
<..>