> 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].
Not really. See below.
"Fetchmail is an MTA" can still be found in
less recent descriptions[3].
The fact that someone wrote that doesn't make it correct.
IIRC, it does not act as an SMTP server,
and has no queues.
Correct, but that's really beside the point.
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.
Fetchamil is, with two exceptions, an MUA. Not an MTA, claims to the contrary
notwithstanding. It's normal use is to pull messages from an IMAP or POP
mailbox - messages that have undergone final delivery and have therefore exited
the transport infrastructure and lost their envelope, and then resubmit to the
transport infrastructure using either submit or SMTP, in the process creating a
new envelope.
This is functionally identical to my reading a message using Thunderbird and
then deciding to forward it to somebody else. The fact that fetchamil does this
without a user sitting in front of it is irrelevant - it's an MUA. (And if you
want an even closer parallel, compare fetchmail to an MTA that suports Sieve
redirect.)
The two exceptions occur when fetchmail is used with ETRN or ODMR (ATRN). In
the formder case fetchmail is simply a queue starter - it's functiona doesn't
correspdond to any of the MUA/MTA/MSA/etc. roles. In the latter case fetchmail
is acting as an MTA - it has attached itself to the transport infrastructure
and is processing messages that have not undergone final delivery and which
still have full envelopes attached.
As for whether or not it's confusing, I suppose it is, but that's hardly the
fault of the standards documents. For better or worse, someone decided to write
a program that is capable of assuming a variety of roles, some of them fairly
obscure in nature, and then the people who wrote it apperently didn't
understand how their own creation fit into the email taxonomy.
None of this makes the present definitions of the roles of email agents any
less clear - indeed, what it means more than anything is that the definitions
need to be kept as clean and crisp as possible - exactly the opposite of the
changes you appear to be proposing here.
> 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.
Again, that's because fetchmail is, for the most part, an MUA.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
