SMTP authentication for broadband providers

Mailman List Mirror (Read Only)
1

To attack spam, we need to attack it at its core, not at some secondary

or

tertiary side-effect, with a mechanism that also hurt legitimate users.

We, as network operators don't need to attack spam. We need
to ignore spam itself and get to work securing the network
that enables spammers to do their dirty work.

Unless and until there is broad community consensus that answers that
question in concrete and practical terms, then all our efforts are
losing and stop-gap.

I wouldn't go quite so far as that. Yes, broad consensus of
the network operator community would help us to secure the
architecture of the email system. That's why I have suggested
that large email operators should be meeting regularly in a
forum where they can discuss and agree upon *BEST PRACTICES*.

But it also helps for people to implement best practices in
a piecemeal fashion because that provides the real-world
operational experience to prove that a particular practice
is feasible.

From recent conversations on the list it appears that the

BCPs for email include using the submission protocol for
all end-user sending of email. But I would like to see this
go a step further and require SMTP AUTH for every single
SMTP session on port 25 as well. That means that AOL's mailservers
would have to authenticate their sessions on Hotmail's servers
before sending email and vice versa. It means that you cannot
operate a mailserver without having a bilateral agreement in
place with some set of email peers. It provides a chain of
trust through those bilateral agreements that makes it easier
to block SPAM and catch spammers.

Yes, this probably means that we need to have some DNS
related changes so that a domain can publish a list of
their email peers and so that MTA software can figure out
where to forward a particular email to reach its destination.

But none of this is rocket science. And all of it could be
accomplished by sitting the major email operators around
a table to hash it out. NANOG could help here by devoting
the next meeting to the various technical operational email
issues and by extending to an additional day for the email
operators forum. There is plenty of BCP material that could
be presented and even though some of the operators like AOL
have presented this in the past, an update would be useful
to a lot of us.

--Michael Dillon

2

go a step further and require SMTP AUTH for every single
SMTP session on port 25 as well. That means that AOL's mailservers
would have to authenticate their sessions on Hotmail's servers
before sending email and vice versa. It means that you cannot
operate a mailserver without having a bilateral agreement in
place with some set of email peers. It provides a chain of

40 million .coms...

Yes, this probably means that we need to have some DNS
related changes so that a domain can publish a list of
their email peers and so that MTA software can figure out
where to forward a particular email to reach its destination.

Yeeee-Haw! A return to the Old West of bangbaths and pathalias.

No thanks.

3

Much talk about using SMTP AUTH, but nothing about using STARTTLS?
Alone, SMTP AUTH is somewhat better, but requires that the passwords be stored
plain-text on the server (CRAM-MD5 or DIGEST-MD5), or that the password
traverse the wire in plain-text (PLAIN or LOGIN).

So by requiring STARTTLS for SMTP AUTH the transmission can be encrypted and
the passwords on the server encrypted as well.

Furthermore, if mail server admins step up and enable STARTTLS on their systems
it opens up the possibilities of using certificate verification and PKI.

4

That's absolutely the issue with emerging resignation to "e-mail peering" and the like being the only solution to the spam problem.

Folks who've been around long enough to remember UUCP maps or ADMD=/PRMD= know how huge the cost and support overhead of unreliability per e-mail sent is relative to SMTP delivery.

Before we drop into that particular trap I'd like to think that one more attempt could be made at using PKI to do MTA identification.

Maybe I'm a dreamer, but a world in which I only accept mail from MTA's that present a certificate from a CA I trust seems way better than one where I need an offline contract with a necessarily few people, and the world has to work out how to reach me through them.

This won't stop spam at all levels, but neither will e-mail peering as it will still be possible to inject SPAM into a provider's network and therefore get it transited through their peering links. It's much easier to kill a black-hat or just careless MTA by locally blacklisting an individual public key, CN=, O=, or even C= if I'm minded to.

5

*Not* that I think bilateral peering for SMTP is a great idea, but: a
web of trust (A trusts B, B trusts C) does not necessarily mean
the mail has to traverse the route of the web of trust (i.e. if
A can establish B trusts C, then why not accept the mail directly
from C if all B is going to do is forward it in essence unaltered).

Perhaps this is no different from having someone DNS sign some form
of inverse MX record saying "this is my customer and they shalt
not spam you or lo the wrath of my abuse department shall descend
on them and cut them off", and people not accept mail from those
without that an inverse MX record signed by someone they trust,
someone who someone they trust trusts (etc.).

Alex

6

The unfortunate fact is lots of people like to operate open, anonymous
services and then expect other people to clean up after them.

Why don't IRC operators require authentication of their users?
  ISPs should block 6667

