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
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822