Am 29.12.2013 20:23, schrieb Andrzej A. Filip: > On 12/29/2013 05:51 PM, Wietse Venema wrote: >> UTF8SMTP tried to provide a path for gradual migration but failed. >> SMPTUTF8 provides no migration path as noted above - it returns >> mail as undeliverable. Without a path for gradual migration towards >> internationalized email, I expect that SMPTUTF8 will fail, too. > > So SMPTUTF8 clients should be capable to set/choose traditional or > internationalized sender address per recipient and split sending of > multi-reipient messages?
it's hard to say how to handle this in a sane way that's why for interoperability the idea of special chars should be avoided > "where there's a will there's a way" > > I share your opinion that english speaking parts of Internet will be > slow to mass support SMTPUTF8. As native speaker of another language I > do not see it as a very important obstacle i fail how it could be helpful for anybody if as example his own MTA accepts the address and the last hop for the final destination rejects it - and that is what will happen for many many years if not virtually forever because there are *a lot* of legacy systems and that hardly will change in the near future so even if *any* SMTP software would support RFC 6531 in the last recent version this will not change the fact that as example the next RHEL7 in 2014 will be supported for *10 years* with only security updates and no functional changes forget it