On 9/3/08 10:50 AM, "Suresh Ramasubramanian" <ops.lists@gmail.com> wrote:

On Wed, Sep 3, 2008 at 8:46 PM, *Hobbit* <hobbit@avian.org> wrote:

...

What I'm trying to get a feel for is this: what proportion of edge customers have a genuine NEED to send direct SMTP traffic to TCP 25 at arbitrary destinations? I'm thinking mostly of cable-modem and

Not too many - they got themselves port 587 to submit outbound mail.

Read the maawg managing port 25 document - and while you are at it read the walled garden doc too.. port 25 abuse is the least of your worries with cable/dsl cpe swamps

http://www.maawg.org/port25 http://www.maawg.org/about/whitepapers/MAAWG_Walled_Garden_BP_2007-09.pdf

--srs

We have not setup a port 587 smtp submit server. Our smtp servers run only on port 25. We point our clients outbound email to these servers, which require authentication for relaying. We run into problems with ISPs and hotels which block outbound SMTP. They can't send email. We have to work with them to work with their ISPs to find out what SMTP server they can use for outgoing email. It's a big problem. Yes, setting up a 587 submit server internally would be best, but man power is at a premium and it hasn't happened. So, for us, having ISPs block port 25 is a problem. === Tim Tim Winders | Associate Dean of Information Technology | South Plains College

On 9/3/08 12:48 PM, "Alec Berry" <alec.berry@restontech.com> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Winders, Timothy A wrote:

...

We have not setup a port 587 smtp submit server. Our smtp servers run only on port 25.

Sorry to be harsh, but that's just not the "right way to do things" these days. At the very least, you can run stunnel to allow incoming mail submission on port 465 (SMTP + SSL).

...

So, for us, having ISPs block port 25 is a problem.

Read: "for us, running a mail server is a problem"

Not harsh at all. It's reality. We do have the option for SMTP/SSL/TLS over port 25. It is only required for an authenticated session. I agree, it's not the "right way to do things". Running a mail server used to be much easier. Volunteers to help set things up "the right way" are always welcome. :-) Otherwise, it will happen "eventually". :-( Tim Winders | Associate Dean of Information Technology | South Plains College

On 9/3/08 12:59 PM, "Jason Fesler" <jfesler@gigo.com> wrote:

...

I agree, it's not the "right way to do things". Running a mail server used to be much easier. Volunteers to help set things up "the right way" are always welcome. :-)

Supporting those clients who can't connect is cheaper or more accessible for you?

At this point, yes. We offer SSL/VPN connections back into the network which (so far) has always fixed the problem if the client is unable to work with their ISP to get smtp settings for their email program. It's a matter of resources and priorities. I'd also like to setup an automated provisioning server, but don't know how to do that. There are many projects "in the wings". Registering students and making sure they can pay for classes always seems to bubble to the top, though. ;-) Of course, this is getting a bit off topic for NANOG, so I'll stop there. Tim Winders | Associate Dean of Information Technology | South Plains College

re: intercepting port 25 calls and routing them to the ISP's own SMTP server. Consider an employee of chocolate.com working from home. he connects to Chocolate.com's SMTP server to send mail, but his ISP intercepts the connection and routes the email via its own. The email will then be sent by the ISP's SMTP server. In a context where SPF has been implemented, it means that the email will have been sent by an SMTP server that has not been authorized to send emails from "chocolate.com" and thus rejected by the recipient, and it is not clear how the rejection message would be handled. Also, the ISP might not only intercept the call, but then reject the email because it doesn't have a "from" from the ISP's domain. Secondly, and more importantly. If you are dealing with mass market ISPs who have clear "no servers" policies, then no customer would have legitimate need to run an SMTP server from home. However, there are smaller ISPs who do cater to SOHO /small businesses and those would have legitimate needs to run their own SMTP servers, and if the small ISP ends up using "last mile" from a large ISP, that large ISP would be negatively impacting the smaller ISP's customers. One option is to block port 25, but allow unblocking on an individual basis to those who have fixed IPs or make a good justification to their ISP that they need the port unblocked. In terms of mass-market people using email services from the outside of their ISP (hotmail, yahoo, gmail), then I guess port 587 would be the required way to get it done).

