Lazy network operators

Mailman List Mirror (Read Only)
1

Vixie writes:

since we're talking about laziness, let's look at two ways in which we (nanog
"members" and others like us around the world) have been lazy, for decades,
and have therefore helped to create the current miserable "abuse" situation.

Paul, let me add one more to your list: As a community, we have
been too lazy to take hold of the architectural source of the
problem, which is the complete lack of accountability over the
ability to post email.

This is not a technical issue (although I can hear echos from
the long past x.400 community already), it's simply a service
definition issue. As a community, we've designed an end-to-end
mail protocol(SMTP) and opened it up to everyone. The reality
is that the vast majority of end-user customers connected to the
Internet have one or two email servers, and there is no reason
to allow client connections to port 25 for posting. If ISP's
simply filtered port 25 by default except from specified servers,
there wouldn't be a huge base of client systems to tap into for
robo-farms for spamming.

Of course, this breaks the end-to-end model of the Internet...
Too bad. End-to-end makes sense in some contexts, and it doesn't
in others. This is the latter case.

In reality, lots of folks have plenty of good reasons to want
open access to port 25 from their entire prefix. That's also
fine, *as long as you accept responsibility for what is sent*.
Want both wide open access and complete deniability? That's
the option we presently have, and frankly, it doesn't scale.

/John

2

Hi John,
I dont think this is a fair assessment of the SMTP 'abuse' problem.. its a lot
more complicated, blocking port 25 will not reduce the volume of spam at all.

Most of the spam I'm seeing comes directly from end user hosts that have either
an open proxy on them or some kind of malware with its own SMTP engine designed
to send out junk.. in this model the only port 25 traffic is that from the end
host coming outwards, I believe you're suggestion is to filter port 25 towards
hosts.

Even blocking the outbound 25 traffic (eg pushing it via the ISP SMTP relay)
will not stop the emails. It is possible to extend this and implement some sort
of statistical sanity checking on the mail being relayed (eg alarm/deny mail
once it exceeds X/minute/host) which is potentially a workable solution.. I'd be
interested if theres any patches to the major MTAs to do something with this (we
use exim) as it could be an interesting test.

Of course this model throws up new problems you need to address such as roaming
users not being able to smtp via their 'home' ISP via auth'd SMTP, making sure
you dont filter ISP-ISP port 25 traffic etc

Steve

3

Steve,

   I'm very much suggesting blocking outward to the Internet port 25
   traffic, except from configured mail relays for that end-user site.
   Those hosts which have MSTP malware are stopped cold as a result.

/John

4

NNTP is set up almost everywhere with configured server to server
connections, and essentially all "open" NNTP user access has been
closed down over the years.

How is the spam problem on USENET these days?

5

NNTP is set up almost everywhere with configured server to

> server connections, and essentially all "open" NNTP user access
> has been closed down over the years.

> How is the spam problem on USENET these days?

It's not nearly as bad as it was at its peak, but it's still very much
present.

6

I've been on Usenet again for a while last year and there was surprisingly little spam compared to some years back. Apparently some people have taken it upon themselves to remove all the spam that pops up. NTTP is at an advantage over SMTP here because "personalizing" messages for each recipient isn't possible here.

Talking about lazy: blocking port 25 is very lazy, in several ways: intelectually, morally and just plain way. It's intellectually lazy because there are other ways to arrive at the same result that don't arbitrarily block communications between two consenting hosts. Morally it's lazy to assume that just because you don't need something, others won't either. And of course having all those access networks install filters rather than work on the problem yourself is just plain lazy.

If we all agree that we don't want to talk SMTP to broadband consumers, it shouldn't be too hard to come up with a registry that lists IP addresses used by broadband consumers. Or maybe it's easier to work the other way around and list the servers we actually may want to talk to. This approach has two main advantages over filtering port 25:

1. People can still talk to unlisted SMTP hosts if they feel they have a good reason to do so (ie, I get to deliver messages directly to my server from home rather than being forced to use my service provider's which may or may not work)
2. Checking is done per SMTP session rather than per IP packet

The good news is that the IETF is now starting work on this, so expect results in two or three years.

7

This approach has two main advantages over filtering port 25:

1. People can still talk to unlisted SMTP hosts if they feel they have a good reason to do so (ie, I get >to deliver messages directly to my server from home rather than being forced to use my service >provider's which may or may not work)

You're right... Rather than simply having you tell your provider that you're
responsible and having port 25 outward opened up, the freedom for anyone
to send to port 25 on an ad-hoc basis like we have today is a better idea.
Today's spam isn't a problem; everything's working as designed.

The good news is that the IETF is now starting work on this, so expect results in two or three years.

Great idea: here's a case where we need less connectivity and better
operational practices, but rather than take that task on, we should do
more protocol work.

The reality is that the vast majority of email is handed off to a designated
mail relay (whether we're talking about consumer connections or office
environments), and if we actually configured connectivity in this matter,
there wouldn't be a problem.

/John

8

The reality is that the vast majority of email is handed off to
a designated mail relay (whether we're talking about consumer
connections or office environments), and if we actually
configured connectivity in this matter, there wouldn't be a
problem.

our innate fear of this stems from suspicion of centralization and
the telco switch model. this fear is not clearly unjustified.

maybe we can get reasonable security without a police state?

randy

9

When evaluating spam solutions, the first thing I ask is, "Does this
empower users?" If the answer is no, it's probably the wrong solution.

10

That's definitely the right idea to start with... The question is, do you
change approach after a decade without progress?

/John

11

so the malware writers start using port 80 through open proxies...they
do already. or they go after the im client ports more. there are ways
to send mail if 25 is blocked to me

/joshua

12

Yep, there's no doubt we'd have to deal with the next round of creative
approaches. I'd still wager we'd see a major decrease in spam as a
result of some simple configuration.

/John

13

> The reality is that the vast majority of email is handed off to
> a designated mail relay (whether we're talking about consumer
> connections or office environments), and if we actually
> configured connectivity in this matter, there wouldn't be a
> problem.

our innate fear of this stems from suspicion of centralization and
the telco switch model. this fear is not clearly unjustified.

There are also plenty of legitimate reasons to permit
earthlink/juno/mindspring dialup users to hit mail relays on their own
domains. For instance, when on travel how does John Curran access his
istaff.org email? (presuming no 'ssh to my shell server and use
pine/elm/mh/mailx)

maybe we can get reasonable security without a police state?

What will the jack-booted-thugs do then? :slight_smile:

14

maybe we can get reasonable security without a police state?

What will the jack-booted-thugs do then? :slight_smile:

tell us how to close down other parts of the net so they can
control and profit from them

15

chris@eff.org (Chris Palmer) writes:

When evaluating spam solutions, the first thing I ask is, "Does this
empower users?" If the answer is no, it's probably the wrong solution.

right now the spammers are holding the users hostage: "if you want to be
able to read mail from people/hosts you've not been formally introduced
to, then you have to swallow our swill also."

that's somewhat the opposite of empowerment. if a "spam solution" can
take away that crisis and the expense is that my dsl-connected end host
has to tunnel its e-mail to someplace out in <www.vix.com/personalcolo>
then that's a tradeoff i can live with.

16

jcurran@istaff.org (John Curran) writes:

The question is, do you change approach after a decade without progress?

Based on my archives of this and related mailing lists... "nope."

17

Ah-ha! too bad that mean old IAB says we can't filter traffic :slight_smile: (or
advises against it, or thinks it's a bad idea...)

In all seriousness, the consumer dial/broadband folks had to take actions
like port/25 filtering (inbound and outbound actually) to address spam
issues with these systems. This is unfortunate for those folks out there
that 'need' smtp access to something other than the blessed email servers
of their dial/broadband provider(s).

Making a more sensible solution for email than the current SMTP, or
finding a middle ground that works for dial/broadband users would sure be
nice. Any 'port 25' filtering is really just a short term solution until
all spambots use locally configured SMTP settings to bypass the filtering
:frowning: (atleast that seems to be the case with the spamwar in general, a
constantly escalating war of technologies)

Perhaps finding a way to make spam non-profitable, or to put enough of the
high-end spammers in jail? this seems like a daunting task I must admit :frowning:

-Chris

18

Paul Vixie wrote:

that's somewhat the opposite of empowerment. if a "spam solution" can
take away that crisis and the expense is that my dsl-connected end host
has to tunnel its e-mail to someplace out in <www.vix.com/personalcolo>
then that's a tradeoff i can live with.

You, sure, how about the people who are not really computer literate and use SMTP AUTH to send their mail from various places? Remember that convinience almost always outweighs security with the general population. If it wouldn�t, the ICT market would not look like it looks today.

Obviously the other issue is, which has been raised several times, that many provider SMTP services are not really performing up to the expectations of almost instantaneous email delivery. Delays up to days are not too uncommon occurrences.

Pete

19

This approach has two main advantages over filtering port 25:

1. People can still talk to unlisted SMTP hosts if they feel they have a good reason to do so (ie, I get >to deliver messages directly to my server from home rather than being forced to use my service >provider's which may or may not work)

You're right... Rather than simply having you tell your provider that you're
responsible and having port 25 outward opened up, the freedom for anyone
to send to port 25 on an ad-hoc basis like we have today is a better idea.
Today's spam isn't a problem; everything's working as designed.

I understand your frustration, but the approach of blocking port 25 isn't the right one. It may be convenient for you, but there are plenty of people who have good reasons for using other SMTP servers than their access provider's ones. And do you think people who are unable to run a good mail service will be able to selectively open up filters in a sane way? Filtering can also have a serious performance impact on some equipment. And of course this approach isn't going to work anyway: many access providers can't even be bothered to implement anti-spoofing filters, so there is no way that ALL consumer access providers are going to do this within a reasonable time frame.

The good news is that the IETF is now starting work on this, so expect results in two or three years.

Great idea: here's a case where we need less connectivity and better
operational practices, but rather than take that task on, we should do
more protocol work.

The idea is that new records in the DNS show which hosts are allowed to deliver mail for a domain. This means spammers must use a domain they control. That's a good start, as it makes white- and blacklisting a lot easier.

However, this isn't enough. A next step would be to require that a host that is delivering mail must be flagged as a designated outgoing SMTP host for the reversed mapping domain name of its IP address. (Which obviously isn't going to happen for Joe Cable or Jane ADSL.)

(There is still an issue with IPv6 though, as here everyone, including consumers, usually runs their own reverse DNS servers.)

The reality is that the vast majority of email is handed off to a designated
mail relay (whether we're talking about consumer connections or office
environments), and if we actually configured connectivity in this matter,
there wouldn't be a problem.

I don't think cutting off one of the monster's heads will do it (there was spam in the good old days when Windows didn't do IP without installing Trumpet Winsock or something similar). There are other ways to get rid of almost all spam, but apparently for most people the pain isn't bad enough to start using them yet. (I installed Spamassasin over the weekend, and it caught 50 of 53 overnight spam messages. My client caught the remaining 3, no false positives.)

20

I understand your frustration, but the approach of blocking

> port 25 isn't the right one.

As a generalization this is inevitably false - there are networks where
blocking port 25 is absolutely the right approach, and networks where it
is not.

> It may be convenient for you, but there are plenty of
> people who have good reasons for using other SMTP servers
> than their access provider's ones.

For these people there is port 587.

Using port 25 for smarthosting needs to die (arguably it is already
dead, it just hasn't stopped moving yet). Port 25 is for sending mail
to the recipient's MX host. Port 587 is for sending mail to the
sender's smarthost. The policy requirements and abuse characteristics
of the two types of services are sufficiently different that trying to
treat them as the same, even though they happen to be using the same
underlying protocol, is just going to cause pain.