Subject: [yam] RFC 4409 definitions

From: Alessandro Vesely <[email-masked]>
Date: Sat, 12 Jun 2010 15:09:39 +0200

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.

Also, is the term "split-MUA" still common? What is the term for 
clients that read from $MAIL?  (RFC 1725 removed that digression.)

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Jun 2010 12:16:26 -0400

--On Saturday, June 12, 2010 15:09 +0200 Alessandro Vesely
<[email-masked]> 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.
> 

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

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 13 Jun 2010 13:00:52 +0200

On 12/Jun/10 18:16, John C Klensin wrote:
> 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

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.

> 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

---

From: S Moonesamy <[email-masked]>
Date: Sun, 13 Jun 2010 08:36:57 -0700

Hi Alessandro,
At 06:09 12-06-10, Alessandro Vesely wrote:
>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.

Do you want me to track this as an issue?

Regards,
S. Moonesamy
WG YAM Secretary

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 13 Jun 2010 17:55:22 +0200

On 6/12/2010 3:09 PM, Alessandro Vesely wrote:
> 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.
>

With some regularity, the community suffers from redundant, vague and/or 
inconsistent definitions and even specifications, such as between the Internet 
Mail Format document and the SMTP document.  This is especially true with 
respect to the use of common terms.

So since you have raised the issue, I'll ask why these terms are not, instead, 
defined as citations to RFC 5598?

The community put quite a bit of energy and time into the terminology defined there.

Seems a shame to ignore it...

d/

ps.  There are any number of obvious ways to de-rail this question.  I'd like to 
suggest that instead the question be considered with some care.  The problem of 
wobbly terminology in our segment of the Internet technical world is serious and 
I believe it warrants efforts to get more reliable and precise use of common 
terms.  If not now, when...?

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 13 Jun 2010 18:07:17 +0200

On 6/13/2010 1:00 PM, Alessandro Vesely wrote:
> 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.

I've changed the Subject line, for some meager differentiation from the wg 
charter-related discussion that prompted this.  But I'm feeling obligated to ask 
you to elaborate.

To be pedantic and perhaps even thorough:

    1.  Can you give a very brief summary of the scenario that fetchmail 
provides that you believe needs to be covered and is not (and for what 
definition, exactly)?

    2.  What text, in particular, is wrong with respect to the case you cite, or 
what functionality needs to be covered and is not?

Thanks.

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Jun 2010 13:47:34 -0400

--On Sunday, June 13, 2010 5:55 PM +0200 Dave CROCKER
<[email-masked]> wrote:

>> section 2.1 of the submission spec defines the three MSA,
>> MTA, MUA acronyms. These definitions are often expanded for
> With some regularity, the community suffers from redundant,
> vague and/or inconsistent definitions and even specifications,
> such as between the Internet Mail Format document and the SMTP
> document.  This is especially true with respect to the use of
> common terms.
> 
> So since you have raised the issue, I'll ask why these terms
> are not, instead, defined as citations to RFC 5598?
>...

Procedurally, a normative reference from a Full Standard to a
somewhat-controversial Informational document, controversial
because it represented the views of one segment of the community
but not another?   I think that, at best, that would be an
invitation to more time-consuming controversy.

For the record, I would favor a standards-track document that
provided a standardized vocabulary/ glossary for Internet email
terminology and that everything, including a hypothetical
5598bis, referred to.    But it seems to me that 5598 is not
appropriate, precisely because it is a retrospective
architectural description and not a vocabulary.
 
  john

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 13 Jun 2010 20:03:12 +0200

On 13/Jun/10 18:07, Dave CROCKER wrote:
> I've changed the Subject line, for some meager differentiation from the
> wg charter-related discussion that prompted this. But I'm feeling
> obligated to ask you to elaborate.
>
>

I don't have strong beliefs about fetchmail's MTA-ness. Raymond used 
to hold that "Fetchmail is an MTA", which may conflict with a strict 
definition of that term.  I don't know whether the apparent retraction 
of that position in its current manual stems from reconsideration or 
wording convenience.

> 2. What text, in particular, is wrong with respect to the case you cite,
> or what functionality needs to be covered and is not?

