Talk:E-mail client

From Wikipedia, the free encyclopedia

This article needs a rewrite. (its also feels like it was lifted from an old textbook) Reading this you could be forgiven for thinking a client was purely a protocol layer. installed non unix systems might suggest this statement to be innacurate.

"..the various Microsoft Windows versions intended for home use never provided.." << bias, implied criticism.

"Since the various Microsoft Windows versions intended for home use never provided an MTA, most modern MUAs have to support protocols like POP3 and Internet Message Access Protocol (IMAP).." <<< I dont think there is necessarily any connection between these two assertions.

Some examples needed. A broader context would be good.

R217.205.132.234 14:52, 31 August 2006 (UTC)

I agree with the above comments, and have tagged the page for cleanup and requiring sources. I may be back to attempt to fix these issues myself later, but don't have time at the moment. JulesH 14:34, 8 December 2006 (UTC)

"An e-mail client, also called a mail user agent (MUA), .." << perhaps this is true in the world of unix ?

And in the Microsoft world also, as a quick search for 'MUA' and 'mail user agent' in the Microsoft Knowledge Base reveals. This article for instance: Article ID: 814111 (last Reviewed: February 27, 2006)

The reason being this terminology is drawn from the Request For Comments documents that are used to collaboratively discuss and formalise internet standards. Try searching RFC's using the following site: http://www.rfc-editor.org

Not Unix-centric then, but certainly standards-centric.

Tonybrown100 13:39, 31 December 2006 (UTC)

Contents

[edit] Rewrote article

I rewrote the article. It's now a stub, but I don't think it requires any cleanup now. Let me know what you think. -- Artagnon 08:45, 29 May 2007 (UTC)

Well, I have some ideas for improvement that I'll go ahead and do when I have more time. One thing I'm not sure about is the section "Mail Concept" -- you describe this as being the most common arrangement, but I'm not convinced that use an external MTA application to send the message is all that common -- my guess is the most common setup is to use SMTP directly to pass the message to a remote MTA. The section should probably also acknowledge that systems using IMAP don't need an MDA at the client end, as delivery only occurs at the server in this case. JulesH 11:18, 29 May 2007 (UTC)
Thank you for your input. We should probably describe the arrangement in a more generalised manner. You're right about external MTA not being necessary in most cases as most MUAs have them built in like mutt does. An external MTA isn't required. Nevertheless, the piece of code written into the MUA to push mail through to another MTA via SMTP is called an MTA. I'll make the 'MTA' sound less like an external requirement. I'll edit the article simultaneously in accordance with your suggestions when I have the time. --Artagnon 07:01, 31 May 2007 (UTC)

Hi, I'm very confused as to the point of email clients. Will they assist in setting up a email list, i.e allow to send an email to a particular group as in yahoo or google groups. Will a client such as GNUS help me with this?

[edit] Isn't that distinguishing too much?

IMHO, distinguishing between client and server is fair. MUA and MTA. Yes, a client has a part that is able to submit a message: all clients do. However, such client MTA don't lookup the MX record, retry in case of failure, keep a mail queue and the like. Vice versa, an MTA also has some parts that can be used to read mail or send messages, although they are not quite user friendly.

MSA, AFAIK, refers to the submission protocol at port 587. I quote RFC 4496

A client (a mail user) starts with an email client program (MUA). The user sends email to an outgoing email server. In the email server, there is an MSA (mail submission agent) that is waiting to receive email from the user. The MSA uses an MTA within the same server to forward the user email to other domains. (Communication between the MUA and MSA may be via SMTP, SUBMIT, or something else such as MAPI).

As for MRA, I got "Your search - MRA site:rfc-editor.org - did not match any documents." ale 19:26, 7 November 2007 (UTC)

From the history tab, I found out that the notion that an "MDA in conjunction with the MTA would transfer [messages] into a local mailbox" dates back to 16:53, 12 November 2005 by anonymous user 132.199.102.77. I think that is completely wrong. Conceptually, one can divide the inner working of an email client into parts that transfer, deliver, submit, and retrieve messages. However, that is not the common sense in which the acronyms MTA, MDA, MSA, and the Wikipedia-Mutt coined MRA are meant. Moreover, I know no actual email client that can use interchangeable plugins that carry out those jobs relying on the standardized interfaces. Thus, I think on my next visit I'll edit the article and relegate the possibility of such distinction in a separate paragraph, because mentioning them in the definition can be very confusing to an occasional reader. ale 18:50, 8 November 2007 (UTC)

[edit] Removed Mail concept

I indent the removed text and comment on why it is deceptive.


In a POP3 mail setup, an MRA retrieves mail from a remote mailserver.

That is deceptive, as using an MRA is not the common way to read one's mail.

