Subject: Argh. the spam.. make it stop...

From: [email-masked]
Date: Mon, 29 Mar 1999 00:42:14 -0500

And I'm not sure if I'm more upset at the people trying to
sell me toner cartridges or the people who obviously don't
know that the world isn't just ASCII anymore, and that
ISO8859 now comes in almost as many flavors as Baskin-Robbins
ice cream...

Out of curiosity, did the ietf-censored list trap either of
those missives?

				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 30 Mar 1999 08:28:51 -0700 (MST)

The Benchmark Print spammer has been around for several years.

> From: "Larry Masinter" <[email-masked]>
> ...

> the client relay through their ISP's mail relay system has several
> problems. For example, in trying to find a workaround for Internet
> Fax machines that want ESMTP support for DSN (to get message 
> confirmation), it seemed reasonable to expect that a client that
> cared about immediate delivery might very well run a SMTP client
> over dialup. From RFC 2532:
> ...

What can such a client do with SMTP that cannot also be done with an
additional, initial hop through POP, IMAP or some other MTA-MUA protocol?
So how is such filtering a real inconvenience?  If the hop through your
ISP's SMTP server takes more than a few minutes, you should do the
obvious--fire your ISP.

Besides, and with appologies to the authors of RFC 2532, sending a FAX
through SMTP is even less interesting than the hand wringing and whining
10 or 15 years about how everyone was using FAX instead of email, that
FAX might replace email, and could we build email-FAX gateways.  There
are many older, much better, more standard, essentially universally
available ways to send pictures through SMTP or other network links.
Sending a FAX of pure text through a TCP connection in 1999 when everyone
has SMTP, HTTP, and even FTP is one of the more amazing pointy-haired
exercises and ranks with RFC 1149.

Then there is what economic reality says about how many boxes will ever
be able to convert a FAX to SMTP or vice versa.  How many would buy
hardware or software to send FAX's over SMTP when they can more easily
scan and send documents with their current equipment, and be vastly more
confident that their correspondent will be able to deal with the message?

> Blocking dialup SMTP doesn't seem like it's the right long-term
> solution to a dialup terms-of-service abuse.

I agree that it would be better technically and administratively more
effective if ISP's would actually enforce their terms of service.  Some
ISP's that generated a lot of spam 18 months ago imposed real penalties
and instantly stopped having spam problems.

Many ISP's running dialups filter TCP SYN's addressed to port 25 from
their customers to prevent spam and other email abuse.  Reportedly some
filter all port 25 SYNs while others allow connections to their own SMTP
servers.  UUnet has been promising for months that realsoonnow they will
also filter connections to port 25 from their dialups.  For much longer,
UUnet has been advising the rest of the Internet to reject all SMTP
connections from their dialups.  So many SMTP servers use private black
lists or global tools such as http://maps.vix.com/dul/ that regardless of
what might you might prefer, it is insane to hope to use dialups to reach
most SMTP servers.  Once practices such as dial-up filtering become
established, they last forever.

Finally, the main IETF list gets very little simple spam.  There is far
more junk (esp. kook) mail that could be avoided by rejecting everything
from the large free email providers such as Hotmail.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 30 Mar 1999 12:49:29 -0700 (MST)

> From: "Larry Masinter" <[email-masked]>

> ESMTP/DSN (RFC 1891).

As we've all known for the at least the last 20 years, during which such
mechanisms have been proposed and several times implemented, few would
knowingly turn on a mechanism that lets general senders know when or
whether they've read a message.  The BSD "Return-Receipt-Request" mechanism
is at the outer edge of what people will tolerate for good, sufficient,
and well known non-technical reasons.  They include the reasons why some
people refuse all U.S.Postal Service "registered" or "certified" mail,
and why many people refuse "registered" or "certified" USPS mail from some
senders.

However, that objection to the idea of DSN asside, I see nothing in RFC
1891 that limits the total number of end-to-end SMTP hops to one.  I would
not expect even the modern IETF to advance an RFC with such an idiotic
limitation.  In other words, adding an additional hop to what is likely
to be a multi-hop SMTP path cannot hurt any application that has any hope
of working.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 30 Mar 1999 21:40:00 -0700 (MST)

