ingress SMTP

Mailman List Mirror (Read Only)
1

I've been blackholing NANOG mail for a while due to other things
displacing the time I'd need to read it, so I might be a little out
of touch on this, but I did grovel through some of the archives
looking for any discussion on this before posting. Didn't find a
really coherent answer yet.

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
DSL/fiber swamps, dialup pools [do they even exist anymore?], and
other clouds basically containing end-users rather than the more
"bidirectional" business-class customers.

The big providers -- comcast, verizon, RR, charter, bellsouth, etc --
seem to be some of the most significant sources of spam and malware
attempts, mostly from compromised end-user machines, and it seems
that simply denying *INGRESS* of TCP 25 traffic except to the given
ISP's outbound relay servers would cut an awful lot of it off at the
pass. Decent anti-header-spoofing configuration on said mailservers
would take care of even more. I realize this might be a total
hot-button but I'm not talking about filtering TOWARD customers, I'm
talking about filtering FROM them, upstream -- possibly less often
discussed. And only SMTP. Not censorship, just a simple technical
policy that the vast majority of customers wouldn't even notice.

I've got a paper out about this that was put together quite a
while ago, in fact:

  http://www.usenix.org/publications/login/2005-10/openpdfs/hobbit.pdf

I can weigh the decision to trust a PTR lookup, but most of the big
players seem to have their inverse DNS automated fairly well which
helps such little hacks work. But really, I'd like to see more done
at the SOURCE of the problem, which should be as simple as two ACL
lines dropped into some edge routers.

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?

And why do the largest players seem to have the least clue about it?

_H*

2

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

3

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.

4

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

5

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

6

Justin Scott wrote:

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.

Why don't you set the alternate ports up as the defaults when the
customer signs up? There are so many ISPs, WAPs, cell carriers, etc that
are blocking egress port 25 (ie outgoing from their network) already.
The prudent thing to do, for you and your customers, would be to assume
every customer will, at some point, have access to port 25 blocked.

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.

In any case, I don't believe a blanket block of 25 is the answer.

If the question is "how can we stop consumer bot armies from sending
spam" it is a pretty good, albeit incomplete, answer.

...
alec

- --
`____________
/ Alec Berry \______________________________

Senior Partner and Director of Technology \
PGP/GPG key 0xE8E9030F |
http://alec.restontech.com/#PGP |
-------------------------------------------|
            RestonTech, Ltd. |
       http://www.restontech.com/ |
         Phone: (703) 234-2914 |

\___________________________________________/

7

You don't. They should have been setup on port 587 to start with.

8

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

9

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

10

Jay R. Ashworth 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."

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.

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". And it's almost plausible, except for the annoying
problem that the net becomes secure and useless in one swell foop.

That said, I heard a pretty amazing claim made by somebody while
I was still at the big ol networking company that ISP's in general
not only didn't know which of their customers computers were
owned, but that they didn't want to know. Even putting aside the
claim of blissful ignorance, port 25 blocking is nothing more than
a Maginot Line for the larger problems of infected computers. If
we really wanted to curb spam, why don't we just put them in the
penalty box until they are remediated? Heck, that even stops lots
of other attacks that have nothing to do with port 25 too.

       Mike

11

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

12

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.

-Justin Scott, GravityFree

13

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

14

Michael Thomas wrote:

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.

I'm pretty sure it has, although without aggregate stats from various
ISPs it is hard to tell. Since mail transport is exclusively on port 25
(as opposed to mail submission), a bot cannot just hop to another port.

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).

...
alec

- --
`____________
/ Alec Berry \______________________________

Senior Partner and Director of Technology \
PGP/GPG key 0xE8E9030F |
http://alec.restontech.com/#PGP |
-------------------------------------------|
            RestonTech, Ltd. |
       http://www.restontech.com/ |
         Phone: (703) 234-2914 |

\___________________________________________/

15

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.

16

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

17

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

18

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

19

It generated some very confused support calls here, where folks said I sent
email to your server, and we had to tell them "no you didn't, you only
thought you did".

Please if you are going to block it block it clearly and transparently.

On the other hand abuse by bots isn't restricted to SMTP, and I suspect ISPs
would be better of long term having a way of spotting compromised/malicious
hosts and dealing with them, than applying a sticky plaster to port 25.
Indeed spewing on port 25 is probably a good sign you need to apply said
system.

20

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"

...
alec

- --
`____________
/ Alec Berry \______________________________

Senior Partner and Director of Technology \
PGP/GPG key 0xE8E9030F |
http://alec.restontech.com/#PGP |
-------------------------------------------|
            RestonTech, Ltd. |
       http://www.restontech.com/ |
         Phone: (703) 234-2914 |

\___________________________________________/