I need to be able to send the email programatically from with VB / ASP. But thanks for
the RFC. I figured it was something along those lines.
~Brad
---------- Original Message ----------------------------------
From: "Robert Dodd" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Jun 2001 20:50:29 -0700
You may not need an ActiveX control. Outlook Express does this automatically.
With Outlook Express and this message:
1) Click "File", "Properties"
2) Click the "Details" tab.
3) Click the "Message Source" button.
4) Scroll down to see both sections.
----- Original Message -----
From: "T. Bradley Dean" <[EMAIL PROTECTED]>
To: "Imail List" <[EMAIL PROTECTED]>
Sent: Wednesday, June 20, 2001 8:29 PM
Subject: [IMail Forum] OT: Can I borrow your non-HTML email client?
> Does anyone here use an email client that CAN NOT show HTML emails?
>
> I have a new email ActiveX control that can (supposedly) send an email with
> both a plain text and a HTML body. I want to try it out, but all my email
> clients show HTML!
>
> Thanks,
>
> ~Brad
>
*******************************************
See RFC1521. An excerpt follows:
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.
Systems should recognize that the content of the various parts are
interchangeable. Systems should choose the "best" type based on the
local environment and preferences, in some cases even through user
interaction. As with multipart/mixed, the order of body parts is
significant. In this case, the alternatives appear in an order of
increasing faithfulness to the original content. In general, the best
choice is the LAST part of a type supported by the recipient system's
local environment.
Multipart/alternative may be used, for example, to send mail in a
fancy text format in such a way that it can easily be displayed
anywhere:
Borenstein & Freed [Page 34]
--------------------------------------------------------------------------------
RFC 1521 MIME September 1993
From: Nathaniel Borenstein <[EMAIL PROTECTED]>
To: Ned Freed <[EMAIL PROTECTED]>
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
.... RFC 1341 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
must 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-conformant mail reader.
While this approach does impose some burden on conformant 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
Borenstein & Freed [Page 35]
--------------------------------------------------------------------------------
RFC 1521 MIME September 1993
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 be
given the choice.
NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each
part of a multipart/alternative entity represents the same data, but
the mappings between the two are not necessarily without information
loss. For example, information is lost when translating ODA to
PostScript or plain text. It is recommended that each part should
have a different Content-ID value in the case where the information
content of the two parts is not identical. However, where the
information content is identical -- for example, where several parts
of type "application/external- body" specify alternate ways to access
the identical data -- the same Content-ID field value should be used,
to optimize any cacheing mechanisms that might be present on the
recipient's end. However, it is recommended that the Content-ID
values used by the parts should not be the same Content-ID value that
describes the multipart/alternative as a whole, if there is any such
Content-ID field. That is, one Content-ID value will refer to the
multipart/alternative entity, while one or more other Content-ID
values will refer to the parts inside it.
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