Why don't SMTP operators require authentication of their users?
  ISPs should block 25

Why don't NETBIOS operators require authentication of their users?
  ISPs should block 135, 137-139, 445

Why don't P2P operators require authentication of their users?
  ISPs should block everything

7

) The unfortunate fact is lots of people like to operate open, anonymous
) services and then expect other people to clean up after them.
)
) Why don't IRC operators require authentication of their users?
) Why don't SMTP operators require authentication of their users?

Why don't HTTP operators require authentication of their users? If I'm
researching testicular cancer on the web, that may involve web sites, IRC
support channels, or mailing lists.

The *truly* unfortunate fact is lots of ISPs like to do things like throw up
firewall rules and then expect other people to clean up after the real
problems they are simply evading.

Consider this: A pathogen is developed that kills anyone with which it comes
in contact. People across the world are randomly exposed to the pathogen and
begin dying en masse.

Short-term public interest would seem to necessitate that hosting public
meetings should now be discouraged, if not outright banned. In some areas,
ordinances might be passed requiring that any human contact be made only if
both parties know each other, and can prove they have adequate air
filtration.

This isn't the plot to next summer's killer Sci-Fi horror movie; this is
what we are dealing with on the Internet today. In either case, the long-
term public interest would probably be served more by funding agencies to
track down and stop the spread of the pathogen.

8

) The unfortunate fact is lots of people like to operate open, anonymous
) services and then expect other people to clean up after them.
)
) Why don't IRC operators require authentication of their users?
) Why don't SMTP operators require authentication of their users?

Why don't HTTP operators require authentication of their users? If I'm
researching testicular cancer on the web, that may involve web sites, IRC
support channels, or mailing lists.

If you have a read-write HTTP web site (i.e. send e-mail through web,
write web blogs, etc), why don't you have authentication before permiting
users to write? This includes news web sites which let you "forward"
stories by entering arbitrary addresses. mailfrom.cgi and friends is as
much of a problem.

If you want to tell everyone in the world about your new and improved
cure for testicular cancer available for the low low price of $119 by
sending continious messages on unauthenticated IRC channels, mailing
lists and web blogs why should the ISP pierce the veil of anonymitity the
IRC operator, mailing list operator, web blog operator wanted?

The operator of the anonymous service should deal with the consequences
of maintaining that anonymitity. ISPs authenticated their users. But
that doesn't mean it is the ISP's responsibility to track down users of
anonymous services everytime there is a problem.

This isn't the plot to next summer's killer Sci-Fi horror movie; this is
what we are dealing with on the Internet today. In either case, the long-
term public interest would probably be served more by funding agencies to
track down and stop the spread of the pathogen.

Restuarant operators are responsible for the safe preparation of the food
they serve and the cleanliness of their resturants. It is not up to the
highway department to prevent sick people from visiting your restuarant
or to monitor the trucks transporting food on the highway.

If you want the ISP (highway department) to control it, expect them to
set up inspection points on the roads they control and disrupt all
traffic. If you don't want ISPs doing this, don't ask them to enforce
things they shouldn't be doing.

9

good while doing that add !@proxad.net to the list of spammers that bug
people

-Henry

10

) On Mon, 16 Feb 2004, Daniel Reed wrote:
) > On 2004-02-15T17:33-0500, Sean Donelan wrote:
) > ) Why don't IRC operators require authentication of their users?
) > ) Why don't SMTP operators require authentication of their users?
) The operator of the anonymous service should deal with the consequences
) of maintaining that anonymitity. ISPs authenticated their users. But

And in large part, we do. I am an IRC Operator on a large IRC network,
called EFnet, and I do report abuse whenever it occurs in my presence.

Unfortunately, I have never received an affirmative response from an ISP
after reporting such abuse; never received a request for additional
information; and certainly never seen the problem host cease to be a problem
after reporting.

I am perhaps one of the few operators still interested in abuse reporting;
many have simply resigned themselves to finding abusers using constantly-
evolving techniques and simply banning them from the network when they are
found. This helps us in the short term, but is only an arms race in the long
term. It is a commonly held belief that any type of subscription service
will be repeatedly evaded through technical innovation; the fix must come
from the providers.

The problem appears to be that many network operators do not think of
themselves as anything beyond commercial network providers. Many appear
loath to take any effort above and beyond ensuring their users' bills are
paid regularly, or their budgets are kept low, etc. Many will have RFC 2142
contacts, but appear to discard incoming mail. Some, such as Charter
Communications, do not even have these mandatory addresses (mail is not
accepted for <abuse@charter.com>).

) Restuarant operators are responsible for the safe preparation of the food
) they serve and the cleanliness of their resturants. It is not up to the
) highway department to prevent sick people from visiting your restuarant
) or to monitor the trucks transporting food on the highway.

