On 12/Jun/10 18:16, John C Klensin wrote:
--On Saturday, June 12, 2010 15:09 +0200 Alessandro Vesely
<[email protected]> wrote:
For example, I would change
A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server
to accept messages from an MSA or another MTA, and either delivers
them or acts as an SMTP client to relay them to another MTA.
to
A process that conforms to [SMTP-MTA]. An MTA is a fully-capable
SMTP server. It accepts messages from an MSA, another MTA, or a MUA
not conforming to these specifications, and either delivers them or
acts as an SMTP client to relay them to another MTA.
I'd like this comment to be read more as a "why it is dangerous
to tamper with this stuff unless one is very careful" comment
rather than just a comment on the above suggestion but the
suggestion doesn't work.
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.
The aim of this thread is to bring to the attention of the WG that
those definitions happen to be conspicuous enough to be accessed by
end users too.
Worse, suppose we had a relay
SMTP server (in the middle of the network) whose sole function
was to accept messages and pass them across an administrative or
security boundary. In other words, its output behavior was
similar to what is now normal behavior at the MUA->MSA boundary:
all messages are forwarded, via SMTP, to a single server. Such
a server is certainly not a "fully-capable SMTP server". It
pushes the requirements of 5321 because, while it might support
MX records, it doesn't make the normal use of them. If it
speaks SMTP over TCP on both the incoming and outgoing sides, it
isn't a gateway. But I believe all of us would agree that it
is still an MTA.
Hm... I'd bet the MTA you describe actually has a queue. However, I
agree that it is "distracting" to require it for MTA rank. An edge
case example is fetchmail, whose web site says both "Fetchmail is a
mail transport agent"[1] and "fetchmail almost resembles a mail
transfer agent (MTA)"[2]. "Fetchmail is an MTA" can still be found in
less recent descriptions[3]. IIRC, it does not act as an SMTP server,
and has no queues.
My intent was merely to clarify that an MTA is not that part of an MUA
that transfers messages. End users who more or less automatically
install, say, mutt, exim, and fetchmail get confused about the roles
of MTA, MSA, and MUA, IME. That's why they may want to seek
"official" definitions.
IMO, if this sort of hairsplitting belongs anywhere at all, it
is in 5598bis, not in 4409. If nothing else, the explanations
of the terminology edge cases are just too distracting for a
protocol specification unless they are absolutely necessary for
clarity of the protocol itself.
The explanation given in RFC 5598 is much wider, but still doesn't
cover fetchmail, because of the envelope changes. It references RFC
1506 for the term "MTA". However, the latter RFC does not give a
formal definition either.
At any rate, that definition of MTA has been there since RFC 2476, so
I see no reasons to remove it from 4409bis. The current wording is
more elegant, with its symmetric treatment of client and server roles,
than it would be if it said that "an MTA _is a_ server" instead.
IMHO, the latter phrase may be clearer. But then I'm not a native
English speaker, so I don't insist.
--
[1] http://fetchmail.berlios.de/fetchmail-FAQ.html#G15
[2] http://fetchmail.berlios.de/fetchmail-man.html#4
[3]
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/s2-email-mta-fetchmail.html
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
