Re: utf8 messages
Daniel Vargha <[email protected]> Wed, 13 Aug 2014 19:07:09 +0000
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <D011732C.19684%[email protected]> |
--===============1533947222704467338==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_D011732C19684dvarghamimecastcom_"
--_000_D011732C19684dvarghamimecastcom_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Daniel Vargha wrote:
> I fully agree with Brandon, the standard SHOULD consider the use case
> when a
> message is transferred from one system to another as a blob (e.g. flat
> file) and
> the only available "metadata" is that the message is in MIME format.
> Having
> some sort of well defined UTF8 indicator in the header section of the
> message
> would make it much simpler to adopt the new standard as it would
> require
> substantially less development effort in most cases.
It is not possible (even in the absence of SMTPUTF8 support) to be
able to transfer e-mail messages with no out-of-band ("metadata" /
envelope) information. The most obvious reason is the list of
recipient addresses, which is not present in a message itself.
Envelope sender may or may not be present in a mail header
(as a Return-Path header field). Other examples are RFC 3461 data
(RET, ENVID, NOTIFY, ORCPT). The SMTPUTF8 flag is just one more of
such out-of-band pieces of information necessary for mail transmission.
It is possible and it is happening to millions of messages every day.
A message is sitting in an archive store, the user exports it to an .EML
file and then imports the file into another archive system. The
destination system needs to parse the message for indexing in order
to make it searchable. Quite often a message goes through this
export/import process several times during it's life time.
Another example where it is assumed that a MIME message is self
contained and allows parsing without additional metadata is the
MBOX format (http://en.wikipedia.org/wiki/Mbox)
Daniel
--_000_D011732C19684dvarghamimecastcom_
Content-Type: text/html; charset=WINDOWS-1252
Content-ID: <[email protected]>
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<span id=3D"OLK_SRC_BODY_SECTION">
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:=
#b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<br>
Daniel Vargha wrote:<br>
> I fully agree with Brandon, the standard SHOULD consider the use case =
<br>
> when a<br>
> message is transferred from one system to another as a blob (e.g. flat=
<br>
> file) and<br>
> the only available "metadata" is that the message is in MIME=
format. <br>
> Having<br>
> some sort of well defined UTF8 indicator in the header section of the =
<br>
> message<br>
> would make it much simpler to adopt the new standard as it would <br>
> require<br>
> substantially less development effort in most cases.<br>
<br>
It is not possible (even in the absence of SMTPUTF8 support) to be<br>
able to transfer e-mail messages with no out-of-band ("metadata" =
/<br>
envelope) information. The most obvious reason is the list of<br>
recipient addresses, which is not present in a message itself.<br>
Envelope sender may or may not be present in a mail header<br>
(as a Return-Path header field). Other examples are RFC 3461 data<br>
(RET, ENVID, NOTIFY, ORCPT). The SMTPUTF8 flag is just one more of<br>
such out-of-band pieces of information necessary for mail transmission.<br>
</blockquote>
</span>
<div><br>
</div>
<div>It is possible and it is happening to millions of messages every day.&=
nbsp;</div>
<div>A message is sitting in an archive store, the user exports it to =
an .EML </div>
<div>file and then imports the file into another archive system. The&n=
bsp;</div>
<div>destination system needs to parse the message for indexing in ord=
er </div>
<div>to make it searchable. Quite often a message goes through th=
is</div>
<div>export/import process several times during it's life time.</div>
<div><br>
</div>
<div>Another example where it is assumed that a MIME message is s=
elf </div>
<div>contained and allows parsing without additional metadata is the&n=
bsp;</div>
<div>MBOX format (<a href=3D"http://en.wikipedia.org/wiki/Mbox">http://en.w=
ikipedia.org/wiki/Mbox</a>)</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>Daniel</div>
</span>
</body>
</html>
--_000_D011732C19684dvarghamimecastcom_--
--===============1533947222704467338==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822
--===============1533947222704467338==--