 |
 |
John, Many service providers do basically what you're suggesting. They filter outgoing port 25 connections from their IP space, and only allow port 25 outgoing to their mail servers. If there is a problem with a user system being infected or abused, it could in most cases be tracked down by the mail system admins. This not only helps restrict the flow of viruses, but also helps to stop zombie machines with a trojan/proxy infection from being used to send out large amounts of spam. The problem that most people bring up with this practice is that it restricts the users ability to choose their outgoing SMTP server. If they have more than one service provider that acts this way, it can cause them all kinds of problems when moving back and forth between the two because they have to create new profiles, or switch their outgoing SMTP server based on where they're connected to. This will likely become more of an issue as domains start to implement new "caller-id" features being proposed by Microsoft and others to help curb spam: http://www.microsoft.com/mscorp/twc/privacy/spam_callerid.mspx This will break the ability for users of such service providers to send mail out from their chosen addresses through whatever ISP they're connected to. For example, if an MSU user is connected through Earthlink, and they want to send mail out from their MSU address, they would be unable to do so because the resulting caller-id feature would consider this email to be invalid because it was being delivered by Earthlink's mail servers instead of MSU's. Of course there will always be alternate port configurations to get around this, but it will likely still be an issue. While this port 25 blocking proactive approach to limiting viruses and spam is a good idea in my book, it would have to be weighed against the resulting support calls, and other problems it might produce. Well, those are my thoughts, feedback is welcome. -Russell John Resotko wrote: > Good morning, > > I'm gonna put my neck out and ask a really stupid question. Due to the > recent plague of password protected .ZIP files in bogus email messages, > and the fact that the vast majority of virus scanning systems can't open > them, I've been wracking my brain trying to figure out how to limit the > damage from these messages. > > My question goes more toward the folks at the Computer Laboratory, and > probably requires more expertise than I have. My thought was this: in > many cases, the PCs and laptops getting infrected and broadcasting > emails are individual machines, not legitimate mail servers. Many of > the infected machines may be reaching campus via the dialup and external > entry points onto campus. Most of those lie within the 35.12.xx.yy > range of addresses. > > My question is this: can specific ranges within 35.12.xx be identified > as STRICTLY dialup users, and could those user addresses have common > SMTP server ports blocked? If no individual PC connecting though dialup > should be allowed to act like an email server, yet infected PCs usually > do when trying to sent out emails, would that create enough of a profile > to allow some ranges to block SMTP ports to prevent some of the spread > of these infections onto the campus network? I know that this is > difficult, considering that a legitimate client may have the need to > connect to specific SMTP ports to deliver valid email. Also, and IPS > would be better suited to at least detect PCs trying to engage in > massive amounts of SMTP connections as possiblly infected machines. I'm > just trying to brainstorm a way to try to reduce the amount of infected > traffic we all have to contend with. > > Now that I've thrown this out there, I'd love to hear comments, > suggestions, criticisms, and most importantly, alternatives that may > help us all with this problem. Thanks to the Computer Lab folks for > keeping on top of these issues when they crop up. > > > > John A. Resotko > Head of Systems Administration > MSU - Detroit College of Law > 208 Law College Building > East Lansing, MI 48824-1300 > email: [log in to unmask] > Phone: 517-432-6836 > Fax: 517-432-6861