On Wed, 3 Sep 2008, Alec Berry wrote:

At the very least, you can run stunnel to allow incoming mail submission on port 465 (SMTP + SSL).

I would be very very careful with that kind of setup. Connections to port 25 from localhost (even if they are from stunnel running on localhost) often bypass most or all of the MTA's security checks. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ FAIR ISLE: CYCLONIC 4 OR 5, BUT 6 OR 7 IN NORTHWEST. MODERATE OR ROUGH. SHOWERS. MODERATE OR GOOD.

Eugeniu Patrascu wrote:

On Sep 3, 2008, at 8:08 PM, Winders, Timothy A wrote:

...

Yes, setting up a 587 submit server internally would be best, but man power is at a premium and it hasn't happened.

I don't know what SMTP server you're using, but on Postfix you just need to uncomment one line in master.cf, do a reload and that's it. it takes less than a minute to do it on server. YMMV.

Would that it were so easy :) You also have the more daunting task of hooking up your auth/aaa infrastructure with your MTA's, and all of the care and feeding that entails. Mike

On Sep 8, 2008, at 12:31 AM, Michael Thomas wrote:

Eugeniu Patrascu wrote:

...

On Sep 3, 2008, at 8:08 PM, Winders, Timothy A wrote:

...

Yes, setting up a 587 submit server internally would be best, but man power is at a premium and it hasn't happened.

I don't know what SMTP server you're using, but on Postfix you just need to uncomment one line in master.cf, do a reload and that's it. it takes less than a minute to do it on server. YMMV.

Would that it were so easy :) You also have the more daunting task of hooking up your auth/aaa infrastructure with your MTA's, and all of the care and feeding that entails.

IIRC the OP said that he was already doing AUTH on port 25, and this was the basis for my email stating it's quite easy.

Mediacom appears to require SSL to POP3 access: http://www.mchsi.com/help/read/publisher_02/2002-01-28.01 "If you are off the Mediacom Online network you can still access your e-mail using your e-mail client. However, you will need to configure your e-mail program to connect to our secure e-mail server via SSL." Frank -----Original Message----- From: Jay R. Ashworth [mailto:jra@baylink.com] Sent: Wednesday, September 03, 2008 11:07 AM To: nanog@nanog.org Subject: Re: ingress SMTP On Wed, Sep 03, 2008 at 11:52:48AM -0400, Tim Sanderson wrote:

Anybody not wanting to use their ISP email would notice it. I see filtering 25 FROM the customer as something that is not likely to happen because of this. When a customer buys bandwidth, they want to be able to use it for whatever they choose. This would be just one more restriction giving competitive advantage to any ISP not doing the filtering.

Just as long as consumer ISPs don't start filtering *110* inbound from the net... as AT&T used to. I had a client move from dialup to cablemodem about 10 years ago... and it took us a *week* to get AT&T to admit they didn't accept inbound POP pickups. Client (intemperately) had printed the att.com email address of lots of crap -- they had to keep the dialup for a long time, since at&t wouldn't forward either... Thank ghod I'm out of the jungle now... Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)

Why don't you set the alternate ports up as the defaults when the customer signs up?

Excellent question and unfortunately I don't have an answer. I will run that one by management as it is an obviously great idea now that you mention it.

We use TLS on port 587 and SSL on 465, most mail clients default to these ports when you click the "TLS" or "SSL" box. Bonus-- we tell our clients that "we only support encrypted access to their mail". They understand.

We also support SSL access for SMTP and POP, so that could be a possibility as well. I appreciate the feedback on this from everyone. I'm still not 100% convinced that a blanket port block is the answer, but then again I'm not an ISP so my opinion shouldn't be on the top of the list of considerations either. I do have some things to think about for new customers though <g>. -Justin Scott, GravityFree

On Wed, Sep 03, 2008 at 11:56:51AM -0400, Justin Scott wrote:

As a small player who operates a mail server used by many local businesses, this becomes a support issue for admins in our position. We operate an SMTP server of our own that the employees of these various companies use from work and at home. Everything works great until an ISP decides to block 25 outbound. Now our customer cannot reach our server, so they call us to complain that they can receive but not send e-mail. We, being somewhat intelligent, have a support process in place to walk the customer through the SMTP port change from 25 to one of our two alternate ports.

