Re: FAQ: SMTP Message Submission to Proposed Standard

Dave Crocker <dcrocker@brandenburg.com> Thu, 14 May 1998 16:30 UTC

Delivery-Date: Thu, 14 May 1998 12:38:46 -0400
Return-Path: cclark
Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id MAA15487 for ietf-outbound.10@ietf.org; Thu, 14 May 1998 12:30:03 -0400 (EDT)
Received: from baygate.bayarea.net (root@baygate.bayarea.net [204.71.212.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA14817 for <ietf@ietf.org>; Thu, 14 May 1998 12:10:44 -0400 (EDT)
Received: (from dcrocker@localhost) by baygate.bayarea.net (8.8.8/8.8.5) id JAA16492; Thu, 14 May 1998 09:06:11 -0700 (PDT)
Message-Id: <199805141606.JAA16492@baygate.bayarea.net>
X-Sender: dcrocker@mail.bayarea.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta)
Date: Thu, 14 May 1998 08:38:10 -0700
To: perry@piermont.com
From: Dave Crocker <dcrocker@brandenburg.com>
Subject: Re: FAQ: SMTP Message Submission to Proposed Standard
Cc: Chris Newman <Chris.Newman@innosoft.com>, ietf@ietf.org, ietf-submit@IMC.ORG
In-Reply-To: <199805141512.LAA06357@jekyll.piermont.com>
References: <Your message of "Wed, 13 May 1998 22:42:16 PDT." <Pine.SOL.3.95.980513213445.25461V-100000@elwood.innosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:12 AM 5/14/98 -0400, Perry E. Metzger wrote:
>> The email industry desperately needs an authenticated submission
>> service.
>
>Given that relaying isn't authenticated, this strikes me as
>unimportant. Remember that SMTP is not an end to end protocol but a

This reaction is perhaps a good exemplar for what I suspect is the real
problem in this debate, namely that IETF technical work has gotten much
more specialized -- i.e., there are masses more of detail and context to
each activity -- and those of us -- yes, I said us -- who like to dabble
broadly often don't have quite enough background to get away with it.  One
might counter by saying that FAQ and other explanatory efforts need to be
thorough, but that's really an impossible task, if carried to its logical
extreme.

The need for submission-time authentication is to create a basis for what
is being called "first hop accountability", so that the service which
injects the message into the mail relay system can be help responsible for
allowing spam to be passed.

In other words, authentication now has a variety of purposes, not just to
permit the final recipient assurance of correct author labeling.  I'm a
large fan of end-to-end data object security, but this particular
requirement does not need it.

>> (2) Why have a separate submit port?
>> 
>> Submit and relay are separate services.  Submit needs to have more
>> stringent validation of content,
>
>I dispute that. If you can forge a submission via forged messages to
>the relay, then why will stringent validation on ingress help?

Sources which allow forged mail will come to find that sites no longer
accept mail from them.  Or they will find serious legal repercussions for
permitting spam to be injected.

>> (4) Why doesn't security protocol X solve all the problems?
>> 
>> MTA/MUA vendors have to sell products which work out of the box.  That
>> means they can't insist on the installation of custom TCP/IP stacks
>
>TLS requires no custom hacks. Its layered on top of TCP, and it is
>standards track.

Since when does the IETF require one and only one solution to be make into
a standard?

One of the other unfortunate aspects about this debate is that it has been
focused on security and spam, rather than email functionality and
architecture.

It's fine that we've gone so long without a separate posting protocol, just
as it was fine we went so long without a special relaying protocol.  But
the divergence between posting and relaying has been developing for a few
years and it's now time to make it official.

d/

_________________________________________________________________________
Dave Crocker                Brandenburg Consulting        +1 408 246 8253
dcrocker@brandenburg.com      675 Spruce Drive        (f) +1 408 273 6464
www.brandenburg.com        Sunnyvale, CA 94086  USA