Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- Delivered-To: test@gmail.com
- Received: by 10.42.166.2 with SMTP id m2cs16081icy;
- Thu, 3 Mar 2011 17:01:48 -0800 (PST)
- Received: by 10.229.211.138 with SMTP id go10mr1544841qcb.195.1299200507499;
- Thu, 03 Mar 2011 17:01:47 -0800 (PST)
- Return-Path: <info@example.com>
- Received: from beta.example.com (testtest.test.com [69.123.123.123])
- by mx.google.com with ESMTP id j14si1690118qcu.136.2011.03.03.17.01.46;
- Thu, 03 Mar 2011 17:01:46 -0800 (PST)
- Received-SPF: neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of info@example.com) client-ip=69.123.123.123;
- Authentication-Results: mx.google.com; spf=neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of info@example.com) smtp.mail=info@example.com
- Received: from localhost.localdomain (localhost [127.0.0.1])
- by beta.example.com (Postfix) with ESMTP id F3C273A3EC
- for <test@gmail.com>; Fri, 4 Mar 2011 01:01:45 +0000 (UTC)
- Date: Fri, 04 Mar 2011 01:01:45 +0000
- From: info@example.com
- To: test@gmail.com
- Message-ID: <4d7039f9e9d3e_3449482ab7831658@test.mail>
- Subject: Your example account was activated.
- Mime-Version: 1.0
- Content-Type: multipart/alternative;
- boundary="--==_mimepart_4d7039f9e6967_3449482ab7831370";
- charset=UTF-8
- Content-Transfer-Encoding: 7bit
- ----==_mimepart_4d7039f9e6967_3449482ab7831370
- Date: Fri, 04 Mar 2011 01:01:45 +0000
- Mime-Version: 1.0
- Content-Type: text/html;
- charset=UTF-8
- Content-Transfer-Encoding: 7bit
- Content-ID: <4d7039f9e95ed_3449482ab7831519@test.mail>
- <html>
- <head>
- <meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
- </head>
- <body>
- <p><a href="http://example.com/"><img border="0" src="http://example.com/images/logo.png" alt="example logo" /></a></p>
- <p>Congratulations, Test!</p>
- <p>
- Your <a style="text-decoration:none;color:#ef4923;" href="http://example.com/">example</a> account was activated.
- </p>
- </body>
- </html>
- ----==_mimepart_4d7039f9e6967_3449482ab7831370
- Date: Fri, 04 Mar 2011 01:01:45 +0000
- Mime-Version: 1.0
- Content-Type: text/plain;
- charset=UTF-8
- Content-Transfer-Encoding: 7bit
- Content-ID: <4d7039f9e8b0e_3449482ab78314b7@test.mail>
- Congratulations, Test!
- Your example.com account was activated.
- ----==_mimepart_4d7039f9e6967_3449482ab7831370--
- 7.2.3 The Multipart/alternative subtype
- The multipart/alternative type is syntactically identical to multipart/mixed,
- but the semantics are different. In particular, each of the parts is an
- "alternative" version of the same information. User agents should recognize
- that the content of the various parts are interchangeable. The user agent
- should either choose the "best" type based on the user's environment and
- preferences, or offer the user the available alternatives. In general, choosing
- the best type means displaying only the LAST part that can be displayed. This
- may be used, for example, to send mail in a fancy text format in such a way
- that it can easily be displayed anywhere:
- From: Nathaniel Borenstein <nsb@bellcore.com>
- To: Ned Freed <ned@innosoft.com>
- Subject: Formatted text mail
- MIME-Version: 1.0
- Content-Type: multipart/alternative; boundary=boundary42
- --boundary42
- Content-Type: text/plain; charset=us-ascii
- ...plain text version of message goes here....
- --boundary42
- Content-Type: text/richtext
- .... richtext version of same message goes here ...
- --boundary42
- Content-Type: text/x-whatever
- .... fanciest formatted version of same message goes here
- ...
- --boundary42--
- In this example, users whose mail system understood the "text/x-whatever"
- format would see only the fancy version, while other users would see only the
- richtext or plain text version, depending on the capabilities of their system.
- In general, user agents that compose multipart/alternative entities should
- place the body parts in increasing order of preference, that is, with the
- preferred format last. For fancy text, the sending user agent should put the
- plainest format first and the richest format last. Receiving user agents should
- pick and display the last format they are capable of displaying. In the case
- where one of the alternatives is itself of type "multipart" and contains
- unrecognized sub-parts, the user agent may choose either to show that
- alternative, an earlier alternative, or both.
- NOTE: From an implementor's perspective, it might seem more sensible to reverse
- this ordering, and have the plainest alternative last. However, placing the
- plainest alternative first is the friendliest possible option when
- multipart/alternative entities are viewed using a non-MIME- compliant mail
- reader. While this approach does impose some burden on compliant mail readers,
- interoperability with older mail readers was deemed to be more important in
- this case.
- It may be the case that some user agents, if they can recognize more than one
- of the formats, will prefer to offer the user the choice of which format to
- view. This makes sense, for example, if mail includes both a nicely-formatted
- image version and an easily-edited text version. What is most critical, however,
- is that the user not automatically be shown multiple versions of the same data.
- Either the user should be shown the last recognized version or should
- explicitly be given the choice.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement