Major ISPs Publish Anti-Spam Best Practices

wayne writes "The ASTA, an alliance of major ISPs, has just published a set of best practices to help fight spam. The list of ISPs include the likes of AOL, Yahoo, MSN/Hotmail, Earthlink and Comcast. The recommendations include such things as limiting port 25 use, rate limiting email, closing redirectors and open relays, and detecting zombies. For details, see the ASTA Statement of Intent (pdf) or any of the ISP's antispam websites."

Comments

Take what they say with a grain of salt

[Raul654]

How many of those ISPs were caught in pink contracts?

Blocking outbound port 25

[Bronster]

Makes me really glad that I push all my email backwards and forwards through an openvpn connection to my mail server now. As long as my ISP doesn't block UDP port *mumble* I'll be fine.

My wife was not so lucky. She was unable to send email a few weeks ago when our cable modem provider instituted outbound port 25 blocking. Luckily it's really easy to set postfix up to listen for smtp on another port as well - one quick config change and she was back in business. I'm planning to install openvpn for Windows on her box one of these days.

Mail admin here, my solution was port 26

[aardwolf204]

As a mail administrator for a medium size company I've had to deal with residential broadband ISPs blocking access to port 25 a lot lately. It was a headache explaining to employees that work at home, at the office, and at customer sites, that they must change their outgoing SMTP setting in Outlook depending on their location. This is a true PITA as lots of times your not supplied with that information (or at least it is not obvious to the non-technical people), for example, internet access in hotel rooms.

For a while the quick and dirty solution was to use webmail when in doubt but we needed something that people could live with and as much as I dislike M$ Outlook its a lot better than Horde, Neo, or Sruirrel Mail (IMO).

My 80% solution now is to handle SMTP on both ports 25 and, hehe, 26. So far so good, I'm able to go between the office and home on my laptop with no problems where as before Cox Cable wouldnt let me get to our SMTP server.

I'm wondering what other admins have had to do in this situation. I know I'm not alone here. And how do you think it will effect the propogation of spam in the future.

Re:Best practices,... published?

[LehiNephi]

Attacking the source of the money--that, I believe, is the only way to kill spam.

That's why I run Unsolicited Commando. It fills the inboxes of companies that pay for spam with spurious form fill-outs. I guess it's kind of like giving them a taste of their own medicine.

Re:Don't forget SPF

[Dimensio]

I even noticed my ISP, Verizon, who tend to be quite lazy and stupid when it comes to spam (and other things), have added an SPF record.

I wouldn't call Verizon "lazy and stupid" when it comes to spammers on their network. I would call them "criminally negligent".

They had a spammer's website on their network for over a month. The spammer was selling a product that was blatantly illegal (digital cable descrambler). The only possible way that their product could have been legal was if it did not function as advertised, and then they would have been committing advertising fraud, so either way they were breaking the law and Verizon was allowing it to happen on their network. After a MONTH of daily complaints about the site, it only disappeared AFTER I setup a webpage documenting Verizon's open support of criminal activity and started advertising it in my .signature file.

No legal threats were ever issued to me. I guess that Verizon knew that I had truth on my side.

Where are the best practices

[linuxwrangler]

This was just a bunch of fluff. I was hoping for some meat. The big ISPs have enough clout that if they force the issue of good practices everyone will have to adapt and the people who will have to adapt are those with broken non-RFC compliant servers.

Best practices can encompass the RFCs and extend them to, well, best practices.

For example:

Per RFCs every place a domain is used it must be fully qualified and resolvable. In addition, the EHLO is supposed to be the primary hostname of the sending machine.

Anti-spam best practice might say that the machine name must resolve back to the connecting IP. Even better, the reverse entry for the IP must include the correct hostname. This way a receiving machine can determine who the sender claims to be, that the DNS entry for that name matches the IP (anyone can spoof the header but it's lots harder to get to the DNS of a legit operation) and that the reverse DNS shows the correct hostname (which would be harder on those who have low-end connections where they don't have control over the reverse DNS entries but no problem for most IT operations - anyone with a small operation can send through their ISP anyway).

If the major ISPs required just these items to match there would be a brief period of pain while everyone scrambles to fix broken systems but the gains from stopping viruses and spam would be enormous and tracing back to and blocking the remaining spam would be easier.

I also saw nothing about information sharing among the large ISPs so they could quickly act against a spammer or quickly disable the web accounts to which the spam is directing people (carefully, of course, or fake spam could be a means of a DOS attack).

Similarly, there was no mention of blocking email where the from address doesn't match the ISP. A couple years ago I dealt with massive backscatter from spam sent by an Earthlink customer THROUGH the Earthlink server. I tried to get an answer from them on why they were allowing someone to send out email "from" our domain when they have no relationship to us. Silence. Sure this is a pain for some people but people who want legitimate extra services can sign up for them. It's not so different than paying for a static extra IPs. If you want to send from a different domain we'll unblock it for you for a small monthly fee after determining that you are authorized to represent that domain.

This just scratches the surface but all in all this "best practices" is a joke.