Viacheslav Panikhin writes:
« HTML content follows »Sam Varshavchik writes: UTF8-content must use the UTF8 string literal to APPEND messages to a mailbox, for UTF-8 content. This error message seems to suggest that Outlook still uses the non-UTF-8 string literal but includes the UTF-8 content in it.Below is a message from the APPEND command to which the Courier displays a ALERT message. In the "From:" and "To:" fields are utf-8 content. RFC6855 allows to do this, or am I mistaken?What is wrong in the "From:" and "To:" fields?
There's nothing from with the From/To fields. The problem is not the fields, but the APPEND command itself, which must specify that the contents of the message are in UTF-8. The UTF-8 version of the APPEND command would look something like this
<token> APPEND <folder> UTF8 ( ~{n}<message> )
instead of
<token> APPEND <folder> {n}<message>
from RFC 3501.
Further technical details are in section 4 of RFC 6855.
Your packet trace apprently captured only the <message> part, but not the
preceding APPEND command.
Additionally, Outlook's choice to leave RAW UTF-8 content in mail headers will likely be problematic in other ways, even assuming it gets sent correctly. RFC-6855 only requires mail servers to deliver UTF-8 mail to other mail serves that advertise support for UTF-8, so there is no guarantee that this message will be delivered. Although it is permitted for mail server to re-code the message, if they can, they are not required to; and in fact RFC 6531 allows bouncing the message, instead:
o If it is not an MSA or is an MSA and does not choose to transform
the message to one that does not require the SMTPUTF8 extension,
it SHOULD reject the message. As usual, this can be done either
by generating an appropriate reply during the SMTP transaction or
by accepting the message and then generating and transmitting a
non-delivery notification. If the latter choice is made, the
notification process MUST conform to the requirements of RFC 5321,
RFC 3464 [RFC3464], and RFC 6533 [RFC6533].
So, presuming that I'm right about Outlook using the wrong APPEND command,
it's UTF-8 support is still quite problematic. It is using the wrong format
in APPEND, it requires not only the IMAP server but also the SMTP server to
be UTF-8 enabled, and all recipients of an E-mail message with non-encoded
headers to also use UTF-8 enabled mail servers.
This is still a poor decision, on the current Internet.
pgpp4wNhhiiPW.pgp
Description: PGP signature
_______________________________________________ Courier-imap mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
