Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

7 Answers 7

up vote 1 down vote accepted

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.

share|improve this answer
    
What do you think of limiting mail sending rate? –  TiFFolk Nov 5 '09 at 13:07
    
What do I think of it? As long as it's reasonable it's not a problem. The goal is to accommodate the end user as much as possible when working as an ISP. User experience is everything to keep the customer happy, and the more limits you put on users the more unhappy they'll be, unlike corporations where IT departments to some degree can dictate "No, you can't do that." Users probably won't have a problem with not being able to send more than 10 emails a minute or something like that; you'd have to monitor how your users are utilizing your network to create policies that work for your situation. –  Bart Silverstrim Nov 5 '09 at 13:20

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.

share|improve this answer
    
Thanks for the great experience exchange! How do you monitor your SMTP-relays whether they are blacklisted? Do you have some automated reaction after your servers are blacklisted? –  TiFFolk Nov 7 '09 at 21:09

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.

share|improve this answer
    
I think this is a reasonable idea. I will scan outgoing mail for viruses. –  TiFFolk Nov 5 '09 at 18:26
1  
Most viruses sending email don't do it through the mail server. They use their own SMTP engine. That's why it's curbed 99% of the time by telling your router not to allow outgoing port 25 traffic. If your mail server is busy your antivirus will also impose some added overhead, so be careful and monitor your server performance with config changes. There are some that will try hijacking your outgoing mail server, but again, not as often, and monitoring via limiting and throttling, getting reports for usual activity, etc. will catch most of this. –  Bart Silverstrim Nov 6 '09 at 14:01
    
We've also had web pages that were compromised, and used to send spam from our webservers. Since our webservers are "trusted", the mail filter didn't scan the mail they sent as thorougly. Something else to consider. –  Brent Nov 6 '09 at 16:48
    
@Brent, Have you noticed sharp increase in amount of mail sent by your web-servers? I think this can be a reason to check any of your trusted servers. –  TiFFolk Nov 7 '09 at 21:14
  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".
share|improve this answer
    
1. But if your competitor ISP provides SMTP without authorisation? 2. Cant you give some examples of such trivial checks? 3&4. I have 5 000+ users, track them aLL? –  TiFFolk Nov 5 '09 at 18:23
    
1. Do you really think people are going to move away from your service if you ask them to configure Outlook Express in way X, instead of way Y? 2. Run Spam Assassin with the expensive checks turned off. 3&4. Yes. Don't do it by hand, use software. –  Bill Weiss Nov 5 '09 at 19:43

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.

share|improve this answer

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.

share|improve this answer
    
But probably, if virus somehow gets SMTP server IP, it will start to spam, but mail won't go out of my network. That saved me once already. –  TiFFolk Nov 5 '09 at 18:08

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.

share|improve this answer
    
I already spelled out my experiences, but another part I didn't mention is that at some point as an ISP (unless your name is something like Google or Yahoo) you're going to end up on a blocklist for something at some point. It's part of being an ISP administrator, I've concluded. The practice that worked best for us (and our users' experience) was to monitor the server for unusual activity and be proactive in monitoring for exploits and the main lists of blocked ISP's to fix issues and clear our provider from those lists ASAP. And it can be a REAL PAIN. –  Bart Silverstrim Nov 5 '09 at 12:50
    
I agree. A balance needs to be struck between security and usability. You're never going to make everyone happy, so I say err on the side of caution. –  joeqwerty Nov 5 '09 at 13:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.