The Good Net-Keeping Seal of Approval describes various criteria that distinguish good-quality News User Agents. This is a similar set of criteria for Mail User Agents.
Like those of its NUA counterpart, the criteria here are not aimed at any one particular egregious MUA. Feel free to evaluate your MUAs against them. Feel free to encourage MUA authors to write good-quality softwares in light of them.
Some of these criteria apply only to MUAs for SMTP-based Internet mail, and have little to no relevance to IM2000 Internet mail MUAs.
Any discussion of these criteria should be directed to the comp.mail.misc Usenet newsgroup.
MUAs for Unix and Linux systems that support the mbox family of mailbox formats should support Rahul Dhesi's mboxrd format, instead of the older mboxo format.
The mboxrd format has a reversible encoding of message content. The mboxo format's modification of message content is not reversible. MUAs should expect mail delivery agents to have long since switched from mboxo to mboxrd by now.
MUAs for Unix and Linux systems should support the Maildir mailbox format, including (if applicable) the changes in the procedure for avoiding name collisions that were introduced in 2003.
MUAs for Unix and Linux systems that support the mbox family of mailbox formats should not attempt to mix different formats within a single mailbox.
Doing so causes message corruption. For example: "mbox" mailboxes in the mboxcl2 format are not safely readable by tools that expect the mboxo and mboxrd formats.
MUAs must document which of the "mbox" formats they are capable of handling, to allow users to prevent the admixture of MUAs and mail delivery agents that use incompatible "mbox" formats.
MUAs that spawn a process running a utility program, such as the sendmail command on Unix, to submit messages must check the exit code of the process and report any failures.
Submission utilities can fail for a variety of reasons, including resource quota exhaustion, lack of permission, or invalid data. MUAs must not simply blindly assume that submission worked simply because they were able to spawn the submission program and send the envelope and message to it.
MUAs that use SMTP to submit mail messages to the MTS should default to using an SMTP Submission service (RFC 2476) and not an SMTP Relay service (RFC 821).
When (mis)using a SMTP Relay service for mail submission, MUAs must supply the message in canonical form, with all necessary headers (including Date: and Message-ID:) and mailbox information present.
SMTP Relay services expect their clients to be other mail systems, not MUAs. Modern SMTP Relay services do not alter the messages that they recieve (apart from prepending trace information). Lazy MUAs, in turn, expect the SMTP service to which they submit mail to modify message content, in one or more of the manners outlined in RFC 2476.
It is best practice for MUAs to convert messages to canonical form, in part because in a client-server environment, in particular where the server and the client are not closely related, the necessary information for modifying mailbox names and supplying date headers is only available locally at the client and is simply unavailable at the server.
MUAs must support three forms of reply:
MUAs should determine the mailbox to use as the author of the message, in "reply to author" and "reply to all", using the value of the first, in the order given, of the following headers that exists:
MUAs should determine the mailboxes to use as the recipients of the message, in "reply to all" and "reply to list", using
MUAs must not conflate the date of submission of the message, given in the Date: header, with either the date of local delivery of the message (obtained from local mailbox information such as, in the case of Maildir mailboxes, the file creation timestamp or, in the case of mboxrd mailboxes, the From header) or the dates of any of the trace headers in the message.
Substituting the delivery date or a trace header date for the sending date causes confusion, not least because (in accordance with good practice) trace header dates are usually given in UTC whereas sending dates (being affixed by the MUA, in accordance with good practice) are given in the timezone of the sender.
MUAs should allow users to choose to view a group of messages (e.g. the contents of a folder) by thread.
When doing so, MUAs must use only the contents of the Message-ID: and References: headers to determine the thread structure.
There are other ways of choosing to display messages. MUAs may choose to display messages in the collation order of their Subject: headers, for example, or in the collation order of their Date: headers. However, neither of those headers determine what a "thread" is. The widely accepted and long-standing definition of a thread involves only the Message-ID: and References: headers.
In particular, MUAs must not join two threads into a single thread if there is no link between them other than (some of their articles) having identical Subject: headers.
Unfortunately, people are often unimaginitive in their choices of subject ("help", "unsubscribe", "digest", "urgent"), resulting in many entirely separate threads on mailing lists having the same subject. It is not useful for a new thread with an unimaginitive subject to be combined, when displayed, with all of the other threads that have used that same unimaginitive subject.
MUAs should allow the user to navigate from the currently displayed message back along the chain of referenced messages.
MUAs should allow the user to navigate directly to a given message by supplying its message ID.
MUAs must use the value in the Content-Type: header for determining how to display a message, and must not use the value of any supplied "name" or "filename" of the body part for this purpose.
One famous error in an MUA allowed executable programs to be run automatically by simply sending them as audio/* body parts. The MUA would attempt to "open" the audio body part when the message was displayed (allowing messages to have "background sounds"), but having determined that the body part was a sound would then proceed to forget that information entirely and instead use the "extension" portion of the supplied filename to determine how to actually "run" the data. The filename would, of course, have the extension that indicated that it was an ordinary executable program image. Senders thereby had the means to cause a program of their choosing to be automatically executed on recipient systems when a message was displayed.
When displaying messages, MUAs must display at least the following information from the message headers:
MUAs must provide a scrolling mechanism of an appropriate sort if the information to be displayed is too large for the user interface to display all at once.
MUAs must provide a mechanism for recipients to display all header information.
MUAs may provide a mechanism for recipients to explicitly command that header information be hidden.
MUAs should not attempt to heuristically recognise "attachments" that are not encapsulated as actual MIME body parts.
Heuristics are unreliable. This is partly why MIME was invented in the first place, after all.
One famous error in an MUA that attempts to detect UUencoded files in such a fashion causes any lines following a line that begins with the word "begin" and two spaces to be hidden from the user.
MUAs must not attempt to recognise the ordinary data of a body part as MIME encoding.
One famous error in an MUA causes it to attempt to decode as MIME any part of a textual body part that resembles a message/rfc822 body part. This provides a covert channel for malicious attackers to sneak undesirable body parts past message scanning tools.
MUAs must not automatically fetch content from external sources, rather than from the message data themselves, when displaying messages. Content display engines must be properly "sandboxed". Fetching of external content must be done only at the explicit command of the reader, separate to the command to display the message.
A common attack is to use external references to images, style sheets, and frames to track, by encoding the recipient mailbox name in the URL used to fetch the external content, what recipients have actually viewed (as opposed to just downloaded) a message. These are known as "web bugs".
Note: This restriction applies to any content type where external references to content can be embedded within the message under the control of the message sender, and not solely to text/html.
MUAs must require that the user explicitly specify, either interactively via a prompt or as part of the command, the filename to use when saving a body part or an entire message to file.
MUAs may use the supplied "name" or "filename" of the body part as the default when presenting the prompt, but should remove any directory prefix information from it before doing so.
MUAs must allow users, at any point during message composition, to view and to change the values of the following headers:
It is unacceptable for users to be unable to correctly adjust the subject to match the actual message content, to specify alternate personal reply destinations, to specify alternate list reply destinations, or to alter the list of recipients, because the software does not permit them to do so.
MUAs may present a user interface that allows the "logical" content of these headers to be changed, without necessarily allowing the raw "physical" content of the headers to be directly manipulated.
MUAs should provide users with the ability to view and to change the values of other headers.
MUAs must detect the absence of a Subject: when the user attempts to submit a message, and should prompt the user to enter a subject.
MUAs must not create "default" subjects such as "(empty)", "(no subject)", or "(unknown)" in the absence of user-supplied subject information, and should not supply such strings as the defaults when prompting for a subject.
When constructing the initial template for a reply MUAs should use the Subject: of the message being replied to, without alteration, as the subject.
MUAs should not follow the deprecated practice of using, when constructing the initial template for a reply, the Subject: of the message being replied to, with a string prepended to it, as the subject. MUAs that nonetheless do so
The practice of prepending "Re: " to the subjects is simply another instance of the general case error of wanting to stuff into the subject (or into the body) of the message a copy of information that is already provided in a header explicitly designed for the purpose. This is just unnecessary duplication, and imposition of structure and program-supplied content on what is intended to be an unstructured field containing user-supplied content. It is a needless duplication of the information that is already provided by the presence of a References: header. It is also inherently ambiguous, since there is no way to determine whether a "Re: " string at the start of the subject of a message is the result of a user accepting the default subject or is the result of a user explicitly supplying that particular string. (It is thus impossible for an MUA to reliably determine whether another MUA has already automatically prepended "Re: ".)
This unnecessary and flawed practice should be eliminated.
Where that hasn't yet happened, constraints are added:
The "Re: Re: Re: Re: " absurdity is avoided by the long-standing, but also quite unreliable (because it is liable to false positives on user-supplied content - e.g. "Re: is a Latin phrase used in correspondence"), heuristic of attempting to determine where another MUA has already automatically prepended "Re: ".
Foolish attempts to "internationalize" the prefix (which is a Latin word, not an English one, note, and is not an abbreviation) would lead to the situation where either subject lines turn into complete messes ("Re: Sv: Antwort: Re[2]: ") or every NUA and MUA has to know all of the possible variations on "Re: " employed by every software in every country throughout the world (which is clearly impracticable). They are thus prohibited.
MUAs should provide a mechanism allowing users to designate which mailboxes are really mailing lists to which the user is subscribed for reading.
MUAs should alert the user, when displaying a message or composing a reply to it via a "reply to all" or "reply to list" command, if the Mail-Followup-To: header contains neither the user's mailbox name nor any designated mailing list mailbox names.
In this situation, either the user has failed to inform the MUA of a mailing list mailbox name or the author of the message is redirecting discussion to a place where the user will not see it.
MUAs may create the initial value of the Mail-Followup-To: header, when composing a message, in the following manner:
MUAs that create an initial Mail-Followup-To: header should provide a mechanism for any changes that the user makes to the To:, Cc:, and Bcc: headers to be mirrored in the Mail-Followup-To: header. MUAs that do not provide such functionality should not create an initial Mail-Followup-To: header.
One possible user interface design would be to provide a "logical" interface to specifying recipient mailboxes, allowing the user to provide a list of mailbox names and for each entry on the list checkboxes specifying how the mailbox name is to be used (e.g. "Include this in To:", "Include this in the envelope", "Include this in Mail-Followup-To:", and so forth).
MUAs should create the final value of the Mail-Followup-To: header, when submitting a message, in the following manner:
When creating a text/html body part, MUAs must not automatically create an equivalent text/plain body part and combine the two within a multipart/alternative body part (although the user may explicitly command this to happen for individual messages).
MUAs are expected to be able to display text/html as if it were text/plain. As RFC 1521 statesAn interesting characteristic of many such extended text representations is that they are to some extent readable even without the software that interprets them.andIn the absence of appropriate interpretation software, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most nontextual data.
MUAs must, when composing replies, add References: headers to those replies, constructed in the manner described in RFC 1036 section 2.2.5.
MUAs should not truncate References: headers unnecessarily, and must not truncate References: headers headers except by removing a contiguous sequence of one or more message IDs from the beginning of the list.
MUAs that perform implicit word wrapping (of text bodyparts) at the end of message composition but before submission must provide the user with a means for determining, during message composition, where such word wrap will occur. If the message composition user interface performs word wrapping when displaying the message during composition, that word wrapping must match the word wrapping that will occur at the point of submission.
Users must not compose messages that they believe, based upon what the composition user interface displays to them, to be formatted in one manner, only to be surprised by the action of automatic word wrapping, and have their messages formatted in a different manner that was not intended, at the point of message submission.
MUAs must not insert large amounts of quoted material into reply messages in ways that encourage users to leave it unedited.
Typical errors are to quote a message in its entirety, and then position the initial caret in the composition interface such that the quoted material and its size are hidden from view.
MUAs should draw the user's attention to the presence of large amounts of quoted material during composition and at the point of submission, and must provide the user with the ability to remove that material once his/her attention has been drawn to it.
MUAs must not derive either
The three are conceptually distinct.
- The domain name portion of the sender mailbox name denotes where the sender's recipient mailbox is.
- The domain name portion of message IDs denotes the authority under which message IDs are generated, within whose scope all local parts are unique.
- The argument to the HELO/EHLO command has no applicability to MUAs and message submission.
One common MUA error is to use the sender mailbox domain name as the argument to the HELO/EHLO command, and to mis-use SMTP Relay service for message submission, resulting in SMTP Relay servers that still employ the original (but obsolete) SMTP loop detection mechanism believing that they are erroneously talking to themselves if the sender mailbox domain name happens to match a name that the SMTP Relay server believes is its own.
MUAs must provide mechanisms for users to independently and explicitly specify the argument to the HELO/EHLO command and the domain name portion of message IDs. MUAs may use a globally unique name of the machine on which the MUA is running as a default for both.
localhost. is not a globally unique name. Neither is the machine's "LAN" name.
MUAs must not use the HELO command when submitting a message via SMTP, and should not use the EHLO command unless they actually wish to negotiate protocol extensions.