And on the other hand, it is the CDC that would perform an outbreak
isolation, not the restaurant staff.

The CDC would also trace who the infected person had contact with and take
steps to verify their health, etc. The restaurant could not possibly hope
to have the resources or training to effectively deal with people walking in
off the street carrying a deadly pathogen, and still have enough resources
to provide a decent service.

11

paid regularly, or their budgets are kept low, etc. Many will have RFC 2142
contacts, but appear to discard incoming mail. Some, such as Charter
Communications, do not even have these mandatory addresses (mail is not
accepted for <abuse@charter.com>).

while they do not conform to the RFC, they receive accept mail at/for
abuse@chartercom.com

[This would be the domain w/o outsourced MX...]

And on the other hand, it is the CDC that would perform an outbreak
isolation, not the restaurant staff.

You're talking about a concerted effort. So far, I haven't seen the
levels of cooperation between providers that is required. I'm all for
everyone holding hands and squashing out issues. But until you get
past the isolationist mindset (you must be sick of me saying that by
now) good luck...

I think we're both in agreement that until * starts saying "If I
don't stop this today, it will hurt me tomorrow", that the
cooperation required to address and stop these issues will be nil.

-mark

12

) On Mon, 16 Feb 2004, Daniel Reed wrote:
) > And on the other hand, it is the CDC that would perform an outbreak
) > isolation, not the restaurant staff.
) I think we're both in agreement that until * starts saying "If I
) don't stop this today, it will hurt me tomorrow", that the
) cooperation required to address and stop these issues will be nil.

I am not sure it will take any major coordinated effort. For many outbreak
incidents, the CDC would respond in the U.S., other agencies would respond
elsewhere.

Coincidentally enough, CNN.com just posted an article "Your PC could be a
'spam zombie'" <http://www.cnn.com/2004/TECH/ptech/02/17/spam.zombies.ap/>.
The provider mentioned appears to be turning off customers [unwittingly]
involved in abuse without any major coordinated effort behind them. (And I
am sure there other examples of providers taking such action.)

13

Well they accept mail at abuse@charter.com but they certainly don't do
anything about it. I have sent numerous complaints to that address with
absolutely nothing happening to fix the problem. The address is a black
hole.

Roy

14

I am not sure it will take any major coordinated effort. For many outbreak
incidents, the CDC would respond in the U.S., other agencies would respond
elsewhere.

To perform a traceback in the US the CDC works with hospitals,
doctors, etc. since they have the authority to do so. Which body has
that authority within the US (and knows how to use it). Law
enforcement comes to mind, but that doesn't scale.

Nor is this the right place to discuss that issue :wink:

Coincidentally enough, CNN.com just posted an article "Your PC could be a
'spam zombie'" <http://www.cnn.com/2004/TECH/ptech/02/17/spam.zombies.ap/>.
The provider mentioned appears to be turning off customers [unwittingly]
involved in abuse without any major coordinated effort behind them. (And I
am sure there other examples of providers taking such action.)

Everyone knows about/of spam. Does everyone know about DoS? I'm just
throwing it out there as an example, I don't really want to get in to
who should know what, etc... These problems [as all issues] are
a topic that only those passionate few [those typically affected by
it] truly seek resolution. I believe it is human (or maybe just
American?) nature to not care until something affects you.

alas, i'm lacking operational content, so this is my final bit of
input on the matter.

-mark

15

Well at least they are somewhat DNS responsible in that they seperate their
user IP space well. SO that it can be blocked. the really annoying ISPS's use
stupid things like DSL1234.isp.com And such.

Of course doing this does block those 1 in 100 people runing a server on their
DSL line and not requesting a reverse DNS change.

la.charter.com 550 NO Mail Accepted From DSL
va.charter.com 550 NO Mail Accepted From DSL
mn.charter.com 550 NO Mail Accepted From DSL
ga.charter.com 550 NO Mail Accepted From DSL
ct.charter.com 550 NO Mail Accepted From DSL
ma.charter.com 550 NO Mail Accepted From DSL
ca.charter.com 550 NO Mail Accepted From DSL
wi.charter.com 550 NO Mail Accepted From DSL
al.charter.com 550 NO Mail Accepted From DSL
sc.charter.com 550 NO Mail Accepted From DSL
tx.charter.com 550 NO Mail Accepted From DSL
nc.charter.com 550 NO Mail Accepted From DSL

Nicole

16

1700+ attempts from one IP address to send mail today via one of my servers.