On Fri 08/Aug/2014 01:29:39 +0200 Sam Varshavchik wrote: >> [rise in UTF-8 interest...] > > This is a big nothing-burger. > > For starters, the only thing that's needed to add SMTPUTF8 support to an > SMTP server is to advertise the SMTPUTF8 extension. Done. > > All that means is that the mail server will accept mail with headers > containing UTF-8.
Well, the envelope too. BTW, Thunderbird can send a U-label to a submission server even without the SMTPUTF8 extension. It sounds like an occasion to review DNS code. According to RFC 6531, the client must use the SMTPUTF8 parameter in the MAIL FROM command if the message requires this extension. In addition, such kind of messages should not be relayed to non-compliant servers, which introduces a new class of rejection cases. > SMTP servers do very little with mail headers. They generally ignore > them completely. Yes, up to external filters. > Courier will happily accept mail with UTF-8 headers, now that it's no > longer checking for 8-bit header content, as a spam check, and just > deliver it wherever it's supposed to go. > > That really leaves sqwebmail and courier-imap. sqwebmail will already > accept typed in recipient names, and mail headers containing non-ASCII > characters, and they will be encoded. Just need to check what will > happen if a message with UTF-8-encoded headers is going to get displayed. > > The point to SMTPUTF8 is to get rid of the encoding, but since everyone > has to support encoded headers, at this point there's little reason to > change this. Local part in email addresses shouldn't be encoded, though, since that may affect the ability of a client to adequately prepare a reply message. And convolute encoding, such as the RFC 2231 attachment file names you can get from emailsecuritycheck.net, can be happily put out to pasture. > IMAP is a sticking point, because of the IMAP client on the other end > not necessarily having the capability to handle UTF-8 headers. An IMAP > server could, in theory, recode the message in that case, but for a > number of technical reasons, that's not feasible to implement. It might be handy to have a new "no-smtputf8" per-recipient flag, so that the server can reject messages tagged SMTPUTF8 to recipients flagged that way. Ale -- ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