The problem, however, is that the customer simply cannot understand why their e-mail worked one day and doesn't the next. In their eyes the system used to work, and now it doesn't, so that must mean that we broke it and that we don't know what we're doing.

I feel your pain, local compadre, but I'm on their side. Here's your script: "Allowing unfiltered public access to port 25 is one of the things that increases everyone's spam load, and your ISP is trying to be a Good Neighbor in blocking access to anyone's servers but their own; many ISPs are moving towards this safer configuration. We're a good neighbor, as well, and support Mail Submission Protocol on port 587, and here's how you set it up -- and it will work from pretty much anywhere forever." Which is a safe thing to tell people because it is decidedly *not* best practice to block 587. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)

On Wed, Sep 03, 2008 at 09:40:20AM -0700, Michael Thomas wrote:

...

"Allowing unfiltered public access to port 25 is one of the things that increases everyone's spam load, and your ISP is trying to be a Good Neighbor in blocking access to anyone's servers but their own; many ISPs are moving towards this safer configuration. We're a good neighbor, as well, and support Mail Submission Protocol on port 587, and here's how you set it up -- and it will work from pretty much anywhere forever."

I think this all vastly underrates the agility of the bad guys. So lots of ISP's have blocked port 25. Has it made any appreciable difference? Not that I can tell. If you block port 25, they'll just use another port and a relay if necessary.

You're forgetting that 587 *is authenticated, always*. The issue here, though, was that of an Enhanced Mail Provider's clients being unable to get through blocks *set by their client's ISPs*. The EMP has no control over that except to switch said clients to MSP (which they really should have done to begin with, as someone else notes). Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)

On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote:

On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote:

...

You're forgetting that 587 *is authenticated, always*.

I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place.

Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST. Oops. Does anyone bother to run an MSA on 587 and *not* require authentication? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)

On Wed, 3 Sep 2008, Jay R. Ashworth wrote:

Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST.

Note that there are TWO relevant RFCs: RFC 4409 and RFC 5068. The latter says: 3.1. Best Practices for Submission Operation Submission Authentication: MSAs MUST perform authentication on the identity asserted during all mail transactions on the SUBMISSION port, even for a message having a RCPT TO address that would not cause the message to be relayed outside of the local administrative domain. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ FISHER GERMAN BIGHT: SOUTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 IN GERMAN BIGHT, DECREASING 4 AT TIMES. ROUGH OR VERY ROUGH, BECOMING MODERATE LATER. SQUALLY SHOWERS. MODERATE OR GOOD.

Jay R. Ashworth wrote:

On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote:

...

On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote:

...

You're forgetting that 587 *is authenticated, always*. I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place.

Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST.

Oops.

Does anyone bother to run an MSA on 587 and *not* require authentication?

All my normal relay or lack thereof and delivery rules are in place on my 587 port. Of course muas's and mtas will also do tls as well as authentication over port 25 where available. I don't sea any reason to preclude a host that would be allowed to relay via 25 to do so via 587... Congruent policy makes administration simpler.

Cheers, -- jra

