Slashdot Mirror

milter, that is.

See http://www.milter.org

I am currently working on a project to do what AMTP wants to do. TLS + Milter is about as effective as you can get today for policy enforcement. AMTP has the possible benefit of having faster code (if written in C) but then again, you could code your milter in C as well.

I'm more waiting for SASL and reverse MX's to take off. That will be just as good IMHO as root CA chain singing.

Hrrrumph.

I too have noticed that the vast majority of spammers now seem to forge the HELO/EHLO greeting. And as most non-spammers don't, this is actually a wonderful way to catch them. I've even seen them send the IP address of my secondary mail gateway in hopes that my primary mail server would fully trust it (obtained probably by looking up my MX records). I run a mail gateway for a corporate domain an get on average 30 to 40 thousand spams per day. Using sendmail with it's milter programming interface I put the HELO greeting though a very strict check. For those contemplating doing the same...

• Per RFC 2821, the HELO greeting string should be either the FQDN of the sending hostname, or the IP address of the sending system in SMTP syntax (e.g., [1.2.3.4] or [IPV6:abcd::1234]
• Most spammers don't even bother with a domain name, using a random greeting like "sqss7e". If it doesn't have a domain, throw it away. Same if you see an IP address without the [] brackets; it's another dumb spammer that can't read the RFC's.
• Sometimes spammers don't even hide their spammy-sounding names in the HELO greeting even though they go to a lot of trouble to make up legitimate From headers. A good regular expression check for common words like "offers" or "optin" in the HELO greeting can work wonders (but use caution).
• When checking if a spammer if forging your own address, be sure to check for ALL hostnames under your domain (say you have acme.com, then check for both "acme.com" and "*.acme.com", and use a case-insensitive comparison). Also check for ALL your possible IP address even if you don't use them all. A remote site using your own IP or hostname is never legitimate.
• If you are running a gateway, you need to treat outbound versus inbound messages differently. This can usually be done by checking the connecting IP address to see if it is one of yours. Also be sure to check for 127.*.*.* and ::1 (IPv6).
• Be aware that some mail clients are broken and don't send conforming HELO greeting; this includes Mozilla (see Bug 68877). So don't be too agressive with your HELO checks for mail originating from the inside of your organization.

One last note about Forged AOL Spam after talking to one of their postmasters...all their legitimate mail by corporate policy is always sent from within the *.aol.com or *.aol.net domains. This will be in both the HELO as well as a reverse DNS lookup of the connecting IP address. If you don't see this in the HELO and DNS but you see a MAIL FROM for aol.com, it's probably spam.

I wish more big ISPs would provide public information about how to better detect forged mail claiming to come from their sites. For instance if I see a MAIL FROM *@yahoo.com, then should the connecting IP address always be from a *.yahoo.com host? Some ISP's like hotmail seemingly always add in a known predictable header whose absence indicates spam. But I can't reliably make these calls unless the ISPs provide that information. Also, beware that some semi-legitimate sites, like Monster.com forge the sending address on purpose; so if you want to receive resumes you may need to whitelist them.

"Excessively slow server detection will be a standard feature of all next generation spam software"

Let's hope so. Then I'd just accept all mail slowly and spam would go away!

Seriously there are flaws in this kind of defense. First, I'm already seeing several spammers who already send mail slowly, probably to avoid setting off statistical trappers and to make it harder to scan through log files. Also don't forget that the spammers usually have much more bandwidth than the recipient; you can never win by trying to fight the battle of resources!

BTW, this is NOT very tricky programming to do if you use the Milter programming interface to sendmail...in fact it is quite easy to do. But like I mentioned, you're sort of self defeating, because you burn your own resources by being slow.

If 50% of all mail in the US is spam, then the other 50% must be the bounces for all that undeliverable mail!

I run a mail gateway for a medium sized company, and although not on the scale of a large ISP, I see many of the same problems. Dealing with spam on a gateway level is quite different from dealing with a single personal mailbox. And spam flooding has gotten much worse in the last few months. Getting over a 1000 messages in under a minute can really start to tax your infrastructure. Actually from my own observations, I'd say that at least 75% of all mail is spam, and 80% of that is undeliverable.

Of course one of the big problems as Ramasubramanian points out is that spammers are getting very sophisticated at impersonating other entities. This results in a large number of bounces being directed back to the wrong guy. So not only are you getting spammed, but you are also indirectly spamming the poor guy who is being impersonated with your flood of bounces. And the bounces also cause other problems because it tends to fill up your outbound mail spools, as well as making the required postmaster account near useless sometimes.

One thing I've learned is that a mail administrator must be very careful about constructing blacklists and filters. I use sendmail and make heavy use of it's milter programatic filter interface. It's amazing how being able to analyze the mail at the protocol level (such as the HELO command) helps identify impersonated mail that can't just be done by only looking at mail headers or the message body. It is also possible to help correlate large volumes of nearly identical inbound mail from a large number of different servers, as well as correlate them with large number of undeliverable outbounds. I'm also very careful to check whois an other registrar databases before adding blacklist entries, to help prevent blacklisting the wrong guy. But I do admit that for a few of the most audacious flood attacks, I actually have to resort to iptables firewall blocks to stop it even before sendmail sees it. I really dislike having to disobey the SMTP standards, but spam floods are IMHO just as destructive as worms and viruses!

The thing I fear most as a mail administrator is not the inbound spam, but that some spammer may start impersonating my company! We'd start getting placed on blacklists and blocked, plus we'd start getting flooded with all those bounce messages (probably an order of magnitude more than direct spam). How can one possibly protect against that?

Perhaps you haven't actually looked at sendmail since 1983?

Sendmail certainly does not need to run as root for most of its operations anymore. Read the file "sendmail/SECURITY" in the source code distribution for all the details.

"One way to minimize the possibility of such problems [root exploits] is to install sendmail without set-user-ID root, which avoids local exploits. This configuration, which is the default starting with 8.12, ..."

There are of course a few small things that any mail transport agent will need root access for, primarily for opening port 25., local mail delivery, etc. But the basic quering and mail handling operations don't require root, and neither does sendmail require root for that. Plus sendmail has separated the mail transport function from the local mail delivery/submission function too. And furthermore you can write your own custom sendmail filters (milters) as separate processes from sendmail and can run as any user you like. And if you don't require local delivery, there's no reason you can't chroot jail it either.

It amazes me how often people spout off about their favorite non-sendmail program being ultimately secure and sendmail being ultimately vulnerable to everything. Nothing is that black and white. True sendmail may have a long history, but it has by no means stood still. And furthermore security vunerabilities are possible in every mail program no matter how much it is evangelized as being "secure".

If you don't need the power of sendmail (and most people don't) and it intimidates you then fine use what works for you. That's a legitimate functionaility decision. But just because there is one buffer overflow bug doesn't mean that the whole of sendmail is junk. It got fixed didn't it? There are many things that sendmail does much better than any other alternative out there, especially for very large and complex sites.

Using the spammer's last SMTP protocol leg, before your mail server closes it, why not do the following:

By not letting go of the (would-be spammer's) SMTP connection, one can consult the mail recipient white list. From an unknown sender, instead, save the entire email in a holding queue and send back the following SMTP error message:

550 This is the first time you have contacted john@private-mailbox.net. To ensure that the email you have just sent reaches "john" and that you are not a spam robot, please send another email to the same email address with a Subject of "MD5-12312AFCD7654." Once done, you (i-am-not-a-spammer@goat.cx) will never get this message again from and "john" will finally get your email.

With a marriage of sendmail MILTER and Tagged Message Delivery Agent, one can shift the burden of automating the mail recipient white list back to the sender (like ICQ does).

With a tweak of the last leg of SMTP protocol, we, the email users, will have control over what is 200 and what is 5-f@cking-50.

What say you?

- Shamelessly ripped from the Seinfield TV episode "Soup Nazi."

What do I like best about Vexira?

Unpacks and extracts all MIME encoded messages without needing any other helper apps

Automatic updating

Very fast virus scanning

Reasonable price

We tested and evaluated vexira for about a month and it was clear that this app is a awesome antivirus.