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: "Perry E. Metzger" <[email-masked]>
Date: 29 Mar 1999 16:33:03 -0500

> ISO8859 now comes in almost as many flavors as Baskin-Robbins

Increasingly, as spammers find more and more relay sites blocked,
they're relying on directly spamming addresses through dialup
accounts.  The toner messages would have been easily stopped if the
IETF mail server blocked mail messages coming from dialup
accounts. The MAPS DUL list helps to automate this sort of blocking --
I do it on my company's systems and it stops nearly half the incoming
spam. At least half of *that* comes from UUNet dialups....

Oh, and yes, I've thus far had no complaints that legitimate mail is
being blocked. Very few people run SMTP servers over dialup, and those 
that do can get around this simply by relaying through their ISP's
legitimate mail relay system.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 29 Mar 1999 16:33:03 -0500

Perry

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 29 Mar 1999 18:01:46 PST

> legitimate mail relay system.

It isn't "SMTP servers", it is "SMTP clients". And requiring that
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:
---------------
5.1.  Submit Mailer Does Not Support DSN

   In some installations the generally available submit server may not
   support DSNs.  In such circumstances, it may be useful for the sender
   to implement [RFC974] mail routing as well as additional submission
   server functions [RFC2476] so that the installation is not
   constrained by limitations of the incumbent submission server.
---------------
Blocking dialup SMTP doesn't seem like it's the right long-term
solution to a dialup terms-of-service abuse.

Larry

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 29 Mar 1999 18:01:46 PST

Larry

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Wed, 31 Mar 1999 01:45:36 -0500

> spam. At least half of *that* comes from UUNet dialups....

You know, I fear that in our quest to remove spam we will make the
Internet "Big Brother Ready(tm)."

Requiring that when I am traveling, that my e-mail route through an ISP's
e-mail server for purposes of censoring it (yep folks, that's what
anti-spam filters implemented at an ISP's e-mail gateway are all about!)
is introducing a nice place to locate message interception facilities
(legal or otherwise).

Then there are other hassles.

Of course most ISP's e-mail relays will not let you have a "From" field
which isn't associated with their service (i.e., I cannot be
"[email-masked]" if I send mail through their server and they don't let me
connect to my mail servers).

Of course those of us with a big institution (like MIT) behind us can
always configure tunnels of some form (like I am doing now, tunneling
SMTP through SSH back to MIT). However not everyone can do this. For
example if I was not affiliated with MIT, I might choose
"[email-masked]" as my home e-mail address. MediaOne is my cable modem
provider. However when I would travel to the IETF, I would likely use the
terminal room (do we provide an SMTP relay at the IETF?) relay or I would
have to send e-mail via my worldnet.att.net dial-up account. Of course
I then won't be able to use the "[email-masked]" address. In the end I
wind up having to read e-mail in multiple locations via multiple PPP
accounts (plus or minus a cable modem). What a kludge!

Finally, as we heap kludge after kludge (anti-spam mail filters, port 25
filters, from address filters...) which add hassle, the spammers find
ways around them. I wonder what they will do next, and what the knee-jerk
reaction to it will be.

                -Jeff

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Wed, 31 Mar 1999 01:45:36 -0500

-Jeff

---

From: Pete Resnick <[email-masked]>
Date: Wed, 31 Mar 1999 02:02:45 -0600

>is introducing a nice place to locate message interception facilities

Routing through an ISP (or running one of the kludges you mention 
later) is not the only choice. All that is required is that you 
either (a) deliver directly (the sub-optimal choice) or (b) route 
through your own authenticated relay. For myself, I choose (b):

In my home/office, I have a dedicated SMTP server running on a little 
old Macintosh. When I'm not on the road, of course, I could be 
running the SMTP server on the same machine as my client and deliver 
directly, but it's easier to have it on a dedicated server. It's 
always connected to the net through my ISDN router. When someone 
connects to the server in the normal way, it will deliver locally for 
me, but it won't relay. When I send mail, my client and server 
autheticate using SMTP AUTH (RFC 2554) with the CRAM-MD5 algorithm. 
Once I authenticate, the server will relay all mail to any site with 
whatever headers I choose to put on the mail (I've authenticated 
already, so why would it care what I put in my From: address). So, 
when I'm on the road, my client simply connects back to my personal 
SMTP server, lumps-and-dumps all of my outgoing mail in one shot, and 
it happily chugs along and does all of the queueing, MX lookups, and 
whatever else it needs to do to get my mail delivered.

No kludges, no tunnels, no censorship, no allowing of spam through 
open relays, and all of my mail gets through. And once both us client 
vendors and them server vendors get our next version of code out that 
supports SMTP AUTH (a bunch of us are almost out the door), any ISP 
you like can implement this and close down their own silly open 
relays. Seems like the smart way to go.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

---

From: Pete Resnick <[email-masked]>
Date: Wed, 31 Mar 1999 02:02:45 -0600

pr

---

From: Ned Freed <[email-masked]>
Date: Wed, 31 Mar 1999 02:04:40 -0800 (PST)

> through your own authenticated relay. For myself, I choose (b):

Alas, (a) runs afoul of the fairly common spam-blocking technique of rejecting
mail sent from addresses known to be associated with dial-up users. 

> whatever else it needs to do to get my mail delivered.

The question here is how many users have the resources to do this, including
the dedicated machine and the nailed-up connection.

> relays. Seems like the smart way to go.

I agree that this is the right long-term solution -- our shipping server
already supports it, as a matter of fact. But deployment will take some time...

				Ned

---

From: Ned Freed <[email-masked]>
Date: Wed, 31 Mar 1999 02:04:40 -0800 (PST)

Ned

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Wed, 31 Mar 1999 12:06:56 -0500

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.

                -Jeff

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Wed, 31 Mar 1999 12:06:56 -0500

-Jeff

---

From: Pete Resnick <[email-masked]>
Date: Wed, 31 Mar 1999 11:26:19 -0600

>this proposed (and in some cases actual) practice that I am most

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.

pr

---

From: Pete Resnick <[email-masked]>
Date: Wed, 31 Mar 1999 11:26:19 -0600

pr