Spam Filtering: June 2005 Archives

Mailscanner allows for a very fine level of control over email content and security via its configuration and ruleset files. This article shall look at setting up per user or per domain rules for file types. It is based on my experience with MailScanner on RPM based systems, however it should work on any system running a standard install of MailScanner. Why would this be of interest? If you are scanning mail for multiple domains and companies you may wish to impose restrictions on certain file types for particular users or, as is more often the case, these restrictions will be forced on you. Getting Started If the server is in production you may want to stop MailScanner processing mail while you make the changes to its configuration: /etc/init.d/MailScanner stop;/etc/init.d/MailScanner starting This will stop MailScanner and then restart its "in" queue, so mail will "sit" in the inbound queue. Open MailScanner.conf in vi: vim /etc/MailScanner/MailScanner.conf Look for the line : Filename Rules = %etc-dir%/filename.rules.conf In order to make this a ruleset which you can control you should change this to something like: Filename Rules = %etc-dir%/filename.rules in /etc/MailScanner you need to create the actual ruleset file. The way I did it was: FromOrTo: default /etc/MailScanner/filename.rules.conf FromOrTo: *@domain1.ie /etc/MailScanner/filename.rules.domain1.conf FromOrTo: *@domain2.com /etc/MailScanner/filename.rules.domain2.conf The first file: /etc/MailScanner/filename.rules.conf is the one that ships with MailScanner (with or without sidewide modifications). The other file(s) contain domain/user specific directives. For example, one of our clients asked us to block ALL zip files, so the custom ruleset contained one minor, but important, difference: deny \.zip$ - - If you have been "hacking" MailScanner for a while you will know that you can specify rules to apply to an entire domain: *@domain.tld or a specific user: user@domain.tld You could also do it using something like: From user1@domain.tld and To user2@domain.tld The README is helpful: As you can see, each rule has 3 fields: 1. Direction (or "Virus:") 2. Pattern to match 3. Result value (or values) or 6 fields: 1. Direction 1 (or "Virus:") 2. Pattern to match 3. The literal word "and" 4. Direction 2 (or "Virus:") 5. Pattern to match 6. Result value (or values) Your mileage may vary :)

There has been a lot of commotion in technical circles in the past week following on Microsoft's announcement that it was implementing Sender ID for hotmail. Microsoft's original plans for sender ID seemed to be quashed when the Open Source community, most notably the Apache Software Foundation, made it clear that they did not support Microsoft's implementation. The original MS version of sender ID seems to have fallen by the wayside to be replaced by SPF, which I mentioned a few months ago. What is causing some confusion is Microsoft's insistence on referring to it as "sender ID", while all the documentation on their site points back to the SPF homepage. Is there any difference? It would seem not. In the last week a number of our clients who hadn't already published SPF for their domains did so and we are now publishing a basic set for our primary domain. Should we applaud Microsoft? I think not. A more responsible attitude would have been to allow people a bit more time to prepare their DNS. Having said that, SPF records are not particulary complicated, but it still requires some thought to set them up. If you are only sending mail from one mailserver and never from any other and do not outsource any services to 3rd parties that may send email on your behalf, then an SPF record could be very simple. Have a look at the one from aol.com: aol.com. 300 IN TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" aol.com. 300 IN TXT "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" It's not overly complex, but if you compare it to mine for this domain: mneylon.com. 900 IN TXT "v=spf1 a a:tristan.blacknight.ie -all" you can see that they have had to take into account more complex factors. Microsoft.com on the other hand, is being "clever": microsoft.com. 3600 IN TXT "v=spf1 mx redirect=_spf.microsoft.com" they are actually sending you off to check against _spf.microsoft.com which has: _spf.microsoft.com. 3600 IN TXT "v=spf1 ip4:213.199.128.139 ip4:213.199.128.145 ip4:207.46.50.72 ip4:207.46.50.82 ip4:131.107.3.116 ip4:131.107.3.117 ip4:131.107.3.100 ip4:131.107.3.108 a:delivery.pens.microsoft.com a:mh.microsoft.m0.net mx:microsoft.com ?all" Even their SPF record might not be entirely comprehensive. Microsoft have been known to outsource some mailing lists to 3rd parties, so why aren't they mentioned? So what of Irish business? Who is publishing SPF? Newsweaver isn't, Techcentral.ie seem to be oblivious to it, as are ENN and those are just a small selection of email sources that I receive mail from regularly. DirectSki.com are publishing SPF, but they seem to be in the minority. What's even more amusing is that one of our competitors who fancy themselves as providers of antispam haven't even bothered to do it. Will this mean that they'll all be rushing to rectify the situation over the next few weeks or will they remain in blissful ignorance? I guess we'll have to wait and see, but with SPF being adopted by some of the largest free email providers it is only a matter of time before the rest of the world is forced to follow suit.

A couple of months ago I mentioned sendmail milters. Snert are no longer offering all of them under an open source license unfortunately. In some ways I can understand why they are doing it. Even programmers have to eat :) - however it is still sad to see software licenses changing like that. The milter we are using, milter-ahead, is still available as "Free Source", but milter-sender is now commercial.

An updated version of SA was released earlier today. There are some bug fixes plus the addition of the SURBL JP DNSBL Download it from your local mirror Thing

URIBL has recently launched with four new blacklists of URIs. The criteria are similar as those used by SURBL. There are four lists currently available: * black.uribl.com - Which is an aggresive list of known spammers. With a goal of zero False Positives. * grey.uribl.com - Which lists people who spam and have legitimate uses. This will cause False Positives for some depending on your definition of SPAM. * red.uribl.com - Experimental list for new domain registrations and mass moves between registries that are defined as spam supporters or facilitators. Use at your own risk. * multi.uribl.com - Which checks to see if a domain is on any of the lists. I added them to our filters last week and the results so far have been very good. Instructions on integrating them with your existing SpamAssassin setup may be found here There is also an easy to use submission form where you can report either URIs or full spam examples with the URIs.

Today I discovered that Comodo had launched a "wonderful" new anti-spam product. It's great! It will stop all spam effectively. It will also stop any effective communication via email in the process, but surely that is a small price to pay for keeping your inbox clean? I think not. I tried to send a business email to them today but got this really "helpful" message back from them: Hi, this is XXXX. Your recent email has been delivered to my computer, but because you're not yet in my trusted senders list, it hasn't been placed in my inbox. To get added to my trusted senders list, please reply to this message with my AntiSpam passcode. Here's all you have to do: 1. Press Reply 2. In the body of the reply, type in my AntiSpam Passcode: 3. Press Send. When I receive this reply, I will know that it was really you that sent me the email and not a computerized spammer. I will then be able to read all your mail. This authentication will be done only once. Thank you & have a great day, XXXX Easy? Let's have a look at what I got in my inbox: Note the total lack of an image or code of any kind. What does this mean? Well, basically it means that the idiot is "protecting" his inbox with a defective tool. I don't care if it's a transient bug in their software or whether pigs fly. Due to their stupidity my email has not reached the intended recipient, so if I was trying to place an order ie. spend money with them, then they have lost the transaction. Brilliant, isn't it? I've never been in favour of CR (challenge response) as a method to "fight" spam, as it breaks the entire communication stream. There are plenty of ways that you can block spam and still maintain your business relationships safely. The Comodo method is obviously not one of them. I would love to know what they were thinking when they decided to "protect" their inboxes using it. Maybe they'll learn or maybe they'll lose business as a result of their stupidity.