Unsolicited email has been around nearly as long as the concept of ‘email’ itself, and people have gone to extraordinary lengths to design web and software-based solutions for intercepting said spam, utilizing mathematics based on Bayesian statistical classification. For the most part, they actually work remarkably well; I can barely recall the last time I’ve had to manually delete spam email from my work and/or Gmail account inbox. Heck, my current spam filter could probably beat me in a game of chess.

However, most current anti-spam solutions are invoked only upon the reception of an email (ingress based filtering), placing the responsibility of spam filtering squarely on the shoulders of the recipient, rather than the sender (egress based filtering). A virtual bottleneck thus ensues, whereby your email client (desktop or web-based) must protect you from the never-relenting onslaught of little blue pill adds and Nigerian princes who want to give you a piece of their fortune, both of which have become quite prolific in the past several years.

A recent discussion thread on The Usenix Special Interest Group for Sysadmins (SAGE) has revived some interest in the concept of ISP-based outbound SMTP filtering, whereby the service provider could perform their own spam-filtering duties on outgoing emails, thus preventing a large chunk of junk mail from being distributed in the first place. While there are several political, technological and economical issues that would need to be resolved in order for any of this to ever become effective (see the discussion thread for insightful commentary on all of these topics), it would be difficult to argue that the two-pronged approach would be less effective than ingress-based filtering alone.

Until more ISPs are convinced that by implementing outbound SMTP filtering they would be saving more money than spending, however, I’ll continue to think of my inbound spam filters like the Spartans at the Battle of Thermopylae - they’re quite good at doing their job, but inevitably they will be overwhelmed by the sheer number of their enemies.

Some Hot Spot allow anything out, other block 25 out, but as you know a lot of OnLine service use ports other than 25 to send out eMail.

 If all HotSpot or  It administrator were blocking SMTP at a higher level, whatever the port used ( FireWall at the application level), it would help a lot… Else if an IT administrator block 25 out for his stations, but allow any other ports outbound, it’s a question of time before some spam goes out using some external relay server on a weird port other than 25

 Any comments are welcome.

 It’s providing virus Writer/Spammer an easy way for any infected stations to Spam the planet.

Only eMail server should be able to go out on port 25..

Probably some of your already experienced how painfull it could be to be removed from IP addresses BlackList… Often we endup changing IP as a shortcut (for for how long)

Note : Several eMail security provider or eMail security product product allow customer to make their Outgoing email be filtered.

http://www.virusbtn.com/news/2007/09_07a.xml?rss=

The case was first brought last autumn, and after initially challenging the charges Spamhaus withdrew from the case, as the US court in which it was brought had no jurisdiction over the organisation’s UK-based operation. e360 was thus granted a default ruling in its favour, with the $11.7 million fine called for based on its own uncontested evaluation of the damage caused by Spamhaus filtering out its mails. The spam fighting organisation was also ordered to apologise publicly and to remove e360 from its ‘ROKSO’ list of known spammers in perpetuity - another ruling whose legality has been questioned by the appeal court.

The appeal court ruling still grants 360 the case, due to Spamhaus’ refusal to contest it, but has passed the settlement award back to the lower court to be analysed more closely. Spamhaus continues to include e360 on its list of spammers, and has suggested e360 brings the case to a UK court, where its activities would fall under stricter anti-spam laws. Attempts by e360 to have Spamhaus’s domain registration revoked have been ignored by US courts.

A Wired.com blogger looks into the case in more detail here, and carries a full copy of the latest ruling (in PDF format) here.

07 September 2007

As you know it’s  now very important to comply to all e-mail internet standards if you want your eMail to be accepted by e-mail security solutions and large provider

SPF records (TXT records) known as Sender Policy FrameWork http://www.openspf.org/

This very important DNS record confirm from wich IP addresses eMail from something@yourdomain.com may originate.

It helps detect e-mail address forgery (i.e. My e-mail address is user@domain.com and I’m sending an e-mail message as if I was user@yourdomain.com.

Imagine that I pretend I’m you@yourdomain.com and send 3 millions e-mail messages Smile, and that most of those eMail are sent to invalid addresses. To whom you think the NDR will come back…? You!

You must be very carefull if some of your remote user don’t send e-mail from the main office (let’s say some ISP smtp server), then ISP mail server must be included in your SPF. If every e-mail are sent from your main office from a single IP, then it’s really easy. One way to avoid having to deal with ISP smtp servers is to use VPN connections or SMTP-AUTH for roaming users.

http://www.mtgsy.net/dns/spfwizard.php is one tool I found (one ISP tool) that is easy to use.

PTR records/ Reverse DNS records

More and more e-mail servers are doing a reverse lookup of the sending e-mail server. When you don’t have a PTR record or have a generic one (like isp-pool-adsl10-90-122-32, then they could refuse the e-mail (SMTP) communication, or consider the message as spam.

The Hosting or ISP providing the IP address is responsible for setting PTR records. So you should request them something like :

Please create a PTR record for us :

IP address: 209.200.200.256 match mail.ourcompany.com (fictive address, doesn’t even exist)

(HELO / EHLO)

 When you set up an e-mail Server, it often takes a default name for the HELO greeting. Basically when your e-mail server talk to another e-mail server, it is saying : Helo, I am mail.ourcompany.com 

Some hosting company or security solution could refuse to communicate with you or consider e-mail from your server as spam if the HELO do not match the reverse DNS, or if it doesn’t make sense.

Example : most Microsoft IT people, when they install an Exchange server in a Windows Active directory environment, forget to set the HELO greeting so the SMTP Banner end up being ’servername.domain.local’. This is not a routable internet FQDN (and an HELO greeting should be).

So to avoid any problems, make sure the HELO also matches the A records & reverse DNS (PTR) of that machine.

So, in our example, to be compliant:

IP address: 209.200.200.256

HELO: mail.ourcompany.com

PTR record for 209.200.200.256: mail.ourcompany.com A record for mail.ourcompany.com -> 209.200.200.256

Any comments are welcome

 As spammers continously adapt themselves to new AntiSpam techniques, I think that AntiSpam companies will have to  work hand in hand with ISP and major internet backbone providers,  to use some kind of “transport analysis methods” to recognize spams.

 If a guy arrive at a bank with a Tank and a bazooka, we don’t have to ask him his ID or where he come from.

I think by beeing more strict as for who can send eMail on the internet (toward port 25) it would make spammer’s life a nightmare.

Probably a lot of your had to deal with organisations very sensible to eMail confidentiality.  We must not forget that eMail travel “clear text” on the internet.

The experience I personally had was that most of the time, some of the mentioned methods required a lot of time to deploy, a lot of training,  and finally companies were dropping those projects.  Some companies are really forced to encrypt communication and will continue with actual technologies.

I was wondering what you think will become “the” standard as for eMail encryption/confidentiality methods

I’ve then call back to fall on an interactive voice response service, offering me an outbound unlimited mobile phone service.

A new annoying technique.. Dial / Hangup, hoping they’ll receive a call back.

It simply use a CSS technique that hides a field, and basically, bots don’t see CSS, so if the field’s not empty, it’s a spammer.

Just take a look at it! I think it’s worth it.

Preventing SPAM without using a CAPTCHA