ietf-smtp
[Top] [All Lists]

Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard

2002-07-02 16:46:59

IESG,

I want to partially agree with Keith -- this proposal makes me
very nervous and I believe the IETF should share that
nervousness.  Since Keith and Dave are more than capable of
discussing the various issues that have been identifed to the
point of clarity, I want to take a slightly different cut at the
problem and tentatively suggest a different approach.

For me, the root problem here is that the proposal seems to
simultaneously say:

        * The MTA here knows a good deal about the MUAs
        associated with each of the recipients.
        
        * The MTA is able to support a relay function.

It appears to me that, even ignoring layering violations, having
both of those things be true requires either a good deal of
negotiation among a set of relays and the final target host
--going beyond the "next relay will take it and accept
responsibility" model that some SMTP extensions use, e.g., to
support non-7bit-transport-- or there has to be some magic.  I
don't see either in a quick reading of the document.

More generally, I think we should hesitate about SMTP extensions
whose purpose is to support a particular application, without
understanding all of the implications of generalizing them.  I
think this is quite similar to one of Keith's points.

But I believe it has been a characteristic of much of the fax
work so far that relaying is not anticipated (this draft, in
repeatedly commenting about "direct" connections, reinforces
that belief).  Indeed, we have text floating around that
suggests that Internet Fax setups be configured to avoid relays,
just as we have had similar suggestions about EDI-over-email
applications.  Sending a virtual fax to a fax broadcast device
is another matter, of course: to the degree to which any action
takes place in the message content, we've traditionally thought
about that as a UA function, with the broadcast device acting as
a receiving SMTP, delivering the message to the relevant UA (no
matter how automated), which then initiates a completely new
SMTP connection (or set of connections).  Or we have modelled
the broadcast device as a fax-capable SMTP gateway, with some
different mail transport on the far side, which completely
changes the rules.

This is all leading to a constructive suggestion:  Unless there
is a clear need for an SMTP relay function that follows SMTP
rules --e.g., the relay MTA doesn't look at message content at
all-- it may be time for a new SMTP extension/ capability
announcement to deal with these specialized applications that
use SMTP as a message transport but that really aren't email in
the normal sense.  

One version of such an extension would be "NORELAY".  An SMTP
server advertising it would guarantee, if the client requested
that option (presumably on MAIL or a separate command -- this
makes no sense on a pre-recipient basis) to either deliver a
message or bounce it, but, under no circumstances to relay it
off to another SMTP server.  Of course, a server advertising
that extension (or not) could refuse relaying even if the client
didn't request the option: we never require servers to relay.

In the presence of such an option, content negotiation that
would require that the server know about its local MUAs becomes,
IMO, somewhat more plausible.  We have always permitted
originating and delivery MTAs more flexibility than intermediate
ones.

In this particular case, if there was no relaying and the
capabilities of the receiver were really server capabilities,
rather than MUA ones (as would be the case for a dedicated
Internet fax device or a distribution system that simulated
one), the whole picture could be considerably simplified by
treating capability negotiation on a per-SMTP-connection basis,
rather than a per-recipient one.

Is it possible that something of that nature would make sense?

-------------

A few other issues that Keith didn't seem to pick up on (to my
surprise):

(i) So far, it has been a basic assumption of the ESMTP
environment that a server advertising a particular capability
does not (I'd have to go back and look, but I think perhaps MUST
NOT) reject an attempt to request the desired capability.   I
understand the reasons here, given the general model, but
returning a 504 to "RCPT TO:<baz(_at_)bar> CONNEG" (implying
"REQUIRED") would seem to violate that principle.

(ii) In order to facilitate efficient relaying and processing of
messages with large numbers of recipients, we permit, indeed
almost encourage, SMTP receivers to accept RCPT commands without
verification and then to prepare bounce messages if needed.  I
strongly suspect that there are conforming MTAs that can behave
no other way.  It seems to me from this specification that a
server that advertises CONNEG must not perform this types of
deferred operation, at least with regard to that parameter, but
must handle errors within the SMTP transaction.   If that
requirement actually exists, I believe it is very important that
the document point it out.

Also, if relaying is permitted, then either the first relay in
the chain has to have complete knowledge about what will be
permitted downstream (and the document doesn't give any
indication as to how it would find that out), or emailed
rejection messages become an absolute requirement (at least
unless no response is issued to any RCPT TO until the final
delivery MTA has generated a 250 code and returned that along
the line -- I suppose that would be possible, but it would
require yet other SMTP extensions to specify the behavior and it
would probably be a performance disaster).

(iii) I can't reconcile the last statement of section 4.2:

        If the server returns an EHLO 250 code without CONNEG
        capabilities, the client MUST work as "a Simple Mode of
        Facsimile Using Internet Mail" [RFC2305].

With the assertion that this is a general facility, not limited
to fax.   If it is a duck, let's call it a duck and be done with
it.  And, if fax is sufficiently special that we need things
like this, perhaps it is time to add something like NORELAY, or
a FAX extension, to make it clear that what is happening is not
normal SMTP.

(iv) Like Gregory Neil Shapiro, I'm not sure what a "target" is
and I'm not sure the term is used consistently.  E.g., in 4.2,
it appears as if the "target" is not the receiving SMTP server,
but is rather the mailbox (and, presumably, MUA) listed in the
RCPT command.  But 4.3 says "... the target MUST reject..."
which strongly implies an SMTP server action.

(v) Just as an editorial matter, but, in order to avoid
unnecessary confusion, it would probably be helpful if the
document adopted terminology consistent with RFC 2821 (and 821).
E.g., there is no such command as "RCPT-TO", the name of the
relevant command is "RCPT".

--------

To paraphrase advice Dave has given on many other occasions,
let's divide this set of issues up and solve the problems that
are well-defined and that we know how to solve and leave the
rest until there is a demonstrated need.  The problem here, as I
understand it --both generally and after reading the
introduction to this draft-- is fax and fax-like
start-of-session 
capabilities negotiation in a direct connection environment.
Let's think about using SMTP extension mechanisms, if necessary,
to specify/require that case and just avoid generalizations that
require us to deal with all of the poorly-understood (or at
least unspecified in this document)     relaying, intermediary
server, and other issues. 

     john