> From: Keith Moore <[email-masked]>

> DSN is more-or-less equivalent to sendmail's ill-named "Return-Receipt-To" 
> mechanism (i.e. DSN is a *delivery* notification, not a read- or receipt-
> notification) except that DSN is done *correctly* - in the MTA-MTA 
> protocol, NOT the UA-UA protocol.  (the latter is not only a layering 
> violation, it has been known to contribute to sorcerer's apprentice syndrome).

Do you count the part of sendmail that responds to Return-Receipt-To lines
as part of the MUA instead of the MTA?  How does a change in the layer
label on the code or the (desirable in my view) movement of the mechanism
from header lines to the envelope prevent loopy problems in bad code?
Has other than amazingly grossly misconfigured sendmail been blameworthy
in an a Return-Receipt-To loop in the last 10 years?  Other code doesn't
count, since I bet I could write a broken MTA that loops with ESMTP DSN's.
Violations of section 7.1 of RFC 1891 look promising.

> If you were thinking of Message Disposition Notifications (MDNs), 
> ...

Yes, I was foolishly, sloppily confused.

> >         ...  In other words, adding an additional hop to what is likely
> depends on the nature of the hop.  ordinary MTAs get maintained and 
> upgraded to support new SMTP options (most vendors support DSN now), 
> but this is not necessarily true of MTAs performing as "firewalls" 
> and similar boxes.

That is a notable disadvantage of putting DSN's in the envelope.  However,
for years support of Return-Receipt-To has been so spotty that it's not
a significant loss.

The connection between ESMTP DSN's and Internet FAX has been explained to
me in private email.  I think I now understand, but am unconvinced.  I
can't believe that delivery notifications are a big part of the appeal of
FAX's.  We've all sent and failed to receive too many FAX's that
disappeared despite the delivery notifications of FAX machines.
Notification of delivery to some machine somewhere is not the same as
notification of delivery to the right fax machine or of movement from FAX
machine to the right mailbox.

Regardless of all of that, or the effects on ESMTP DSN's or Internet FAX
or its general technical or administrative desirability, filtering on port
25 SYN's is here to stay.

Having the [email-masked] exploder refuse to forward from the dialups that
UUnet says that UUnet will realsoonnow be filtering, and the other major
sources of pure junk would not do any harm and would do some good.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 30 Mar 1999 21:40:00 -0700 (MST)

---

From: "William Allen Simpson" <[email-masked]>
Date: Wed, 31 Mar 99 12:31:37 GMT

-----BEGIN PGP SIGNED MESSAGE-----

Gentlefolk -- funny, how the same topic gets recycled so often....

Relays are a terrible idea in practice!  They are left over from the old
X.400, usenet, fidonet, and bitnet days.

SMTP is much better as an End-To-End protocol!

Where, oh where, have the end-to-end folks gone?

If spam becomes a problem again on _this_ IETF list, just require
everyone to PGP sign their messages!

Spam blocking at open relays was a simple short term solution.  It is
not as useful in the end-to-end Internet.  Why are we discussing forcing
everyone to go through relays, just to make them easier to filter?

Requiring SMTP clients to have at least one relay in their mail path is
a Very Bad Idea.  It is a bad idea currently implemented in Eudora and
Messenger, but not in most useful mail clients.  (I don't find having to
re-type the SMTP server in the configuration panel for each message
destination before sending to be very user-friendly at all.)

My home ISP (Merit) does not offer relay service -- none at all!

Many of the Merit affiliated organizations have relays for their
specific students and faculty, because those persons need them for
Eudora or Messenger, but they are often ill-maintained and/or open
relays.  (Hopefully, the one you find in this message is well maintained.
If not, please let me know, so I can tell them.)

My away ISP (WaterValley Interchange) offers relay service to IP
addresses specially configured, and for a very limited time after
POP'ing email.  It is of little or no use to me at home.

As for the latter, I can make it do pretty much whatever I want for
policy, since I'm an owner, and I _still_ don't find it useful at home!

I don't think that forcing everyone to go out and start their own ISP is
a particularly good (or likely) scenario anyway (although with the
number springing up, it seems like everybody _is_ starting their own ISP
;-)  You'll get even more badly maintained open relays.

Those relays will be on ISDN lines, xDSL, cable modems, and good
old-fashioned dialup, all with variable IP addresses, and you won't be
able to filter them anyway.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 31 Mar 1999 11:25:49 -0700 (MST)

SMTP relays have disadvantages, and single-hop, end-to-end SMTP is nice.
However, relays are here to stay except for the small minority of users
whose systems are fully exposed to the net.  Corporate firewalls are here
to stay.  Only the very smallest and very largest sites can afford to put
their main email systems on their firewalls (never mind security worries),
and so firewalls tend to be SMTP relays.

> >Your client cannot connect back to your own SMTP server if the ISP you
> >are using blocks TCP traffic to port 25 from a dialup connection! It is
> >this proposed (and in some cases actual) practice that I am most
> >concerned with.

Aren't there other MUA-MTA protocols that can be used for the first hop?
Doesn't one of the varients of POP or IMAP handle submission?
Can't you always fall back to SSH, telnet, or even rlogin?

Couldn't you use an SSH tunnel between your roving laptop and your home
system, and pipe SMTP through the SSH tunnel?  If you are exchanging email
with coworkers back home that you might not want other people to see (eg.
competators at the IETF), isn't some kind of confidentiallity beyond
ordinary SMTP desirable?  Many companies have rules about letting "company
confidential" or more secret email come even as close to the Internet as
their firewalls for fear of leaks, unexpected bounces, and spies.

> One of my points was that once SMTP AUTH becomes ubiquitous, ISPs 
> will no longer have any reason to block TCP traffic to port 25 from 
> anyone.

How does SMTP AUTH affect anything?  Doesn't it still use port 25?
(As far as I can tell from a quick check of RFC 2476 and RFC 2487,
both of those do.)
How can an ISP filter SYN's to a distant port 25 if and only if the
subsequent SMTP/TCP/IP chitchat will include authenticators?

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 31 Mar 1999 13:50:37 -0700 (MST)

] From: "Theodore Y. Ts'o" <[email-masked]>

]    Couldn't you use an SSH tunnel between your roving laptop and your home
]    system, and pipe SMTP through the SSH tunnel?  
] 
] *I* could configure an SSH tunnel if I needed to use that to get back to
] my home system.  I don't consider that a supportable solution to tell
] our help desk to give to random users who need to be roaming and who are
] using off-the-shelf mail clients.

