Archive for the 'Tips and techniques' Category

Should Internet Service Providers Filter Outbound SMTP traffic?

Nov 21, 2007 in Tips and techniques

While most of the current tech-related news regarding ISP content-filtering centers on a certain other protocol, ISP-based SMTP filtering is an issue lurking in the shadows that I feel should be given more critical thought, especially given the potential effect it could have on The War on Spam (TWoS). Before many of you start screaming about privacy issues and other possible personal rights infringements (in which you would be fully justified, of course), let’s put that aside for the moment and consider the more immediate pros and cons of such an arrangement.

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.

Hot Spot responsabilites, should they allow Outgoing SMTP connections ?

Nov 21, 2007 in Tips and techniques

I personally think that Hot Spot should do “application firewalling” and not allow SMTP connection out, whatever the port used. 

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.

Reminder : Restrict port 25 at the Firewall (outbound)

Nov 20, 2007 in Tips and techniques

Too many IT administrators forget to restrict wich  IP addresses on their network can send email out, I mean to use SMTP Outbound

 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.

eMail Best practices for IT administrators

Nov 19, 2007 in Tips and techniques

Hi All

 

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

 

Future of actual AntiSpam methods ?

Nov 18, 2007 in Tips and techniques

What is the future : improving body/content analysis methods or Transport analysis methods  ?

 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.

We’ve found the spam bot!

Oct 17, 2007 in Tips and techniques

A little joke, to smooth the mood !

Spam Bot

An ingenious way to filter spammers through your Web form

Oct 17, 2007 in Tips and techniques

Here’s a link to a page that teaches a new way to help you filter the spammers to post through your web forms.

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