Hi, Hobbit - we met back in the late 80s / early 90s at various New Jersey things such as Trenton Computer Fair, but you probably don't remember me; Tigger says hi as well... "Be Liberal in what you accept, be conservative in what you send, and be really really clear in your error messages, except occasionally if you're lying to spammers." IMHO, selling somebody connectivity that blocks various ports isn't selling them Internet Service, it's selling them Walled Garden Couch-Potato Service. For many people that's ok, and if they're sending traffic on Port 25 it's only because some zombieware has taken over their PC, as opposed to because they're actually trying to send it. But the old PC on my desk upstairs has about 2500 times as much CPU and 500 times as much disk space as the Vaxen that I used to run email for a department of 30 people, and the network connection is about 300 times as fast, and there's no particular reason that it shouldn't have full end-to-end Internet presence like anybody's commercial mail server. That's different from 15 years ago when I only had dialup at home, because dialup wasn't really a full-time process, and sending mail was sufficiently unreliable that it made sense to run a dumb client at home that talked to a full-time smart host that knew how to queue messages and retry on failure. Blocking port 25 has become popular, not only with walled-garden connectivity services that are really scared of their customers running their own servers (e.g. most cable modem companies), but also with other ISPs that don't want to deal with the problems of having customers who are spamming (whether deliberate or zombified.) So anybody buying something lower-priced than a T1 typically needs to have a mail client or mail transfer agent that can use other ports, unless they want to trust their ISP's mail service or use webmail. And also obviously if you're running an outbound mail relay smarthost for your clients you need to accept mail from known people on the various authenticated ports in case they're stuck behind a randomly misbehaving ISP, and you should also support encrypted SMTP in general. In some sense, anything positive you an accomplish by blocking Port 25 you can also accomplish by leaving the port open and advertising the IP address on one of the dynamic / home broadband / etc. block lists, which leaves recipients free to whitelist or blacklist your users. And you can certainly provide better service to your customers by redirecting Port 25 connections to an SMTP server that returns "550 We block Port 25 - see www.example.net/faq/port25blocking" or some similarly useful message as opposed to just dropping the packets. I've toned down my vehemence about the blocking issue a bit - there's enough zombieware out there that I don't object strongly to an ISP that has it blocked by default but makes it easy for humans to enable. -- ---- Thanks; Bill Stewart Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.

Hi Bill, Bill Stewart wrote:

In some sense, anything positive you an accomplish by blocking Port 25 you can also accomplish by leaving the port open and advertising the IP address on one of the dynamic / home broadband / etc. block lists, which leaves recipients free to whitelist or blacklist your users.

Except that this tends to lead to a worse situation for people like yourself who wish to run a mailserver - because ultimately you'll have to resort to using an ISP's forwarder anyway because there will be more spam from the IP ranges you're in leaving to the wide world, thus a worse reputation, and so more blocking. ie. by blocking outbound SMTP by default and getting customers to use our mail cluster their email is more likely to arrive and not be dropped as coming from a potential spam source.

I've toned down my vehemence about the blocking issue a bit - there's enough zombieware out there that I don't object strongly to an ISP that has it blocked by default but makes it easy for humans to enable.

That's what we do - by default most customers have a small ACL applied which protects them from traffic from various windows ports, ensures SMTP goes via our mail cluster etc. Having customers send mail out via us is actually better because we do spam checking and can alert customers to their machines being compromised etc (or at least customers can look at their status themselves). But, customers can easily turn the filtering off via the portal we have. We have no issues with customers running servers - most people don't, and those who do value the ability to do so. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909

Frank Bulk wrote:

How do you alert mail server operators who are smarthosting their e-mail through you that their outbound messages contain spam?

Typically a ticket gets injected into helpdesk who then contact them via email or via a phone call depending on the situation. I don't think we've automated it as often these kinds of people don't react well or ignore it - so a human being needs to intervene and often give help. We also take measures such as rate limiting the amount of email they can send (kbps, msg per hour wise) to limit the damage. We offer a URL for customers that allows them to see their "spam" rating for their IPs (this includes if they're sending out viruses as well) - including a text only version (2 lines of text) so it can be easily parsed by machine if someone wanted to integrate it into their own checking. We try and have default settings that protect us and the users as much as possible, but allow people who (at least think they) know what they're doing to change them to be more open. Our general customer base tends to be biased towards the techy type who want this kind of thing. (We sponsor things like the Australian Systems Administrator's Guild etc) MMC

Frank

-----Original Message----- From: Matthew Moyle-Croft [mailto:mmc@internode.com.au] Sent: Saturday, September 13, 2008 12:41 AM To: Bill Stewart Cc: nanog@nanog.org Subject: Re: ingress SMTP

Hi Bill,

Bill Stewart wrote:

...

In some sense, anything positive you an accomplish by blocking Port 25 you can also accomplish by leaving the port open and advertising the IP address on one of the dynamic / home broadband / etc. block lists, which leaves recipients free to whitelist or blacklist your users.

Except that this tends to lead to a worse situation for people like yourself who wish to run a mailserver - because ultimately you'll have to resort to using an ISP's forwarder anyway because there will be more spam from the IP ranges you're in leaving to the wide world, thus a worse reputation, and so more blocking.

