--On Sunday, June 13, 2010 1:00 PM +0200 Alessandro Vesely
<[email protected]> wrote:
>...
>> There are enough MAY provisions, statements about things that
>> should be done in ideal circumstances (e.g., no limits on
>> lengths) that "fully-capable SMTP server" is not a
>> clearly-defined term. That makes "MTA" unclear and takes the
>> whole definition into a rathole.
>
> Sorry, I didn't mean to be careless. I used the term
> "fully-capable" after its definition given in RFC 5321 --an
> SMTP server with a queue. Patently, such definition was
> meant to be valid in that context only. Thus, my proposal
> contained two "bugs": this one, of referencing a non-exported
> term, and the more substantial one that you address in the
> text quoted below. However, I proposed the text above rather
> to exemplify the kind of changes that I think are needed, than
> to set a final wording.
>...
Let me propose a different approach that I think addresses your
concerns without descending into the morass I think we would
find ourselves in if we tried to find-tune definitions at this
point. The real difficulty is that we have a more or less
abstract model that, for explanatory convenience, treats terms
like MUA, MSA, and MTA as representing discrete categories of
software. In practice, that is often not true. Even within
5321, we encounter "the SMTP client" ("SMTP sender" in the 821
vocabulary, which is actually more clear) and "the SMTP server"
("SMTP receiver"), but, for example, any mail relay contains
both receiver (server) and sender (client) functions.
Similarly, before we complicated the terminology world by
explicitly separating out submission systems, MUAs needed a way
to get messages to the first-hop, queue maintaining MTA. Some
of them used SMTP and hence were SMTP clients (whether they
maintained queues or not), while others used a wide assortment
of out-of-band APIs or mechanisms or protocols different from
SMTP. I vividly remember one that would try to open a
connection to a destination SMTP server --with MX support and
all-- and send the message, via SMTP, directly out of what we
would normally call an MUA. Only if that first try failed for
some reason would it hand the message off to something that
maintained queues (i.e., that we would call a submission server
today, but a submission server that was not always used).
So I suggest that, where there is any reasonable possibility of
ambiguity, we try to use terms like [is performing an] "MTA
role" or "MTA function", rather than "is an MTA". And, if
people believe that paragraphs that explained the mixture of
roles in practice, somewhat along the lines of the above, would
be significantly helpful, please suggest and send text.
john
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
