RE: Last Call: SMTP Message Submission to Proposed Standard

["Vaudreuil, Greg" <gregv at lucent.com>]

I believe this is an incomplete protocol addressing inadequately
considered requirements.  I recommend that a working group be formed to
evaluate the requirements and engineer an adequate protocol to meet
those needs.  A working group will provide the visibility necessary for
a project of this importance.

This protocol appears to focus on limiting damage to messages from MTAs
which use inadequate heuristics to implement the defacto protocol for
message submission.  As such, this protocol reads more like a list of
tweaks and improvements to the existing heuristics and SMTP protocol
rather than the properly engineered message submission protocol that is
needed.

In particular, the following defects are noted:

1) The draft specifies extensive content manipulation, including address
completion, security services, MIME  content-transfer encoding and
others.  Content manipulation is a totally new architectural facility
requiring careful thought.  At a minimum, the handling of the
substantial number of unique failures which can be expected to result
from content manipulations need to be described. In this draft,
insufficient SMTP response codes or extended status codes were defined
for this purpose.  (555 used for all content errors)

2) No mention was made of the interaction between the MSA and the client
with respect to the DSN extensions.  DSN provides a rich facility for
packaging and delivering error reports.  At a minimum one might consider
using the DSN format as a mechanism for providing a feature-rich
indication of the error to the client, including a user friendly textual
description.  Further, the MSA is expected to manipulate the RCPT TO
addresses in the ESMTP envelope that the DSN extension is designed to
preserve.  At a minimum this draft should discuss the interactions of
this protocol with the ESMTP DSN extensions.

3) The draft speaks to a number of things that a MSA should do to fix
incomplete addresses submitted from a client. There are two common needs
for server based address manipulation.  The first is to detect and
attempt to correct syntactically invalid addresses.  The second is to
perform an implied directory service function to resolve server based
aliases such as role-dependent names and alias-style distribution lists.
The directory service may also provide the ability to resolve common
recipient names into fully qualified domain names for known local users.
These two roles are substantially different and require careful thought
to determine common rules by which a client may indicate, and a server
may determine the difference between a legitimate alias requiring
expansion, a totally bogus address, an a legitimate FQDN with a trivial
syntactic error.

4) The relay SMTP extension appears incompletely thought out.  It
appears to be a request from the sender SMTP to a receiver SMTP to honor
the existing full standards.  The extension does nothing to resolve the
ambiguity for an MTA which declares RELAY support and receives a message
without the keyword.  Is this an implied request for content inspection
and manipulation?  At a minimum, it requires existing MTAs which do not
manipulate content to support RELAY to protect the integrity of
messages.

This is an incomplete proposal. We have two good message retrieval and
access protocols for Internet Mail.  Let's write one good one for
submission. Lets have a working group to finish this work and consider
the full requirements of this important function for Internet Mail.

Greg V.

> ----------
> From: 	The IESG[SMTP:iesg-secretary at ietf.org]
> Reply To: 	iesg at ietf.org
> Sent: 	Tuesday, April 21, 1998 5:14 AM
> To: 	@ietf.org; @ietf.org
> Cc: 	ietf-submit at imc.org
> Subject: 	Last Call: SMTP Message Submission to Proposed Standard
> 
> 
> The IESG has received a request to consider SMTP Message Submission
> <draft-gellens-submit-06.txt> as a Proposed Standard.  This has been
> reviewed in the IETF but is not the product of an IETF Working Group.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg at ietf.org or ietf at ietf.org mailing lists by May 5, 1998.
> 
> Files can be obtained via
> ftp://ftp.ietf.org/internet-drafts/draft-gellens-submit-06.txt
> 
> 
> 
> 
>