jscott at gravityfree.com
Wed Sep 3 10:56:51 CDT 2008
> 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
In any case, I don't believe a blanket block of 25 is the answer.
-Justin Scott, GravityFree
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3257 bytes
Desc: S/MIME Cryptographic Signature
More information about the NANOG