John Fawcett:
> On 27/01/11 13:19, Wietse Venema wrote:
> > John Fawcett:
> >
> >> Claudio
> >> the problem is happening because your column definition for "domain"
> >> column has character set latin1 (which by default has collation
> >> latin_swedish_ci) and the data being passed from postfix is in utf8
> >> (which by default has collation utf8_general_ci).
> >>
> > Actually, there is no legitimate character set for non-ASCII SMTP
> > commands. There is an RFC for UTF8 SMTP, but is not implemented
> > on any significant scale at this time. It creates major headaches
> > for envelope and content inspection, with non-identity MIME encoding
> > and with alternate email addresses.
> >
> > Wietse
> >
> In RFC5336 the server advertises availability of non-ascii in smtp
> commands (UTF8SMTP keyword in EHLO response), but I do not see an
> explicit way of identifying if a client wishes to use the extension,
> except maybe for the ALT-ADDRESS parameter but that is optional.
Actually, ALT-ADDRESS, AUTH, DSN, STARTTLS and so on are not valid
SMTP commands and will result in command syntax errors with 100%
compliant implementations of the latest RFC for the SMTP protocol.
The client can send UTF8 SMTP etc. commands ONLY after the SMTP
SERVER announces support for the UTF8 SMTP etc. extension.
> If UTF8SMTP support is introduced in Postfix, what rules should Postfix
> follow for interpreting email addresses? That if there is at least one
> non-ascii character, the string is treated as utf8 else it is treated as
> ascii? What demands does that place on all the dictionary back ends?
All strings will be processed as UTF-8 text. This encoding is 100%
upwards compatible with ASCIIZ text.
Wietse
