ingress SMTP

Justin Scott 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 
a clue.

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...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3257 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080903/cabb37d5/attachment.bin>


More information about the NANOG mailing list