On 13/Jun/10 20:11, John C Klensin wrote:
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.
Yes, and TCP/IP nicely dresses the client/server metaphor by providing
for listening vs. connecting sockets.
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).
Direct-to-MX handing is apparently what Submit tries to avoid.
Although direct connections would be successful in the vast majority
of cases, they cannot reliably indicate a server for returns or
complaints.
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.
Why do we use the term "agent", then? An agent is described
specifying how it plays client and server roles for the relevant
protocols. An agent's purpose is part of its description. Of course,
one can devise a new agent by using a mixture of already defined ones
as building blocks. Such new agent would not "be" any of its building
blocks. It should have its own name anyway.
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