Fetchmail changes the envelope recipient when it relays retrieved 
messages to the target MTA.  RFC 5598, section 4.3.2, says "it does 
not change addresses in the envelope", which implies fetchmail is not 
an MTA.

According to RFC 5598, fetchmail is a Mediator.  Unfortunately, that 
term isn't widely used in such technical acceptation.

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Jun 2010 14:11:56 -0400

--On Sunday, June 13, 2010 1:00 PM +0200 Alessandro Vesely
<[email-masked]> wrote:

> 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

---

From: Ned Freed <[email-masked]>
Date: Sun, 13 Jun 2010 11:19:33 -0700 (PDT)

> 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.

> of MTA, MSA, and MUA, IME.  That's why they may want to seek

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.

> formal definition either.

Again, that's because fetchmail is, for the most part, an MUA.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 13 Jun 2010 20:51:48 +0200

On 6/13/2010 8:19 PM, Ned Freed wrote:
>    The two exceptions occur ... - 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 -
...
> 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.
>
> less clear - indeed, what it means more than anything is that the
> definitions need to be kept as clean and crisp as possible

Exactly.

Architecture is an abstraction that is mapped to software according to the 
arcane organizational or personal processes of product definition.

Serious discussion about architecture is regularly derailed by confusing the 
distinction between architecture and software, even among experienced folk.

A given bit of software well might choose to provide a subset of functions from 
one architectural component and a subset from another.  (More typically, it will 
provide the core from one and some or all of the core from another.) That 
particular choices are made for particular software might provide feedback to 
the designers of the architecture, about whether they got things right or wrong. 
  It also might /not/.

Careening off of a recent private discussion, I'll offer the example of the 
early Arpanet.  The packet switches, called Interface Message Processors (IMP) 
were not "routers" in the Internet sense, but they did do packet store and 
forward and the routing to determine forwarding.  BBN added some hardware, 
memory and software to an IMP, to produce a single-box solution for sites 
needing terminal access.  (The hardware was a serial line driver).  The result, 
called a Terminal Interrface Processor (TIP) still had all of the IMP software 
and functionality /and role/.  The fact that it did more than an IMP did not 
magically make it stop being an IMP.

Nor would it suddenly become an Internet Router just because someone 
(erroneously) wrote in the documentation that it was one...

d/

-- 

   Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Sun, 13 Jun 2010 13:22:53 -0700 (PDT)

> want an even closer parallel, compare fetchmail to an MTA that suports Sieve

That should have been "MUA" in the last sentence, not MTA.

				Ned

---

From: Tony Finch <[email-masked]>
Date: Mon, 14 Jun 2010 15:28:52 +0100

On Sun, 13 Jun 2010, Alessandro Vesely wrote:
> I don't have strong beliefs about fetchmail's MTA-ness.

Fetchmail sucks messages out of a mailstore via IMAP or POP and re-injects
them using SMTP to a local MTA which it expects to do local delivery to a
local mailstore.

Microsoft Small Business Server does something similar.

> Fetchmail changes the envelope recipient when it relays retrieved messages to
> the target MTA.

Once a message has been delivered it has no envelope, so fetchmail has to
re-invent the envelope rather than rewrite it.

> According to RFC 5598, fetchmail is a Mediator.  Unfortunately, that term
> isn't widely used in such technical acceptation.

Yes.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH THAMES DOVER WIGHT: NORTHEASTERLY 4 OR 5 INCREASING 5 TO 7, OCCASIONALLY
GALE 8 IN DOVER AND WIGHT, AND PERHAPS GALE 8 LATER IN SOUTH THAMES. SLIGHT OR
MODERATE, BECOMING MODERATE OR ROUGH. SHOWERS. MAINLY GOOD.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 15 Jun 2010 01:21:03 +0200

>> isn't widely used in such technical acceptation.

Right.  But in more common parlance, it is much more like a mailing list than an 
MTA.  Perhaps a 're-mailer'.

d/

-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 15 Jun 2010 10:11:50 +0200

> both receiver (server) and sender (client) functions.

Yes, and TCP/IP nicely dresses the client/server metaphor by providing 
for listening vs. connecting sockets.

> 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.

> 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.