--On Saturday, June 12, 2010 15:09 +0200 Alessandro Vesely
<[email protected]> wrote:
> Hi,
> section 2.1 of the submission spec defines the three MSA, MTA,
> MUA acronyms. These definitions are often expanded for
> explaining the corresponding concepts to end users, e.g. on
> Wikipedia. IME, there is still confusion. For example, users
> tend to think that an MSA or an MTA may be included in a MUA;
> I'm not sure why.
>
> 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. 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.
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.
john
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
