Bruce, fwiw, this general approach was discussed when this
protocol was first being designed. I can't remember all of the
reasons why it was rejected, but at least one of them was that
we didn't want to put unreasonable burdens on clients. At this
stage, you are talking about what would, in essence, be a whole
new protocol design. For that, I think you are going to need
both a draft (not an email note with an outline of what you
would like to see in principle) and a compelling reason to undo
or change what, operationally, does not appear to be broken.
john
--On Wednesday, 02 March, 2005 15:15 -0500 Bruce Lilly
<blilly(_at_)erols(_dot_)com> wrote:
...
There's another fairly simple way to handle the situation; a
"submit" server could offer an extension keyword (or multiple
keywords) that identify the types of modifications it will
perform in the absence of direction to the contrary by the
client. The keywords would be defined solely for "submit"
use, so a client encountering any of them would be able to
identify the "submit" protocol. If none are offered, then
either the server is an SMTP MTA, or won't modify the message
content (in which case it is acting as an SMTP MTA (should)).
Corresponding verbs would allow a client to direct the MSA
to disable certain modifications. Some observations:
1. legacy clients not supporting recognition of the extension
keywords won't be able to distinguish ESMTP from "submit".
Same as now. But future client development could take that
information into account.
2. legacy clients would not be able to direct the MSA not to
apply some modifications. Same as now, but again, future
clients could benefit. Such clients would be able to
determine -- in advance -- what sort of modifications
would be performed, and could either negotiate application
of those modifications (e.g. "no, I don't want you to
alter 'foo.com' in the address fields, that's what I mean,
not 'foo.com.bar.org'") or terminate the session.
3. If a session is initiated with HELO, the extension
mechanisms would be unavailable. Ergo, a client would
be unable to determine if the server is an MSA or MTA
(same as now). MOral: if the client needs to know, let
it speak ESMTP.
4. It might even be reasonable to disallow HELO on port 587.
5. The verbs corresponding to the "submit" extension keywords
would be disallowed to MTAs acting as clients (though I
can imagine a sort of split gateway where some non-SMTP
transport might make use of an MSA to do part of the
translation work, so maybe there should be an exemption
to allow for that).
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf