Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
International email addresses (RFC 6531)
395 views
Skip to first unread message
Freek Dijkstra
Dec 29, 2013, 8:13:51 AM12/29/13
to
Hi all,
Postfix does not support international email addresses, such as
jos�@example.org, as described by RFC 6530-6532. To be precise, the
SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
EHLO response.
Wikipedia [1] says it is "under development", but given the response to
the topic "Question about supporting EAI in postfix" about a year ago
[2] I get the impression it is not.
Would anybody be aware of external contributions to Postfix for this
feature? I have not found anything on the web.
Regards,
Freek
[1] https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
[2] http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286
Postfix does not support international email addresses, such as
jos�@example.org, as described by RFC 6530-6532. To be precise, the
SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
EHLO response.
Wikipedia [1] says it is "under development", but given the response to
the topic "Question about supporting EAI in postfix" about a year ago
[2] I get the impression it is not.
Would anybody be aware of external contributions to Postfix for this
feature? I have not found anything on the web.
Regards,
Freek
[1] https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
[2] http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286
li...@rhsoft.net
Dec 29, 2013, 8:26:24 AM12/29/13
to
Am 29.12.2013 14:13, schrieb Freek Dijkstra:
> Postfix does not support international email addresses, such as
> jos�@example.org, as described by RFC 6530-6532. To be precise, the
> SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
> EHLO response.
>
> Wikipedia [1] says it is "under development", but given the response to
> the topic "Question about supporting EAI in postfix" about a year ago
> [2] I get the impression it is not.
>
> Would anybody be aware of external contributions to Postfix for this
> feature? I have not found anything on the web.
>
> Postfix does not support international email addresses, such as
> jos�@example.org, as described by RFC 6530-6532. To be precise, the
> SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
> EHLO response.
>
> Wikipedia [1] says it is "under development", but given the response to
> the topic "Question about supporting EAI in postfix" about a year ago
> [2] I get the impression it is not.
>
> Would anybody be aware of external contributions to Postfix for this
> feature? I have not found anything on the web.
>
> [1] https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
> [2] http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286
and even if postfix supports it you gain nothing for a lot of reasons
> [2] http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286
* not everybody is using postfix
* not everybody using postfix is using the latest version
* not all other mailservers supports it
* no all other software verify addresses and filter mails supports it
* any *involved* machine from sender to final RCPT need to support it 100%
hence forget this broken idea for the next at least 5 years
Wietse Venema
Dec 29, 2013, 11:51:33 AM12/29/13
to
Freek Dijkstra:
> Hi all,
SMPTUTF8 sender address to a non-SMPTUTF8 MTA. It must return such
email as undeliverable. See sections 8 and 9.
In other words, email with your "international" sender address will
be undeliverable to vast portions of the Internet. Is that what you
want?
And that is just one problem with SMPTUTF8.
Earlier Internet email extensions such as MIME were careful to
maintain interoperability with existing infrastructure, providing
a path for gradual migration from the present to the future.
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.
Wietse
> Hi all,
>
> Postfix does not support international email addresses, such as
> jos?@example.org, as described by RFC 6530-6532. To be precise, the
> Postfix does not support international email addresses, such as
> SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
> EHLO response.
>
> Wikipedia [1] says it is "under development", but given the response to
> the topic "Question about supporting EAI in postfix" about a year ago
> [2] I get the impression it is not.
>
> Would anybody be aware of external contributions to Postfix for this
> feature? I have not found anything on the web.
With RFC 6530 an SMPTUTF8-capable MTA can't forward email with an
> EHLO response.
>
> Wikipedia [1] says it is "under development", but given the response to
> the topic "Question about supporting EAI in postfix" about a year ago
> [2] I get the impression it is not.
>
> Would anybody be aware of external contributions to Postfix for this
> feature? I have not found anything on the web.
SMPTUTF8 sender address to a non-SMPTUTF8 MTA. It must return such
email as undeliverable. See sections 8 and 9.
In other words, email with your "international" sender address will
be undeliverable to vast portions of the Internet. Is that what you
want?
And that is just one problem with SMPTUTF8.
Earlier Internet email extensions such as MIME were careful to
maintain interoperability with existing infrastructure, providing
a path for gradual migration from the present to the future.
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.
Wietse
Andrzej A. Filip
Dec 29, 2013, 2:23:39 PM12/29/13
to
internationalized sender address per recipient and split sending of
multi-reipient messages?
"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.
li...@rhsoft.net
Dec 29, 2013, 2:36:10 PM12/29/13
to
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?
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
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
Wietse Venema
Dec 29, 2013, 3:12:40 PM12/29/13
to
Andrzej A. Filip:
format, and now they have to send it again in a different format.
They will just stop using email and do their correspondence on a
properietary platform (facebook, and the like).
Wietse
> > 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?
>
> > 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?
>
> "where there's a will there's a way"
Try to explain to your parents that they sent email in the wrong
format, and now they have to send it again in a different format.
They will just stop using email and do their correspondence on a
properietary platform (facebook, and the like).
Wietse
Freek Dijkstra
Dec 29, 2013, 4:12:44 PM12/29/13
to
Hi Wietse, et al.,
Thank you for your explanation. I now understand that you do not have
any plans on supporting this feature due to interoperability concerns.
Would you be willing to accept external patches to add RFC 6531
functionality?
(Admittedly, this is a bit of an academic question -- I'm starting to
see some IDNs in email, and wanted to find out the status of
international email addresses in general. I now have that answer.)
I didn't intent to start a discussion if RFC 6531 is good or bad, but
now that we have that discussion, here are my two cents.
While I perfectly understand that other features are more important to
implement, I'm a bit surprised by the rather strong opinion voiced on
this list against this feature. Personally, I rather see UTF-8 encoded
mail headers than HTML-encoded mail bodies. ;).
> In other words, email with your "international" sender address will
> be undeliverable to vast portions of the Internet. Is that what you
> want?
Personally, I wouldn't recommend anyone to start creating email
addresses with non-ASCII characters in the local part (the domain name
part is fine), precisely for the incompatibility reasons you cite.
However, on the off-chance that someone else creates such mail
addresses, now that it is a IETF proposed standard (as opposed to RFC
5336, which was 'only' experimental), I would hate to see that Postfix,
my favorite MTA, would be the one that causes the bounce because it is
incapable of handling such address.
Regards,
Freek
Thank you for your explanation. I now understand that you do not have
any plans on supporting this feature due to interoperability concerns.
Would you be willing to accept external patches to add RFC 6531
functionality?
(Admittedly, this is a bit of an academic question -- I'm starting to
see some IDNs in email, and wanted to find out the status of
international email addresses in general. I now have that answer.)
I didn't intent to start a discussion if RFC 6531 is good or bad, but
now that we have that discussion, here are my two cents.
While I perfectly understand that other features are more important to
implement, I'm a bit surprised by the rather strong opinion voiced on
this list against this feature. Personally, I rather see UTF-8 encoded
mail headers than HTML-encoded mail bodies. ;).
> In other words, email with your "international" sender address will
> be undeliverable to vast portions of the Internet. Is that what you
> want?
addresses with non-ASCII characters in the local part (the domain name
part is fine), precisely for the incompatibility reasons you cite.
However, on the off-chance that someone else creates such mail
addresses, now that it is a IETF proposed standard (as opposed to RFC
5336, which was 'only' experimental), I would hate to see that Postfix,
my favorite MTA, would be the one that causes the bounce because it is
incapable of handling such address.
Regards,
Freek
Wietse Venema
Dec 29, 2013, 4:51:02 PM12/29/13
to
Freek Dijkstra:
clever person will come up with a tweak to the proposed protocols
that avoids the need to bounce email with a non-ASCII sender (or
non-ASCII whatever).
> Would you be willing to accept external patches to add RFC 6531
> functionality?
RFC 6531 is about announcing SMTPUTF8 support in SMTP. That
is 1% of all the work that is needed to implement SMTPUTF8.
In order to announce SMTPUTF8 support, the other 99% must be done
first. To correctly processes SMTPUTF8 requires changes to address
manipulation, MIME support, delivery status notifications, delivery
agents (can't just blindly pass UTF8 into shell command lines),
and returning mail as undeliverable when the next MTA does not
announce SMTPUTF8 support.
The way I read your proposal is that Postfix would only pretend
that it supports SMTPUTF8, without doing the 99% of the work.
Wietse
> Hi Wietse, et al.,
>
> Thank you for your explanation. I now understand that you do not have
> any plans on supporting this feature due to interoperability concerns.
That understanding is not necessarily correct. I hope that some
>
> Thank you for your explanation. I now understand that you do not have
> any plans on supporting this feature due to interoperability concerns.
clever person will come up with a tweak to the proposed protocols
that avoids the need to bounce email with a non-ASCII sender (or
non-ASCII whatever).
> Would you be willing to accept external patches to add RFC 6531
> functionality?
is 1% of all the work that is needed to implement SMTPUTF8.
In order to announce SMTPUTF8 support, the other 99% must be done
first. To correctly processes SMTPUTF8 requires changes to address
manipulation, MIME support, delivery status notifications, delivery
agents (can't just blindly pass UTF8 into shell command lines),
and returning mail as undeliverable when the next MTA does not
announce SMTPUTF8 support.
The way I read your proposal is that Postfix would only pretend
that it supports SMTPUTF8, without doing the 99% of the work.
Wietse
Freek Dijkstra
Dec 29, 2013, 6:18:36 PM12/29/13
to
On 29-12-2013 22:51, Wietse Venema wrote:
> I hope that some
> clever person will come up with a tweak to the proposed protocols
> that avoids the need to bounce email with a non-ASCII sender (or
> non-ASCII whatever).
RFC 6530 sect 8 seems to suggest that RFC 2047 (MIME Message Header
> I hope that some
> clever person will come up with a tweak to the proposed protocols
> that avoids the need to bounce email with a non-ASCII sender (or
> non-ASCII whatever).
Extensions for Non-ASCII Text) could be used, but that is only mentioned
as one possibility.
I fear I won't be that clever person. I'm still struggling to understand
these four RFCs.
> The way I read your proposal is that Postfix would only pretend
That would of course be ludicrous, and it never occurred to me that my
original email could be interpreted that way. I apologize for the confusion.
FYI, I did test a international email in the virtual alias map on a
production machine (running a rather old Postfix 2.7.1). It arrived
without problems. The spam filter balked at the non-conformant mail
headers, but that was all. I was very impressed.
I understand that this functionality is just a tip of the iceberg. I had
thought about how this effectively changes the API interface to other
mail components (such as spam filters, or procmail-like delivery tools)
which may now expect ASCII-encoded input. Your list is clearly a lot
longer than that.
Freek
Wietse Venema
Dec 29, 2013, 10:09:12 PM12/29/13
to
Freek Dijkstra:
do SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs
that need to be supported first.
Wietse
> > The way I read your proposal is that Postfix would only pretend
> > that it supporMts SMTPUTF8, without doing the 99% of the work.
>
> That would of course be ludicrous, and it never occurred to me that my
> original email could be interpreted that way. I apologize for the confusion.
...
> > that it supporMts SMTPUTF8, without doing the 99% of the work.
>
> That would of course be ludicrous, and it never occurred to me that my
> original email could be interpreted that way. I apologize for the confusion.
> I understand that this functionality is just a tip of the iceberg. I had
> thought about how this effectively changes the API interface to other
> mail components (such as spam filters, or procmail-like delivery tools)
> which may now expect ASCII-encoded input. Your list is clearly a lot
> longer than that.
Indeed. SMTPUTF8 support involves more than the 1% that says "I can
> thought about how this effectively changes the API interface to other
> mail components (such as spam filters, or procmail-like delivery tools)
> which may now expect ASCII-encoded input. Your list is clearly a lot
> longer than that.
do SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs
that need to be supported first.
Wietse
Viktor Dukhovni
Dec 29, 2013, 10:55:47 PM12/29/13
to
On Sun, Dec 29, 2013 at 10:09:12PM -0500, Wietse Venema wrote:
> Indeed. SMTPUTF8 support involves more than the 1% that says "I can
> do SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs
> that need to be supported first.
I think the RFCs in question are a mistake. A far simpler and
> Indeed. SMTPUTF8 support involves more than the 1% that says "I can
> do SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs
> that need to be supported first.
cleaner design would have been to extend Punycode to the local part
of the address. For some reason the IETF working group did not
choose the approach with the simplest migration path. There are
other IETF RFCs that never get much adoption, I hope and expect
that these will be among them.
--
Viktor.
Andrzej A. Filip
Dec 30, 2013, 3:07:59 AM12/30/13
to
ASCII" charsets (ISO-8859-X) but it may create (too) long names for
"completely non ASCII charsets".
There is as always conflict between short term ease of transition and
long term simplicity.
Luigi Rosa
Dec 30, 2013, 3:25:47 AM12/30/13
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Viktor Dukhovni said the following on 30/12/2013 04:55:
>> Indeed. SMTPUTF8 support involves more than the 1% that says "I can do
>> SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs that need
>> to be supported first.
>
> I think the RFCs in question are a mistake. A far simpler and cleaner
> design would have been to extend Punycode to the local part of the address.
>
Agreed.
Why not use the same algorithm used by IDNA (RFC3490)? There are already an
adopted RFC and a working algorithm, why reinvent the wheel?
Otherwise we could end up with an email address whit a local part encoded with
algorithm A and a domain name encoded with algorithm B.
Ciao,
luigi
- --
/
+--[Luigi Rosa]--
\
Law of the Perversity of Nature: You cannot successfully determine
beforehand which side of the bread to butter.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLBLgYACgkQ3kWu7Tfl6ZSNhwCeMBQLUYSF3+mtCqkOFMddo87Y
a8EAoLhlakYzz1Epxb1RiPlE0caQ9o/z
=0air
-----END PGP SIGNATURE-----
Hash: SHA1
Viktor Dukhovni said the following on 30/12/2013 04:55:
>> Indeed. SMTPUTF8 support involves more than the 1% that says "I can do
>> SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs that need
>> to be supported first.
>
> I think the RFCs in question are a mistake. A far simpler and cleaner
> design would have been to extend Punycode to the local part of the address.
>
Why not use the same algorithm used by IDNA (RFC3490)? There are already an
adopted RFC and a working algorithm, why reinvent the wheel?
Otherwise we could end up with an email address whit a local part encoded with
algorithm A and a domain name encoded with algorithm B.
Ciao,
luigi
- --
/
+--[Luigi Rosa]--
\
Law of the Perversity of Nature: You cannot successfully determine
beforehand which side of the bread to butter.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLBLgYACgkQ3kWu7Tfl6ZSNhwCeMBQLUYSF3+mtCqkOFMddo87Y
a8EAoLhlakYzz1Epxb1RiPlE0caQ9o/z
=0air
-----END PGP SIGNATURE-----
Andreas Kasenides
Dec 30, 2013, 4:03:05 AM12/30/13
to
On 29-12-2013 22:05, lst_...@kwsoft.de wrote:
> Zitat von Freek Dijkstra <pub...@macfreek.nl>:
>> Freek
> in whatever charset you should use the real name in the header
> section.
>
> Regards
>
> Andreas
My opinion (slightly off topic but very relevant) having read the thread
carefully:
It is obvious that the English speaking world does not want to abandon
ASCII. For their own reasons.
If you want an RFC (or any project for that matter) to fail then create
an impossible situation
ie no path from the existing status-quo to the new system. The arguments
put forward, by some, are exactly
the same for IPv6. But then the path from IPv4 to IPv6 is well charted
out and understood. Software
have been built long ago when nobody was using IPv6. Incompatibilities
corrected and applications and or
drivers created for several generation now. Still IPv6 is not that
common.
Come to think of it, why don't we go back to using inches, yards, miles
and pounds?
It was, and still is, quite painful converting to SI.
Andreas
> Zitat von Freek Dijkstra <pub...@macfreek.nl>:
>
>> Hi all,
>>
>> Postfix does not support international email addresses, such as
>> josé@example.org, as described by RFC 6530-6532. To be precise, the
>> Hi all,
>>
>> Postfix does not support international email addresses, such as
>> SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
>> EHLO response.
>>
>> Wikipedia [1] says it is "under development", but given the response
>> to
>> the topic "Question about supporting EAI in postfix" about a year ago
>> [2] I get the impression it is not.
>>
>> Would anybody be aware of external contributions to Postfix for this
>> feature? I have not found anything on the web.
>>
>> Regards,
>> EHLO response.
>>
>> Wikipedia [1] says it is "under development", but given the response
>> to
>> the topic "Question about supporting EAI in postfix" about a year ago
>> [2] I get the impression it is not.
>>
>> Would anybody be aware of external contributions to Postfix for this
>> feature? I have not found anything on the web.
>>
>> Freek
>>
>> [1] https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
>> [2]
>> http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286
>
> IMHO The e-Mail address is just a "routeable" name. For your real name
>> [1] https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
>> [2]
>> http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286
>
> in whatever charset you should use the real name in the header
> section.
>
> Regards
>
> Andreas
My opinion (slightly off topic but very relevant) having read the thread
carefully:
It is obvious that the English speaking world does not want to abandon
ASCII. For their own reasons.
If you want an RFC (or any project for that matter) to fail then create
an impossible situation
ie no path from the existing status-quo to the new system. The arguments
put forward, by some, are exactly
the same for IPv6. But then the path from IPv4 to IPv6 is well charted
out and understood. Software
have been built long ago when nobody was using IPv6. Incompatibilities
corrected and applications and or
drivers created for several generation now. Still IPv6 is not that
common.
Come to think of it, why don't we go back to using inches, yards, miles
and pounds?
It was, and still is, quite painful converting to SI.
Andreas
Wietse Venema
Dec 30, 2013, 7:10:26 AM12/30/13
to
Andrzej A. Filip:
systems that don't support non-ASCII addresses. Just like MIME
8-7bit conversion, the need for it goes away over time.
Wietse
> On 12/30/2013 04:55 AM, Viktor Dukhovni wrote:
> > On Sun, Dec 29, 2013 at 10:09:12PM -0500, Wietse Venema wrote:
> >
> > On Sun, Dec 29, 2013 at 10:09:12PM -0500, Wietse Venema wrote:
> >
> >> Indeed. SMTPUTF8 support involves more than the 1% that says "I can
> >> do SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs
> >> that need to be supported first.
> >
> > I think the RFCs in question are a mistake. A far simpler and
> > cleaner design would have been to extend Punycode to the local part
> >> do SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs
> >> that need to be supported first.
> >
> > I think the RFCs in question are a mistake. A far simpler and
> > cleaner design would have been to extend Punycode to the local part
> > of the address. For some reason the IETF working group did not
> > choose the approach with the simplest migration path. There are
> > other IETF RFCs that never get much adoption, I hope and expect
> > that these will be among them.
>
> IMHO Extending punycode to local part may be a good option for "mostly
> ASCII" charsets (ISO-8859-X) but it may create (too) long names for
> "completely non ASCII charsets".
This transformation would be needed only when sending mail between
> > choose the approach with the simplest migration path. There are
> > other IETF RFCs that never get much adoption, I hope and expect
> > that these will be among them.
>
> IMHO Extending punycode to local part may be a good option for "mostly
> ASCII" charsets (ISO-8859-X) but it may create (too) long names for
> "completely non ASCII charsets".
systems that don't support non-ASCII addresses. Just like MIME
8-7bit conversion, the need for it goes away over time.
Wietse
Wietse Venema
Dec 30, 2013, 7:16:32 AM12/30/13
to
Andreas Kasenides:
interoperate while the transition is being made, then real people
will switch from email to proprietary systems such as FB and the
like, and make the job easier for spying agencies.
Wietse
> Come to think of it, why don't we go back to using inches, yards,
> miles and pounds? It was, and still is, quite painful converting
> to SI.
If there is no migration path that allows different systems to
> miles and pounds? It was, and still is, quite painful converting
> to SI.
interoperate while the transition is being made, then real people
will switch from email to proprietary systems such as FB and the
like, and make the job easier for spying agencies.
Wietse
Viktor Dukhovni
Dec 30, 2013, 10:33:51 AM12/30/13
to
On Mon, Dec 30, 2013 at 07:10:26AM -0500, Wietse Venema wrote:
> > IMHO Extending punycode to local part may be a good option for "mostly
> > ASCII" charsets (ISO-8859-X) but it may create (too) long names for
> > "completely non ASCII charsets".
Punycode is a rather efficient encoding. There is little reason
> > IMHO Extending punycode to local part may be a good option for "mostly
> > ASCII" charsets (ISO-8859-X) but it may create (too) long names for
> > "completely non ASCII charsets".
to be concerned about the length of the localpart.
A more complex issue with Punycode is that address extensions are
problematic. That said, address extensions are generated by the sender.
Provided the sender's system understands whatever form they take
when the sender's address requires encoding from UTF-8, the rest of
the world need not know or care about how that's accomplished at
each site.
Thus, Postfix would hypothetically need to be able decode from
Punycode to UTF-8, strip the extension, and re-encode when performing
address lookups without the extension in various databases.
Likewise, when generating VERP sender addresses, it would need to
decode, append the extension then re-encode.
IMAP servers that support extensions and also UTF-8 localparts
would need similar logic.
Finally, for human-readable bounces, one might want to include
both the Punycode and the UTF-8 form of the address in bounce
body text.
None of the above would be a major obstacle, or introduce
interoperability issues with remote systems.
> This transformation would be needed only when sending mail between
> systems that don't support non-ASCII addresses. Just like MIME
> 8-7bit conversion, the need for it goes away over time.
encoding one needs to modify LDAP schemas, X.509 extension encoding
rules, SQL database character encoding rules, ... I expect the
Punycode localpart form would stay on the wire indefinitely, but
this is not a problem.
There would be a benefit to long-term Punycode localpart addresses.
Message recipients not familiar with the sender's native script
will generally be able distinguish distinct Punycode strings, and
will be able to begin to type the address into their email client
allowing the software to complete it, ...
--
Viktor.
Wietse Venema
Dec 30, 2013, 12:36:04 PM12/30/13
to
Wietse:
What we need is a legitimate transformation that allows mail to
flow between MTAs with and without standardized UTF8 support. Once
enough systems support standardized UTF8, the crutches can go away.
We need the transformation only to enable an orderly transition.
An example of this is the MIME 8bit-to-7bit transformation. It
took care of differences between MTAs without bothering users.
By now, all relevant MTAs are 8-bit clean.
If we can do no better than telling users "you need to resend your
UTF8 email in a different format" then I find that appalling.
Systems should take care of such details. If they don't, then users
will switch to something else.
Wietse
> This transformation would be needed only when sending mail between
> systems that don't support non-ASCII addresses. Just like MIME
> 8-7bit conversion, the need for it goes away over time.
Viktor Dukhovni:
> systems that don't support non-ASCII addresses. Just like MIME
> 8-7bit conversion, the need for it goes away over time.
> There would be a benefit to long-term Punycode localpart addresses.
I don't think that crutches like this should be deployed in eternity.
What we need is a legitimate transformation that allows mail to
flow between MTAs with and without standardized UTF8 support. Once
enough systems support standardized UTF8, the crutches can go away.
We need the transformation only to enable an orderly transition.
An example of this is the MIME 8bit-to-7bit transformation. It
took care of differences between MTAs without bothering users.
By now, all relevant MTAs are 8-bit clean.
If we can do no better than telling users "you need to resend your
UTF8 email in a different format" then I find that appalling.
Systems should take care of such details. If they don't, then users
will switch to something else.
Wietse
davi...@gmail.com
Mar 1, 2014, 11:25:45 AM3/1/14
to
So, there haven't been done any progress with this? It's 2014 year and we are still limited to 7-bit ASCII, that's a shame. It shouldn't matter if no one else have implemented it, but someone need to start. RFC 6531 is best what we currently have and it's proposed standard. Also it doesn't matter if no one else upgrades to it. I've my own server, with my own apps and there wouldn't be any problems as it would work for me.
0 new messages