That is also inexact, since an MRA (e.g. fetchmail) can retrieve mail using POP2 and IMAP4 as well. In addition, the server is obviously a POP3 server, not an SMTP server like an MTA is usually meant to be: many ISPs have POP3 servers separated from their public MTAs.


An MDA delivers that mail to a local mailbox.

That is deceptive because local means w.r.t. the MDA, which runs on the server. Since the whole article is meant from the user point of view, the mailbox is not local for users who use their own machine, unless they run their own MRA rather than letting their MUAs access the POP3 server directly: a rather unusual setup.


Finally, an MUA connects to the local mailbox and reads mail.

That is not clear. The MUA connects to a file where the MRA has delivered the mail? It would seemingly make more sense if the MUA connects to the POP3 server. Why on the earth did the user run an MRA, then?


An MSA posts the message to a nearby MTA.

Correct. However, who posted the message to the MSA?


The MTA is then called to connect to a remote MTA to send mail. <ref>[1]</ref>

Correct, if call the MTA means submit a message. Here the procedural call is deceptively used to convey the wrong impression that the body of the MTA, rather than consisting of one or more programs running on a possibly different machine, can be linked within a client.


However, note that some/ several of these components may be built into the same application. For example, most MUAs act as an MSA to submit messages to the user's ISP's SMTP server.

RFC 4409, Message Submission for Mail, defines that "The process that accepts message submissions from MUAs is termed a Message Submission Agent (MSA)." The text I removed deceptively suggests that client and server roles are interchanged.


In an IMAP mail setup, an MDA is unnecessary as the mail stays on the mailserver and is directly read from there.[2]

The reference to RFC 1064 added by 172.142.234.243 on 22:09, 9 November 2007 is inappropriate: that document does not contain any of the terms delivery agent or MDA.

About MTA, MSA, and MDA, RFC 5068 notes that "These architectural components are often compressed, such as having the same software do MSA, MTA and MDA functions": not MUA. In facts, it is the MDA that knows what kind of storage (e.g. maildir or mbox) a user's mailbox uses, and it may deliver to that storage independently of the protocol (IMAP or POP3) that the user will deploy to retrieve the mail next time he or she connects. Some servers (e.g. Courier-MTA) provide both IMAP and POP3 services. Since mail must be delivered before it can be retrieved by any of those services, and they cannot know beforehand what protocol will be used, the delivery operation must take place in the same way.

To be pedantic, an MDA is unnecessary as the mail stays on the mailserver, but it is required whenever new mail arrives.

—Preceding unsigned comment added by Ale2006 (talk • contribs) 19:21, 15 November 2007

Re: An MDA delivers that mail to a local mailbox. -- That is deceptive because local means w.r.t. the MDA, which runs on the server. Since the whole article is meant from the user point of view, the mailbox is not local for users who use their own machine, unless they run their own MRA rather than letting their MUAs access the POP3 server directly: a rather unusual setup. -- Actually, it's descriptive of a typical setup on unix systems, where there is (often) an MDA [procmail] on the user's desktop machine (not the server), that delivers to a local file that the user-agent reads. However, I've never liked that section for other reasons - some of the wording is convoluted and confusing —Random832 20:13, 15 November 2007 (UTC)

Yes, that's correct. The classical unix setting provides for users logging in on a machine where an MTA is running. And it is also deceptive that a regular client configuration installs exim on a debian notebook. (Because at requires it.) ale 09:00, 1 December 2007 (UTC)

[edit] Article describes only all-in-one email clients

It is true that many many users who bump across this article will be using an all-in-one email client. Confusing the users with terms like MRA, MUA and MTA is not a good idea, as already pointed out. For their purposes, distinguising between an MRA, MUA, MTA is not important. These are distinctions made in traditional unix and unix-like systems. This is not a historical note because, as already pointed out, a typical Debian system comes with exim installed by default. From the current revision of the article, no user can possibly understand where exim fits into the whole equation. They can never hope to understand what a true MUA such as mutt really does, much less set up mutt to send/receive his/her mail. From the point of view of Microsoft Windows users, this is possibly largely irrelevant as I know of no true MUA, MRA, MTA, MDA programs for the system.

Therefore the solution is not to eliminate all the painful explanations of how mail is really delivered, but rather put it in here or elsewhere so a new user doesn't get confused. For that, some research needs to be done to get solid sources backing up these acronyms (or whatever the correct ones might be) and some RFC articles specifying these standards. After that, we needs ideas to integrate this information somewhere so it's there but doesn't confuse a new user. My previous edit had glaring mistakes and didn't clarify enough what terms like "local" meant - I agree with that completely. Putting the old explanation back in is not an option. --Artagnon (talk) 16:54, 20 December 2007 (UTC)