Whether to filter (for spam, viruses) outgoing mail or not?

Question

The purpose of this questions, is to understand pros and cons of filtering outgoing mail.

I am admin of an ISP. As usual, users, who have dynamic IPs, can send mail only with ISP's SMTP server. Nowadays users can send mail without authorization inside the network, but sending mail to internet requires authorization on the SMTP server. Thereby I can protect my network from been banned for spam.

But I see, that some providers permit sending mail to internet with their SMTP server without authorization. Is it good? Aren't they afraid to appear in DNSBL?

So, what do think about filtering outgoing mail? Use content filter? Deny or permit non-authorized users to send mail? How it is configured in your production?

Answer 1

I'm not sure if I fully understand the question with the part about providers permit sending mail to the Internet without authorization. If you mean internet users using the server to send to other internet users, that's bad. It would be considered an open relay and yes you'd get most likely filtered by other ISP's.

If you mean your internal users sending to the Internet, it's not necessarily bad it's just a policy decision. You can do that by securing the server to only relay mail for your IP ranges.

We aren't an ISP but I have worked with them. While there we only allowed sending from our own IP range, and if you were outside the network you had to authorize to the mail server to send messages and/or use the web interface to use email.

Mail servers were throttled in how much they could send per message so people couldn't email huge attachments.

The mail server was monitored for unusual traffic spikes...no home user should be sending a constant stream of mail.

The router locked out port 25 for any server that wasn't designated as the mail server, so home users couldn't run their own mail servers.

Filtering outgoing mail with something like bayesian filtering can be a pain in that false positives create a bad user experience. Users don't like it when their webbertubes act like magic and that magic won't work for them, especially if it fails seemingly at random. Your tech support won't appreciate the angry calls either. Or you may lose users who just get fed up if they have a bad experience with things "just not working" (unless these are people you want off your network, I don't know).

In general you want to prevent unauthorized access to your server. SMTP authorization can be somewhat annoying for the users to set up, but it usually isn't too bad. Beyond that locking it down to whitelisting your own IPs for relay and limiting message size should be fine. You may or may not want to also add a block on sending executable attachments as well (bat, pif, exe, com...), but that's a policy decision.

Either way you need to make it clear on your website and instructions for home users how and what is allowed for your mail server. You'll still get the phone calls about why something didn't work or what a bounce message means since users usually can't read the message with "attachment too large" written in it, but the slightly more tech savvy will appreciate the ability to look up your policies and errors without dealing with your help line.

Answer 2

I work for a fairly large ISP and we have Spamassasin setup to filter mail on our outbound relays and policies in place to restrict the amount of mail users can send in a certain period of time. The Spamassasin thresholds and policies we use for these relays are no where near as strict as they are on our inbound servers where we can still deliver the mail to the users spam folder, so they only catch only the worst of worst.

We spot check the rejections periodically and, in the few years we've used, it have never found anything other than spam being rejected and received no complaints from users.

These restrictions were put into place in response to three problems we were having which were causing blacklisting and greylisting of our mail servers. The first issue as you mentioned was abuse of webmail services. The second issue was the obvious one of users with infected computers sending spam without their knowledge. These policies have had the side effect of allowing us to contact users and alert them to possible infections.

The third reason involves users having mail forwarded through us to an external mailbox. This is especially an issue with hosted domains where users setup their boxes to forward to a variety of external locations. This forwarded mail would get us blacklisted even though we had no control over the sender and didn't want to limit where customers could forward their mail.

As for the authentication question it would be nice if we could simply request users use authentication, but its a reality that you most likely have users that were setup without it. Depending on the size of our userbase it may be worth the effort but if you're in the same position I am contacting hundreds of thousands of users is probably not feasible.

You mention dynamic IP space for customers, and if its IP space only available to your users where you keep records of who's authenticated to what IP, I'd say that the auth check on email relays are not worth the effort. If instead your users are using shared IP space from a 3rd party provider or you don't have the IP records, the auth check is worth it.

You could work around the shared IP space problem if you tied your access authentication system to your mail relays and only allowed relaying for IPs where customers are actively logged in. To my knowledge there are no pre-build systems that do this though so you'd probably have to roll your own.

Answer 3

1. Require authentication to send. Don't do pop-before-SMTP, or IP registration, or anything else. Just SMTP-auth.
2. Run some trivial spam checks on outgoing mail. If they fire, have a human look at it and see if the user is owned (or bad).
3. Keep some sanity-enforcing limits on how much spam can be sent out at a time per user.
4. Look at trends in how much mail people send. My grandmother, who sends ~10 emails a day, probably isn't going to send 1000 some day. If she does, it's probably ok to have a human look and say "oh, not a spam bot".

Answer 4

I think that the main purpose of filtering outgoing mail would be to limit virus propogation. In other words, to address the situation where a user's computer has been compromised, and is sending mail without the user's consent - particularly when attempting to self-propogate by sending mail with virus-laden attachments.

As others have mentioned - what is spam for one person may be legitimate mail for another. Unless your user-base is extermely homogeneous, I wouldn't filter outgoing mail for spam, but I WOULD filter outgoing mail for viruses.

In a corporate setting, I would also notify an administrator of any virus senders, and use this as a red-flag that that user's workstation needs attention.

Answer 5

What an ISP needs to do and should do is very different I think, from what other entities need to do and should do. Personally I wouldn't allow any unauthenticated email to go through my server. Secondly, authenticating to your server doesn't prevent the user from sending spam and is no guarantee that you won't end up on a block list. I would recommend that you perform some type of filtering on all email that transits your server, both incoming and outgoing.

Answer 6

My view is that an ISP should not be filtering outgoing mail for spam under any circumstances unless specifically requested by a user. What one person or system considers to be spam may well be legitimate mail for others, as anyone managing an anti-spam system will be only too aware. As far as virus scanning goes, I would not like to see any message blocked based on positive detection by anything less than at least three scanners. There are far too many false positives otherwise.

Answer 7

Nah. Just require authentication for outbound mail. Don't filter. At most, set a generous cap on the number of emails per 24 hours, or something like that. If someone's sending more than 10k of messages in that short of a time, well, ask them questions. They may be legit, but odds are they just got a spambot on their PC.

Ask yourself how would you want your ISP to treat you, and act accordingly.