ie. by blocking outbound SMTP by default and getting customers to use our mail cluster their email is more likely to arrive and not be dropped as coming from a potential spam source.

...

I've toned down my vehemence about the blocking issue a bit - there's enough zombieware out there that I don't object strongly to an ISP that has it blocked by default but makes it easy for humans to enable.

That's what we do - by default most customers have a small ACL applied which protects them from traffic from various windows ports, ensures SMTP goes via our mail cluster etc. Having customers send mail out via us is actually better because we do spam checking and can alert customers to their machines being compromised etc (or at least customers can look at their status themselves). But, customers can easily turn the filtering off via the portal we have.

We have no issues with customers running servers - most people don't, and those who do value the ability to do so.

MMC

-- Matthew Moyle-Croft - Internode/Agile - Networks

Apologies for not being more clear, because I see the responses going in tangents I hadn't expected. Most anti-spam products drop the connection or issue some kind of rejection message during the SMTP exchange. If the connection is dropped, the subscriber's MTA/MUA will likely try and try again until it reaches expiration time. For MS Exchange I think that's two or three days. For Outlook Express, that message just sits in the Outbox. If a rejection message was issued, hopefully the sender can interpret what the MUA is saying, or the MTA sends back an undeliverable. So, for service providers who require their subscribers to smarthost messages through their server, how are they letting the subscribers know in some kind of active way? Frank -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists@gmail.com] Sent: Saturday, September 13, 2008 8:39 PM To: Frank Bulk Cc: Matthew Moyle-Croft; nanog@nanog.org Subject: Re: ingress SMTP On Sat, Sep 13, 2008 at 11:38 PM, Frank Bulk <frnkblk@iname.com> wrote:

How do you alert mail server operators who are smarthosting their e-mail through you that their outbound messages contain spam?

Frank

If those are actual mailservers smarthosting and getting MX from you then you doubtless have quite a lot of reporting already set up. Have you seen what Messagelabs, MXLogic etc do? There's also feedback loops, ARF formatted, where users on those mailservers can report inbound spam to the filtering vendor. .. or was that a rhetorical question and am I missing something here? -- Suresh Ramasubramanian (ops.lists@gmail.com)

Alec Berry wrote:

Michael Thomas wrote:

...

But the thing that's really pernicious about this sort of policy is that it's a back door policy for ISP's to clamp down on all outgoing ports in the name of "security".

I don't think ISPs have anything to gain by randomly blocking ports. They may block a port that is often used for malicious behavior (135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their support calls-- but they would have to balance that with the risk of loosing customers. It's not as much a slippery slope as much as it is a tightrope act (yes-- I am metaphorically challenged).

I see nothing wrong with filtering commonly abused ports, provided that the ISP allows a user to opt out if they know enough to ask. When port 25 block was first instituted, several providers actually redirected connections to their own servers (with spam filters and/or rate limits) rather than blocking the port entirely. This seems like a good compromise for port 25 in particular, provided you have the tools available to implement and support it properly. I also agree with the comments about switching customers to 587. My former monopoly ISP only accepted mail on 25 and I had endless problems trying to send mail from airports, hotels, coffee shops, etc. while traveling. The same hotspots also tended to block port 22, so I couldn't even forward mail via my own server. However, my new monopoly ISP only accepts mail on 587, and I have yet to have a single problem with that from any hotspot I've used since the switch. Ditto for reading my mail via IMAPS/993, whereas I used to have occasional problems reading it via IMAP/143. S

On Wed, Sep 3, 2008 at 9:26 PM, Justin Scott <jscott@gravityfree.com> wrote:

...

What is preventing this from being an operational no-brainer, including making a few exceptions for customers that prove they know how to lock down their own mail infrastructure?

As a small player who operates a mail server used by many local businesses, this becomes a support issue for admins in our position. We operate an SMTP

Do you operate your mailserver on a residential cablemodem or adsl rather than a business account? There's this little matter of a "no servers on home connections" type AUP that most providers have .. --srs

On Wed, Sep 3, 2008 at 10:18 PM, Justin Scott <jscott@gravityfree.com> wrote:

