2014-08-12 10:20, Brandon Long wrote:
So, if I have an "email" message, I can no longer just parse it.
Instead, there are actually two
types of email messages, and the only way to know how to parse it
is to know a priori which type it is.
Because all systems are "sealed" and there's never any leakage.
[...]
Yes. And the most obvious place for that information, to me, is in the
headers of the message. Assuming that every mechanism for exchanging
email
messages needs an explicit external piece of data...
Actually the presence of an SMTPUTF8 flag *is* reflected in the
header section of a message. It's in the WITH subfield of a
(likely topmost) Received header field (RFC 6531), as inserted
by your MX or MSA:
UTF8SMTP ESMTP with SMTPUTF8
UTF8SMTPA ESMTP with SMTPUTF8 and AUTH
UTF8SMTPS ESMTP with SMTPUTF8 and STARTTLS
UTF8SMTPSA ESMTP with SMTPUTF8 and both STARTTLS and AUTH
UTF8LMTP LMTP with SMTPUTF8
UTF8LMTPA LMTP with SMTPUTF8 and AUTH
UTF8LMTPS LMTP with SMTPUTF8 and STARTTLS
UTF8LMTPSA LMTP with SMTPUTF8 and both STARTTLS and AUTH
http://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-7
(and equivalently for LMTP)
Is there a separate three letter filename extension for 6532 messages,
for example? (for platforms which use such things).
RFC 6532:
message/global -> .u8msg
RFC 6533:
message/global-headers -> .u8hdr
message/global-delivery-status -> .u8dsn
message/global-disposition-notification -> .u8mdn
Mark
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822