That sounds like at most a small user-interface problem and possibly a
business opportunity.  The SSH tunnel parameters are not complicated.
(Besides SMTP, I also use SSH tunnels to reach confidential HTTP and NNTP
servers from 1000's of miles away.)

> From: Pete Resnick <[email-masked]>

> ...
> My point was that an ISP doesn't need to filter SYN's to port 25 if 
> it runs SMTP AUTH; it can let all traffic through. If a connection 
> comes in unauthenticated, it can (if it wants) allow local 
> deliveries, but it won't relay. If authenticated, it can allow relay 
> and sending of mail anywhere the connector wants.

I doubt we talking about the same filtering.  I think it is:

  1. done by routers owned by the ISP that owns the pool of dial-up modems
    (e.g. UUnet) and that consists of discarding TCP SYN's received via
    dial-up modems and addressed to any other host except a few that are
    owned by the ISP.

  2. by spam targets within SMTP servers or on routers and that consists
    of rejecting all SMTP connections from IP addresses or domains thought
    to be dialups (e.g. da.uu.net).

UUnet has been publicly promising to implement #1 for several months, and
has been publicly recommending #2 for many months.  #2 is widely deployed
on individual SMTP servers using ad hoc lists or the automagic DNS
described at http://maps.vix.com/

In both cases, the SMTP code of the dial-up ISP is not involved.  The only
filtering done by the dialup ISP is against TCP/IP headers and is commonly
done on the ISP's routers.  I do not see how SMTP AUTH is relevant.  The
ISP will have filtered (discarded) the SYN to a distant port 25 long before
the ESMTP AUTH chit-chat.

If you mean that dial-up ISP's would use #1 to force their dial-up
customers to connect only to the ISP's port 25, then SMTP AUTH is still
irrelevant.  Other people in this thread have been saying they do not want
to use the dial-up ISP's SMTP server and object to #1 and #2 filtering.
Second, because the ISP owns the radius servers, the modem banks and
everything else, there is no honest reason why the ISP cannot use any of
the old, already available SMTP authentication mechanisms listed in RFC
2476 and largely fix the spam problem.

> This of course doesn't address our spammers who have the resources to 
> set up their own SMTP servers and connect end-to-end to everyone that 
> they want to spam. But we have other resources for limiting their 
> ability to do that.

For many months, it has been true that almost all spammers set up their
own STMP servers (actually clients) and blast away at port 25 all over
the net.  Their direct targets are generally "open relays" because
filtering of dialups (#2), spam houses, and free email providers is so
common.

No rocket science or even sendmail is required of the spammers.  The
equivalent of some scripts and `telnet domain.com 25` is enough, although
I'd choose to pervert sendmail.  (Spammers do not want a real SMTP client,
since they prefer to give up and not retry after failures.)

Because few if any ISP's are now willing to host the sending machinery of
spammers at a fixed IP address for more than a little while, the spammers
prefer to use throw-away accounts at ISP's such as UUnet that impose no
significant penalties for abuse.  They rent an account for a day or two,
connect to port 25 at open relays, and then get cancelled (or so UUnet
says.)  Another attraction of the dialup pools is that UUnet shields the
identities of their dial-up spammers, which makes it harder for individual
targets to go after spammers with the various state anti-spam laws.  (Some
are talking about using the new Virginia criminal law against UUnet itself,
which might be entertaining.)

Yes, of course, if only the ISP's would impose real penalties on their
spamming customers (e.g. $200 per day of spamming), then the current spam
problem would instantly disappear.  As long as there are major outfits
like UUnet (and UUnet's resellers) that charge $20 for a day's worth of
dial-up relay-rape spamming, technical defenses will be popular.  Moreover,
those defenses, including port-25 filtering, will remain long after the
spam problem is solved.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 31 Mar 1999 17:04:17 -0700 (MST)

> >  1. done by routers owned by the ISP that owns the pool of dial-up 

> OK, let's start with this. Why is this filtering desireable? You say below:
> ...

> Exactly so. Spammers exploit open relays. That is, they don't want to 

Open SMTP relays only provide "gain" and "cover" to spammers.  Relays are
a great convenience to spammers, but not required.  Do the math.  A 56K
modem with reasonable v.42bis or PPP compression can easily send 50-100
MBytes or 100K separate spam in 4 hours.  Sort your address list so that
each message has 10 addressees (to avoid tripping some spam filtering),
and you've hit 1 M spam targets in 4 yours.  Open relays improve that by
only 10X or 100X.  That's why a lot of spam from UUNet dialups is not
relayed.

> So, if open relay people install SMTP AUTH, I no longer would care 
> about UUnet installing SYN filters. Furthermore, people who run SMTP 
> servers in general will not have to worry (as much) about doing 
> incoming router-level filtering. 

Look at the next relayed spam you receive, and notice that the relay is
grossly misconfigured, running ancient code that has long since been fixed
to not relay undesirably, or is running hopeless junk.  If the open relay
people could install SMTP AUTH, why wouldn't they first close their open
relays?  It's trivial to fix an open relay with current software, while
installing SMTP AUTH has inevitable, pesky problems, starting finding code
that does it now and continuing forever with keying hassles.

>                                  Only mail destined for local hosts 
> would be allowed if they are running SMTP AUTH.

SMTP AUTH is completely irrelevant there.  You *do not* need SMTP AUTH to
completely prevent relaying email to strangers from other strangers.  It's
*trivial* to relay only to or from local hosts.  How do you think most
big sites on the Internet managed to close their relays years before SMTP
AUTH?  You only need SMTP AUTH or other mechanisms if you want to allow
some but not all apparent strangers to relay through your system to other
apparent strangers, and you do not have other means of authenticating the
first strangers, such as IP address ranges.