...

Do you operate your mailserver on a residential cablemodem or adsl rather than a business account?

No, we co-lo equipment at a professional facility that our customers on any type of connection need to have access to send mail through, regardless of whether their ISP blocks the standard ports or not.

That's why you set your outbound MTA to listen - for auth'd outbound connections only - on port 587 Endless loop of dead horse beating .. ouch srs -- Suresh Ramasubramanian (ops.lists@gmail.com)

I would like to point my customers to port 587, but that kind of configuration is still in its infancy. We ask our employees of our business customers to VPN into work and for everyone else to use our webmail. Frank -----Original Message----- From: Justin Scott [mailto:jscott@gravityfree.com] Sent: Wednesday, September 03, 2008 10:57 AM To: nanog@nanog.org Subject: Re: ingress SMTP

What is preventing this from being an operational no-brainer, including making a few exceptions for customers that prove they know how to lock down their own mail infrastructure?

As a small player who operates a mail server used by many local businesses, this becomes a support issue for admins in our position. We operate an SMTP server of our own that the employees of these various companies use from work and at home. Everything works great until an ISP decides to block 25 outbound. Now our customer cannot reach our server, so they call us to complain that they can receive but not send e-mail. We, being somewhat intelligent, have a support process in place to walk the customer through the SMTP port change from 25 to one of our two alternate ports. The problem, however, is that the customer simply cannot understand why their e-mail worked one day and doesn't the next. In their eyes the system used to work, and now it doesn't, so that must mean that we broke it and that we don't know what we're doing. Your comment about "exceptions for customers that prove they know how to lock down" is not based in reality, frankly. Have you ever tried to have Joe Sixpack call BigISP support to ask for an exception to a port block on his consumer-class connection with a dynamic IP? That's a wall that I would not be willing to ask my customers to climb over. Now, having said all that, I do agree that big ISPs should do more to prevent spam from originating at their networks. A basic block of 25 isn't the solution, in my opinion. Unfortunately I don't know what is. Perhaps monitoring the number of outgoing connections on 25 and temporarily cutting off access if a threshold is reached? Set it high enough and the legitimate users won't notice, but low enough that it disrupts the spammers. Perhaps I'm talking out of my ass and don't have a clue. In any case, I don't believe a blanket block of 25 is the answer. -Justin Scott, GravityFree

JS> Date: Wed, 03 Sep 2008 11:56:51 -0400 JS> From: Justin Scott JS> Have you ever tried to have Joe Sixpack call BigISP support to ask JS> for an exception to a port block on his consumer-class connection JS> with a dynamic IP? In my experience, most people capable of preventing outbound 25/TCP abuse also are capable of requesting "please allow me unfiltered 25/TCP access to the entire world". Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

Charles Wyble wrote:

I have SBC / AT&T / Yahoo DSL in Southern California and they block outbound 25 to anything but Yahoo SMTP server farm, and they only allow SSL connectivity at that. I'm all for that personally.

That seems to be the convention wisdom, but the science experiment as it were in blocking port 25 doesn't seem to be correlated (must less causated) with any drop in the spam rate. Because so far as I've heard there isn't any such drop. Spammers and the rest are pretty resourceful. So I still haven't heard why there isn't any emphasis on going after the bots that are by far the biggest problem instead of erecting damage for them to route around. I can sort of understand why providers are leery of getting sucked into that battle, but it's got to cost them a fortune for every "My internet is slow" call they take. Mike

On Wed, Sep 3, 2008 at 5:12 AM, Michael Thomas <mike@mtcc.com> wrote:

That seems to be the convention wisdom, but the science experiment as it were in blocking port 25 doesn't seem to be correlated (must less causated) with any drop in the spam rate. Because so far as I've heard there isn't any such drop. Spammers and the rest are pretty resourceful.

Let's put it this way .. a lot of ISPs have already realized that which is why port 25 blocking or management is the basics. They do that and have done that for years (and various providers elsewhere still proudly claim "hey, we do outbound port 25 blocking, we're great!!!"). The real action is in walled gardens to automatically detect and isolate botted hosts till they're cleaned up Go talk to arbor, sandvine, perftech etc etc srs