a few brief comments on John's comments, not all of which have to do with
the conneg-over-smtp draft:
- I see two possible paths to "fixing" this proposal
1. do the necessary protocol fixes to make it generally
applicable for email
2. make clear that it has only limited applicability
for smtp-to-fax gateways, either supporting a
single recipient or where all recipients have the
same capabilities, and where relaying and forwarding
were specifically disallowed.
part of making this clear would be to clearly label the extension -
not "CONNEG" or "Content_Negotiation" but FAXNEG or "Fax_Negotiation"
however if pursuing this path it would still be necessary to
leave room for VOICENEG or MIMENEG or whatever, and this still
probably means NOT overloading RCPT.
I strongly prefer alternative #1, because I believe it leads to a less
complex and less costly end-state. In other words I'd far rather have
a single SMTP extension that makes sense in an integrated messaging world
that can also be used by specialized services, than to have separate
extensions for (for lack of a better term) "workstation mail", internet
fax, voice mail, etc.
I do however recognize that there is probably pressure to do this
soon rather than to wait until there can be consensus from
all of the various parties. However, for this same reason I doubt
that the #2 approach should result in a standards-track document.
- I also feel compelled to say that waiting until IETF Last Call to get
public review of any SMTP extension from the wider SMTP community
is a very questionable strategy. This statement could be generalized
by replacing "SMTP" with any other protocol name that has a significant
number of implementations and/or installed base.
- Regarding the idea for a NORELAY extension: I think we would do well
to encourage more direct delivery for all kinds of email. The email
system seems to be becoming more fragile all the time, thanks in large
part to spam and viruses and (often poorly chosen or misconfigured)
countermeasures for these. The more hops that a message has to
travel, the lower the probability that it will be delivered.
However it's not immediately clear to me how a NORELAY extension helps -
will senders (fax or otherwise) really be willing to request it?
- In a similar vein, I think we should reconsider the traditional
encouragement for SMTP receivers to accept RCPT commands without
verification. The reason is that the mail system is now considerably
burdened by spam that is often sent to invalid recipient addresses,
and which often has an invalid return address. Such messages
(and the resulting bounces) clutter up the mail queues and postmaster
mailboxes where they're generally discarded because most postmasters
don't have time to read them any more. Early detection of invalid
recipient addresses allows the message to be immediately rejected
rather than bounced, reducing the load on the receiving MTA.
What we really should do is encourage MTA implementors to provide
the necessary hooks to make possible early detection of bad recipient
addresses.
- regarding failures due to requesting CONNEG
(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.
perhaps more to the point, I think the current semantics are broken.
if the server cannot supply a conneg string for a particular
recipient (because it does not have one or because the sender
lacks permission or whatever) the only reasonable behavior is
for the server to report that fact (which should NOT be a
server-reported error)
at this point the client can either fail to deliver the message
(because it's not willing to downgrade that far) or it can
assume that the recipient has only minimal capabliities (e.g.
simple mode) and do the required downgrade to that mode.
but in the unwilling-to-downgrade case it's the CLIENT's job
to assert the error, not the server's job. the client may have
to assert the error in any cases, since it may not be possible
to reasonably downgrade the message to suit the recipient's
capabliities even if the recipient does support CONNEG.
having the server assert the error just makes things more complex
without adding any real functionality.
- Also, unless the client is acting directly on behalf of the
recipient (which is not required by the draft) the client
is being asked to make a convert-or-fail decision without
any reasonable (sender-supplied or standardized) criteria as
to what kinds of conversions are acceptable.
This seems like another major omission in the current spec.
Keith