Am 10.12.2013 15:18, schrieb LuKreme: > In our previous episode (Monday, 09-Dec-2013), "li...@rhsoft.net" said: >> * the local part must not contain special chars > > Is that your policy or are you claiming that is a standard?
it is fact > RFC 6530 covers UTF-8 email addresses and how they should be handled my MTAs. fine, read it, how does this affect the current world? http://www.rfc-editor.org/info/rfc6530 Status: PROPOSED STANDARD IETF State: WG Document Consensus: Unknown http://datatracker.ietf.org/doc/rfc6530/?include_text=1 _________________________________ in order to use internationalized email addresses, it is necessary to internationalize both the domain part and the local part of email addresses. The domain part of email addresses is already internationalized [RFC5890], while the local part is not. Without the extensions specified in this document, the mailbox name is restricted to a subset of 7-bit ASCII [RFC5321] Though MIME [RFC2045] enables the transport of non-ASCII data, it does not provide a mechanism for internationalized email addresses. In RFC 2047 [RFC2047], MIME defines an encoding mechanism for some specific message header fields to accommodate non-ASCII data. However, it does not permit the use of email addresses that include non-ASCII characters. Without the extensions defined here, or some equivalent set, the only way to incorporate non-ASCII characters in any part of email addresses is to use RFC 2047 coding to embed them in what RFC 5322 [RFC5322] calls the "display name" (known as a "name phrase" or by other terms elsewhere) of the relevant header fields. Information coded into the display name is invisible in the message envelope and, for many purposes, is not part of the address at all.
