Subject: Re: Last Call: SMTP Message Submission to Proposed Standard

From: Dave Crocker <[email-masked]>
Date: Mon, 11 May 1998 12:34:29 -0700

At 11:41 AM 5/11/98 -0400, Perry E. Metzger wrote:
>You know, somehow I've been surviving with SMTP for this for years,
>and it works well for myself and my users. I really am not certain why 
>this sudden critical need has arrived. Perhaps the hundreds of
>thousands of people using SMTP for this purpose are mistaken and only
>*think* it works.

The need is not "sudden".  The topic was under discussion for quite awhile,
as in a couple/few years.  

The need HAS been made MORE urgent by the onset of spam problems and the
need to treat submission markedly different from relaying.

You know, the Arpanet went 10 years without a special posting protocol for
mail, instead using an adjunct command for file transfer.  But the net
grows and demands change.  So we created SMTP.  

It's now time to create a distinct posting service and to create it as
simply as possible.  Instantiating SMTP on a separate port and with some
very explicit statements about the strictures at the server, distinguishing
relay processing from submission processing, is the easiest way for us to
accomplish this.

d/

_________________________________________________________________________
Dave Crocker                Brandenburg Consulting        +1 408 246 8253
[email-masked]      675 Spruce Drive        (f) +1 408 273 6464
www.brandenburg.com        Sunnyvale, CA 94086  USA

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 11 May 1998 15:20:54 -0600 (MDT)

> relay processing from submission processing, is the easiest way for us to

The problem with SUBMIT (according to the latest draft I reviewed) is that
AUTH is optional. Unless SUBMIT *requires* authenticated message injection
it isn't going to do anything to solve the spam problem. In fact, it makes
it worse: SUBMIT servers, by definition, *must* support relay.

I still contend that the existing SMTP, coupled with AUTH, and including
the SUBMIT header processing extensions described in the draft, will work
just fine one the existing port. In the course of identifying yourself to
the SMTP server (via AUTH), the SMTP server is able to determine (through
those authentication credentials) whether the authenticated entity is
entitled to "submit" messages. (E.g., if the "submit" bit is lit up in the
credentials for the authentication entity, the server allows relaying and
enables the SUBMIT header processing functionality.) As a bonus side
effect, it ensures the rapid deployment of SMTP AUTH. 

--lyndon

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 May 1998 16:59:51 -0700

>AUTH is optional. Unless SUBMIT *requires* authenticated message injection

That is correct.  No one said that the current spec solves the spamming
problem.  Rather, the concern is to separate submission from relaying, so
that a range of differential services can be considered and developed.  Use
of submission-time authentication is just one -- albeit obvious and
important -- concern.

>just fine one the existing port. In the course of identifying yourself to

It is always possible to multiplex two different services together.
Multiplexing mail over the file transfer protocol worked fine for ten
years.  Analysis of any single item can easily lead one to be convinced
that we do not need to separate things.

The problem is that the "flavour" of submission has come far enough to be
distinguishable from relaying and should therefore be separated explicitly.

If you have two different ports, you can have two different code bases, or
you can have one code-base and let it run on both ports.  If you have one
port, there is no choice.  You must use a single code base.  

Code which has massive numbers of tests like (if relay then...; else ...)
sprinkled freely throughout greatly increases the complexity and bugginess
of code.

d/

---

From: "Perry E. Metzger" <[email-masked]>
Date: Mon, 11 May 1998 21:02:41 -0400

> need to treat submission markedly different from relaying.

I've heard the anti-spam arguments and I just don't belive
them. Forging in-transit mail is trivial, and implementing
anti-relaying in SMTP servers is also trivial. (My site has
anti-relaying -- I have for some time now. It was about twenty lines
of code added to my MTA. No big deal.)

> simply as possible.

I'm not arguing that no posting service has a reasonable use. I'm just 
arguing that the claim that we have a sudden crisis that mandates that 
we take immediate action to push forward this particular protocol
sounded bogus.

Perry

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 May 1998 18:23:50 -0700

>I've heard the anti-spam arguments and I just don't belive

doesn't matter what you or I believe.  what matters is that already 50% of
the smtp sites on the net have turned off posting from outside their local
net.  This is killing mobile users.

In any event, I was using that as an indication of heightened concern about
treating submission as an independent service.

>of code added to my MTA. No big deal.)

Well, you're lucky that spam control is so easy for you.  It is proving
rather more problematic for many other sites.

>we take immediate action to push forward this particular protocol

The topic lay fallow for about a year.  The current urgency has reminded us
to finish the work that was already underway.  Finish means finish, not
start over.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 May 1998 18:23:50 -0700

d/

---

From: "Perry E. Metzger" <[email-masked]>
Date: Mon, 11 May 1998 21:58:17 -0400

Dave Crocker writes:
> net.

A very good idea.

> This is killing mobile users.

Hardly. I'm a mobile user, and I have no trouble uploading mail, AND I 
have relaying off.

> rather more problematic for many other sites.

That is far more a question of sites not actively updating or
maintaining their software than anything else, from what I can
tell. If they were running recent versions of most software they could 
get anti-relaying capability. It certainly doesn't appear to be a
protocol problem -- the existing protocols work just fine.

Perry

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 May 1998 21:46:39 -0700

>Hardly. I'm a mobile user, and I have no trouble uploading mail, AND I 

It's always dangerous to take the practises of a highly skilled technician
and apply it to the general user population.  There are no mechanisms
currently available off the shelf which are well integrated and sufficient,
for doing authentication-based SMTP relaying.  If your pop server happens
to support non-standard access to smtp and the user is running eudora, then
they can use this mechanism, if they happen to know the name of the
undocumented .ini parameter to create by hand.

This is not reasonable to impose on or expect from the general population.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 May 1998 21:46:39 -0700

d/

---

From: "Jack De Winter" <[email-masked]>
Date: Wed, 13 May 1998 11:12:51 -0400

>treating submission as an independent service.

Not a product plug, but our mail server actually has two different modes,
authentication and unauthenticated.  Depending on which you are, you will
either be allowed to relay or not.  This solves the mobile user problem
(as that use can authenticate as soon as all of the services like SMTP
support it, along with the clients) while maintaining the anti-relaying
for those that dont authenticate with the server.

As far as our customers think, this is a very happy medium, except for
the fact that few SMTP clients use authentication at this time.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

---

From: "Jack De Winter" <[email-masked]>
Date: Wed, 13 May 1998 11:12:51 -0400

regards,
Jack