RE: ISP outbound SMTP filtering

: I agree here to a point -- but I think (and maybe you do 
: this) the better policy would be to block 25 by default, 
: and then if particular customers have a preference 
: (whatever their reasons) to deliver directly from the mail
: server they can apply for an exemption.


If your network's already up and running I would suggest against putting a block in place and waiting for customers to call. The first thing you can do is set up a filter to log all port 25 traffic and find out who in your statically assigned IPs are using mail servers.  Then you can block the other addresses that haven't sent any legitimate mail for various values of 'legitimate'.  ;-)  Then when blocked customers decide to start using a mail server they can follow your procedure (that you previously sent to all customers) and you don't disrupt your more savvy customer's traffic.

I have found only one legitimate use of a mail server on a DHCP assigned address, so far, and I suspect there're very, very few folks doing that.  So, block outbound 25 on DHCP ranges.

scott




--- [email protected] wrote:

From: <[email protected]>
To: <[email protected]>
Subject: RE: ISP outbound SMTP filtering
Date: Tue, 5 Jun 2007 17:44:15 -0400

Kevin Kargel wrote:
> I agree port 25 blocking isn't going to hurt anyone.  On the contrary
> it is necessary.  I block port 25 outgoing on my dynamic networks.
> 
> What does hurt people, and networks, and the image the public has of
> us all is when autocratic administrators impose unduly strict
> restrictions on customers without reasonable cause.

I must be losing track of this thread.  :-)  I could have sworn that just a
few re:'s ago you were accusing someone of being an autocratic administrator
imposing undully strict restrictions on customers without reasonable cause
for blocking outbound port 25.  Unless you're just making a distinction here
about blocking it only on dynamic ranges, which is a valid point.
 
> In actuality many of my customers do relay through my mail server.
> Others prefer to deliver directly from their own mail server.  This
> is a choice they should be able to make so long as they are well
> behaved. 

I agree here to a point -- but I think (and maybe you do this) the better
policy would be to block 25 by default, and then if particular customers
have a preference (whatever their reasons) to deliver directly from the mail
server they can apply for an exemption.  It's a small hurdle for them, yes,
but not unreasonable IMHO.  Maybe make them agree to some special terms and
conditions that allows you to take swift action in the event of abuse.  That
also allows you to compile a handy-dandy list of mail operators on your
network that maybe could use some special attention.

 
> Another thing I do that I thought would be more popular, but so far
> has not taken off, is to offer free validation of personal email
> certificates for authentication and encryption.  It appears that what
> people really want is out-of-box functionality, and that is going to
> be what satisfies them.

People don't understand it and there isn't widespread enough adoption to
make them care enough to learn about it.  I'm not holding my breath.

 
> As soon as
> port 587 becomes widely used the zombies and viruses will raid the
> local email configs for credentials and start using that service. 
> Running and hiding from zombies will work for a time, but it will be
> a temporary fix. 

587 is only part of the solution.  Authenticated access on port 587 is the
key.  I'm sure the day will come when zombies figure out how to read TLS
settings out of MUA's, at which point we'll have to look to other solutions.
Fighting spam is clearly an arms race with no end in sight, but that doesn't
mean we should just throw our hands up in the air and give up.
 

> If you consider port 58x delivery to be a standard practice, I would
> suggest looking in the pull-down configuration of the most common
> email clients and see how many list that port as a built-in
> alternative to port 25.

Precious few if any.  But that just means the software hasn't yet caught up
with reality.  Mail software didn't used to support SMTP authentication
methods either.  Now they support several.  Does it make it painful for your
support staff in the interim?  Yes.  But then so did doing away with SLIP
for PPP or X2/Kflex for V.90.  I'm pretty sure your support techs will be
pounding their heads against their desk over something as long as there are
support techs. :-)  Just be thankful that we've finally standardized on a
mail input port and are moving away from the hodge-podge where every
provider pulled a port out of thin air.

 
> More and more people have work
> email addresses where their corporate policies require them to use the
> non-local corporate mail servers.  At the same time these people work
> with internet connections on non-corporate IP blocks.  The corporate
> solution (which is a good measure) is to require SMTP Auth and/or Pop
> before SMTP Auth.

Again, I'm confused what you're arguing here.  You've already said that
you're blocking outbound 25, and that it is a good thing, yet now you're
again complaining about things it breaks.  But then you provide the easy
solution to what it breaks.  We're in a bit of a transition period right
now, which means sometimes things won't work the way you or your clients
might like them to.  But solutions are at hand, and there are workarounds in
the meantime.  I don't think anyone has said there aren't drawbacks to
blocking port 25.  There certainly are, and you've listed several.  That
doesn't change the fact that it's becoming de-facto standard best-practice
and the benefits seemingly greatly outweigh the problems.  It's a long and
messy process making even the smallest of changes in how things work on the
Internet, but hopefully the end result makes all the interim pain
worthwhile.


Andrew

_______________________________________________
"Eat sushi frequently". - Avi
[email protected] is the human contact address.
[email protected] is the list posting address.
See below URL for subscribe/unsubscribe and list options:
http://inet-access.net/mailman/listinfo/list


_______________________________________________
"Eat sushi frequently". - Avi
[email protected] is the human contact address.
[email protected] is the list posting address.
See below URL for subscribe/unsubscribe and list options:
http://inet-access.net/mailman/listinfo/list