UASG014 - Quick Guide to EAI
Dear all: Attached is a draft revision to UASG014. A number of the edits have been hanging around for some time, some are new and added today. Key questions: 1) Do we revisit and revise this now and then possibly again once the Introduction to EAI is complete or do we wait until the Introduction to EAI is complete? I’m inclined to do it twice since we’re raising awareness and people may be referencing this more often. 2) I’ve added a section identifying which fields need to be considered when doing EAI retrofitting. Can someone provide such a list? Are there also tasks/functions that we need to apply? 3) Should we identify UASG Good Practices where they are not addressed one way or another within the RFCs? Eg Aliasing vs ‘downgrading’ on the fly. Don Don Hollander Universal Acceptance Steering Group www.uasg.tech don.hollander@icann.org Skype: don_hollander
On Sat, 13 Jan 2018, Don Hollander wrote:
2) I’ve added a section identifying which fields need to be considered when doing EAI retrofitting. Can someone provide such a list? Are there also tasks/functions that we need to apply?
For sending, all you have to do is to handle UTF-8 text in addresses in From:, To:, Cc:, Sender:, Reply-To:, and Resent-*:. But RFC 6532 also says that you can use UTF-8 nearly everywhere that used to require ASCII, so the display names, Subject: line, and message body can also be UTF-8, so you better be prepared to handle that on incoming mail even if you don't send it. Also, when doing attachments, if your mail program can attach one message to another, e.g., forward as an attachment, it needs to check if the message being forwarded is EAI and if so attach is as message/global rather than message/rfc822. It's probably also worth mentioning a few things not to change. Don't change the Date: header, since it's in a rigid format intended to be parsed and redisplayed by MUAs. (Mine displays dates in the local timezone, adjusting appropriately.) Don't change Message-IDs, they're for computers, not people.
3) Should we identify UASG Good Practices where they are not addressed one way or another within the RFCs? Eg Aliasing vs ‘downgrading’ on the fly.
Aliasing is the only thing that comes to mind. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
I think we need a section regarding how to display names on From/To/CC/BCC lines when they are received in unexpected formats. * Example 1: * Suppose a system replaces an address with a punycode equivalent or MIME equivalent. * (They shouldn't do that, but we are robust and can accept it.... it's just ascii, after all.) * If the message includes a friendly-from string, we can display as * Friendly Name <randomasciicrap@moreasciicrap> * … or, as just * Friendly Name * … or something else. * The former seems better to me. What is the UASG preferred practice? * Example 2: * When UTF8 is received on a non-EAI-compatible client or via a non-EAI-compatible service on the CC line, it will usually show the right characters (fonts are often managed by the OS, not the app), but Reply and Reply All will fail. * I think John mentioned that ":;" is used in this case, sorry if I captured that wrong. * Is this the best way to convey to the user that Reply is unavailable? -----Original Message----- From: UA-EAI [mailto:ua-eai-bounces@icann.org] On Behalf Of John R. Levine Sent: Sunday, January 14, 2018 9:39 PM To: Don Hollander <don.hollander@icann.org> Cc: ua-eai@icann.org Subject: Re: [UA-EAI] UASG014 - Quick Guide to EAI On Sat, 13 Jan 2018, Don Hollander wrote:
2) I’ve added a section identifying which fields need to be considered
when doing EAI retrofitting. Can someone provide such a list? Are
there also tasks/functions that we need to apply?
For sending, all you have to do is to handle UTF-8 text in addresses in From:, To:, Cc:, Sender:, Reply-To:, and Resent-*:. But RFC 6532 also says that you can use UTF-8 nearly everywhere that used to require ASCII, so the display names, Subject: line, and message body can also be UTF-8, so you better be prepared to handle that on incoming mail even if you don't send it. Also, when doing attachments, if your mail program can attach one message to another, e.g., forward as an attachment, it needs to check if the message being forwarded is EAI and if so attach is as message/global rather than message/rfc822. It's probably also worth mentioning a few things not to change. Don't change the Date: header, since it's in a rigid format intended to be parsed and redisplayed by MUAs. (Mine displays dates in the local timezone, adjusting appropriately.) Don't change Message-IDs, they're for computers, not people.
3) Should we identify UASG Good Practices where they are not addressed
one way or another within the RFCs? Eg Aliasing vs ‘downgrading’ on
the fly.
Aliasing is the only thing that comes to mind. Regards, John Levine, johnl@iecc.com<mailto:johnl@iecc.com>, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly&data=...
* Suppose a system replaces an address with a punycode equivalent or MIME equivalent.
When you get mail from xn--ls8ha@outlook.com (a real address, try it) that may look like punycode, but it's not. There is no way to tell whether some address in a header was mangled by a previous step or if so, how to unmangle it. The reasonable approach is to do what the MUA normally does, show some combination of the display name and the unmodified actual address since that's most likely to be right.
* (They shouldn't do that, but we are robust and can accept it.... it's just ascii, after all.) * If the message includes a friendly-from string, we can display as * Friendly Name <randomasciicrap@moreasciicrap> * … or, as just * Friendly Name * … or something else. * The former seems better to me. What is the UASG preferred practice?
I don't see how this is EAI specific. Personally I always prefer to see both the comment and the real address, but a lot of mail programs written in the Redmond WA area only show the comment, unrelated to whether it's an EAI address.
* Example 2: * When UTF8 is received on a non-EAI-compatible client or via a non-EAI-compatible service on the CC line, it will usually show the right characters (fonts are often managed by the OS, not the app), but Reply and Reply All will fail.
It does not seem like a good idea to encourage people to spend any time applying band-aids to their non-EAI clients. If they want to handle EAI, they should fix their software to handle EAI, a position we came to in the IETF EAI group after everything else turned out to be unworkable. I agree since a lot of MTAs are mostly 8-bit clean in some cases the UTF-8 headers may arrive intact, but I wouldn't want to count on it.
* I think John mentioned that ":;" is used in this case, sorry if I captured that wrong.
Yup, that's an empty address group. There are two RFCs about POP/IMAP servers downgrading mail so that non-EAI mail clients can at least see their mail. One tries to be very clever with reversible transformations, which I think is the wrong place to put effort, the other just smashes headers down to something legit without worrying too much about the semantics. Putting the real addrss in the display name is reasonable. The :; tells the MUA that there's no addresses there so if you try to reply, there's nothing to reply to.
* Is this the best way to convey to the user that Reply is unavailable?
-----Original Message----- From: UA-EAI [mailto:ua-eai-bounces@icann.org] On Behalf Of John R. Levine Sent: Sunday, January 14, 2018 9:39 PM To: Don Hollander <don.hollander@icann.org> Cc: ua-eai@icann.org Subject: Re: [UA-EAI] UASG014 - Quick Guide to EAI
On Sat, 13 Jan 2018, Don Hollander wrote:
2) I’ve added a section identifying which fields need to be considered
when doing EAI retrofitting. Can someone provide such a list? Are
there also tasks/functions that we need to apply?
For sending, all you have to do is to handle UTF-8 text in addresses in From:, To:, Cc:, Sender:, Reply-To:, and Resent-*:. But RFC 6532 also says that you can use UTF-8 nearly everywhere that used to require ASCII, so the display names, Subject: line, and message body can also be UTF-8, so you better be prepared to handle that on incoming mail even if you don't send it. Also, when doing attachments, if your mail program can attach one message to another, e.g., forward as an attachment, it needs to check if the message being forwarded is EAI and if so attach is as message/global rather than message/rfc822.
It's probably also worth mentioning a few things not to change. Don't change the Date: header, since it's in a rigid format intended to be parsed and redisplayed by MUAs. (Mine displays dates in the local timezone, adjusting appropriately.) Don't change Message-IDs, they're for computers, not people.
3) Should we identify UASG Good Practices where they are not addressed
one way or another within the RFCs? Eg Aliasing vs ‘downgrading’ on
the fly.
Aliasing is the only thing that comes to mind.
Regards,
John Levine, johnl@iecc.com<mailto:johnl@iecc.com>, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly&data=...
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[Comments inline] -----Original Message----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Tuesday, January 16, 2018 4:22 PM To: Mark Svancarek <marksv@microsoft.com> Cc: Don Hollander <don.hollander@icann.org>; ua-eai@icann.org Subject: RE: [UA-EAI] UASG014 - Quick Guide to EAI
* Suppose a system replaces an address with a punycode equivalent or MIME equivalent.
When you get mail from xn--ls8ha@outlook.com (a real address, try it) that may look like punycode, but it's not. There is no way to tell whether some address in a header was mangled by a previous step or if so, how to unmangle it. The reasonable approach is to do what the MUA normally does, show some combination of the display name and the unmodified actual address since that's most likely to be right.
* (They shouldn't do that, but we are robust and can accept it.... it's just ascii, after all.) * If the message includes a friendly-from string, we can display as * Friendly Name <randomasciicrap@moreasciicrap> * … or, as just * Friendly Name * … or something else. * The former seems better to me. What is the UASG preferred practice?
I don't see how this is EAI specific. Personally I always prefer to see both the comment and the real address, but a lot of mail programs written in the Redmond WA area only show the comment, unrelated to whether it's an EAI address. [Mark Svancarek] It's not EAI specific, but it feels like something that might be more significant in an EAI setting. Also, there are other alternatives that I didn't include, such as putting things inside quote marks; I see that from time to time and don't know when or why it was used.
* Example 2: * When UTF8 is received on a non-EAI-compatible client or via a non-EAI-compatible service on the CC line, it will usually show the right characters (fonts are often managed by the OS, not the app), but Reply and Reply All will fail.
It does not seem like a good idea to encourage people to spend any time applying band-aids to their non-EAI clients. If they want to handle EAI, they should fix their software to handle EAI, a position we came to in the IETF EAI group after everything else turned out to be unworkable. [Mark Svancarek] Good point. This only applies to non-compatible clients, and we are asking them to do only one thing - support EAI. Please disregard this example. I agree since a lot of MTAs are mostly 8-bit clean in some cases the UTF-8 headers may arrive intact, but I wouldn't want to count on it.
* I think John mentioned that ":;" is used in this case, sorry if I captured that wrong.
Yup, that's an empty address group. There are two RFCs about POP/IMAP servers downgrading mail so that non-EAI mail clients can at least see their mail. One tries to be very clever with reversible transformations, which I think is the wrong place to put effort, the other just smashes headers down to something legit without worrying too much about the semantics. Putting the real addrss in the display name is reasonable. The :; tells the MUA that there's no addresses there so if you try to reply, there's nothing to reply to.
* Is this the best way to convey to the user that Reply is unavailable?
-----Original Message----- From: UA-EAI [mailto:ua-eai-bounces@icann.org] On Behalf Of John R. Levine Sent: Sunday, January 14, 2018 9:39 PM To: Don Hollander <don.hollander@icann.org> Cc: ua-eai@icann.org Subject: Re: [UA-EAI] UASG014 - Quick Guide to EAI
On Sat, 13 Jan 2018, Don Hollander wrote:
2) I’ve added a section identifying which fields need to be considered
when doing EAI retrofitting. Can someone provide such a list? Are
there also tasks/functions that we need to apply?
For sending, all you have to do is to handle UTF-8 text in addresses in From:, To:, Cc:, Sender:, Reply-To:, and Resent-*:. But RFC 6532 also says that you can use UTF-8 nearly everywhere that used to require ASCII, so the display names, Subject: line, and message body can also be UTF-8, so you better be prepared to handle that on incoming mail even if you don't send it. Also, when doing attachments, if your mail program can attach one message to another, e.g., forward as an attachment, it needs to check if the message being forwarded is EAI and if so attach is as message/global rather than message/rfc822.
It's probably also worth mentioning a few things not to change. Don't change the Date: header, since it's in a rigid format intended to be parsed and redisplayed by MUAs. (Mine displays dates in the local timezone, adjusting appropriately.) Don't change Message-IDs, they're for computers, not people.
3) Should we identify UASG Good Practices where they are not addressed
one way or another within the RFCs? Eg Aliasing vs ‘downgrading’ on
the fly.
Aliasing is the only thing that comes to mind.
Regards,
John Levine, johnl@iecc.com<mailto:johnl@iecc.com>, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly &data=02%7C01%7Cmarksv%40microsoft.com%7C936e38e36e874481fadd08d55bda6 1bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636515915867149370&sd ata=scv26qwi2VaZBitByBFyU%2FrOTaIGvdWosG5uo0%2BzbyI%3D&reserved=0
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly&data=...
Whenever we send an email to group addresses, in headers this gets represented as undisclosed-recipients:; This is also another way to represent BCC; So, May be put EAI address as display name and noncompatible-recipient:;. Or Utf8-email-address:; or Unsupported-email-address :; or contact-email-admin :; Or something like that in angular brackets.. That way, we can deliver and display properly at recipient Server/Client. However technically we have touched the email address we don't own. Just for information, if you compose an email on gmail and type your address in BCC and nothing in TO, CC , see how you get headers.. Thanks. On 17 January 2018 06:16:02 GMT+05:30, Mark Svancarek via UA-EAI <ua-eai@icann.org> wrote: [Comments inline] -----Original Message----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Tuesday, January 16, 2018 4:22 PM To: Mark Svancarek <marksv@microsoft.com> Cc: Don Hollander <don.hollander@icann.org>; ua-eai@icann.org Subject: RE: [UA-EAI] UASG014 - Quick Guide to EAI * Suppose a system replaces an address with a punycode equivalent or MIME equivalent. When you get mail from xn--ls8ha@outlook.com (a real address, try it) that may look like punycode, but it's not. There is no way to tell whether some address in a header was mangled by a previous step or if so, how to unmangle it. The reasonable approach is to do what the MUA normally does, show some combination of the display name and the unmodified actual address since that's most likely to be right. * (They shouldn't do that, but we are robust and can accept it.... it's just ascii, after all.) * If the message includes a friendly-from string, we can display as * Friendly Name <randomasciicrap@moreasciicrap> * … or, as just * Friendly Name * … or something else. * The former seems better to me. What is the UASG preferred practice? I don't see how this is EAI specific. Personally I always prefer to see both the comment and the real address, but a lot of mail programs written in the Redmond WA area only show the comment, unrelated to whether it's an EAI address. [Mark Svancarek] It's not EAI specific, but it feels like something that might be more significant in an EAI setting. Also, there are other alternatives that I didn't include, such as putting things inside quote marks; I see that from time to time and don't know when or why it was used. * Example 2: * When UTF8 is received on a non-EAI-compatible client or via a non-EAI-compatible service on the CC line, it will usually show the right characters (fonts are often managed by the OS, not the app), but Reply and Reply All will fail. It does not seem like a good idea to encourage people to spend any time applying band-aids to their non-EAI clients. If they want to handle EAI, they should fix their software to handle EAI, a position we came to in the IETF EAI group after everything else turned out to be unworkable. [Mark Svancarek] Good point. This only applies to non-compatible clients, and we are asking them to do only one thing - support EAI. Please disregard this example. I agree since a lot of MTAs are mostly 8-bit clean in some cases the UTF-8 headers may arrive intact, but I wouldn't want to count on it. * I think John mentioned that ":;" is used in this case, sorry if I captured that wrong. Yup, that's an empty address group. There are two RFCs about POP/IMAP servers downgrading mail so that non-EAI mail clients can at least see their mail. One tries to be very clever with reversible transformations, which I think is the wrong place to put effort, the other just smashes headers down to something legit without worrying too much about the semantics. Putting the real addrss in the display name is reasonable. The :; tells the MUA that there's no addresses there so if you try to reply, there's nothing to reply to. * Is this the best way to convey to the user that Reply is unavailable? -----Original Message----- From: UA-EAI [mailto:ua-eai-bounces@icann.org] On Behalf Of John R. Levine Sent: Sunday, January 14, 2018 9:39 PM To: Don Hollander <don.hollander@icann.org> Cc: ua-eai@icann.org Subject: Re: [UA-EAI] UASG014 - Quick Guide to EAI On Sat, 13 Jan 2018, Don Hollander wrote: 2) I’ve added a section identifying which fields need to be considered when doing EAI retrofitting. Can someone provide such a list? Are there also tasks/functions that we need to apply? For sending, all you have to do is to handle UTF-8 text in addresses in From:, To:, Cc:, Sender:, Reply-To:, and Resent-*:. But RFC 6532 also says that you can use UTF-8 nearly everywhere that used to require ASCII, so the display names, Subject: line, and message body can also be UTF-8, so you better be prepared to handle that on incoming mail even if you don't send it. Also, when doing attachments, if your mail program can attach one message to another, e.g., forward as an attachment, it needs to check if the message being forwarded is EAI and if so attach is as message/global rather than message/rfc822. It's probably also worth mentioning a few things not to change. Don't change the Date: header, since it's in a rigid format intended to be parsed and redisplayed by MUAs. (Mine displays dates in the local timezone, adjusting appropriately.) Don't change Message-IDs, they're for computers, not people. 3) Should we identify UASG Good Practices where they are not addressed one way or another within the RFCs? Eg Aliasing vs ‘downgrading’ on the fly. Aliasing is the only thing that comes to mind. Regards, John Levine, johnl@iecc.com<mailto:johnl@iecc.com>, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly &data=02%7C01%7Cmarksv%40microsoft.com <http://40microsoft.com> %7C936e38e36e874481fadd08d55bda6 1bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636515915867149370&sd ata=scv26qwi2VaZBitByBFyU%2FrOTaIGvdWosG5uo0%2BzbyI%3D&reserved=0 Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly&data=...> &data=02%7C01%7Cmarksv%40microsoft.com%7C5400c036d8b04819f69c08d55d4049da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636517453053962352&sdata=qCzrqdPvuc8qwgnF4wRQc%2BfeYoQM%2BMZL4DDTWXtZpww%3D&reserved=0 _____ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
Hi Don, kindly find my below comments highlighted with Yellow. There is two minor comments, kindly check the attached document. Thnx All the Best, Abdalmonem Tharwat Galila Deputy Manager, Dot Masr Registry, Operation Sector. [NTRA Logo 2016] National Telecommunication Regulatory Authority [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: 1365523405_telephone] Office Tel.: +2 02 35341582 - +2 02 35341300 [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Mobile] Mobile: +2 010 00049068 [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: ICON] Fax : +2 02 35370537 [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: oNLINE] Website : http:\\www.mcit.gov.eg<http://www.mcit.gov.eg/> : http:\\www.tra.gov.eg<http://www.mcit.gov.eg/> [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: 1365523294_email] E-mail : agalila@mcit.gov.eg<mailto:agalila@mcit.gov.eg> : atharwat@tra.gov.eg<mailto:atharwat@tra.gov.eg> [Description: 1447802547_skype] Skype : abdalmonem.galila [Description: static_qr_code_without_logo] [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: 1365523469_error]DISCLAIMER This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify your system support manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the National Telecom Regulatory Authority (NTRA) . Finally, the recipient should check this email and any attachments for the presence of viruses. The NTRA accepts no liability for any damage caused by any virus transmitted by this email. From: UA-EAI [mailto:ua-eai-bounces@icann.org] On Behalf Of Don Hollander Sent: Saturday, January 13, 2018 5:26 AM To: ua-eai@icann.org Subject: [UA-EAI] UASG014 - Quick Guide to EAI Dear all: Attached is a draft revision to UASG014. A number of the edits have been hanging around for some time, some are new and added today. Key questions: 1) Do we revisit and revise this now and then possibly again once the Introduction to EAI is complete or do we wait until the Introduction to EAI is complete? I’m inclined to do it twice since we’re raising awareness and people may be referencing this more often. Do it twice. 2) I’ve added a section identifying which fields need to be considered when doing EAI retrofitting. Can someone provide such a list? Are there also tasks/functions that we need to apply? Sorry which list you are referring to inside the document !! 3) Should we identify UASG Good Practices where they are not addressed one way or another within the RFCs? Eg Aliasing vs ‘downgrading’ on the fly. Yes it will be more helpful. Don
3) Should we identify UASG Good Practices where they are not addressed one way or another within the RFCs? Eg Aliasing vs ‘downgrading’ on the fly.
JFYI, there's anything up to 2.5 million MTAs deployed with EAI support now. (It's difficult to tell exactly since a majority has the support disabled in a configuration file. But a couple of million is a good guess. Roughly a million for each of Postfix and Exim, and a few tens of thousands for up to ten other MTAs.) Don't identify any "good practice" that's at odds with either Postfix or Exim. Even if something was a good idea, the deployed code is better by virtue of being deployed. What we need now is agreement and interoperation. Anyone who argues that some significant deviation from Postfix/Exim is a good idea risks being heard as saying "the 2008-era RFCs were bad, the 2012-era RFCs were bad, the 2014-16 implementations were bad but THIS time we've got it right". I realise that's not the intention, but it might well be the perception, and that perception would be harmful to further deployment. Arnt
Thanks Arnt. Is there any way to tell whether these 2.5 million installations are the EAI Ready releases? Is there a repository that counts downloads perhaps? At this point, we are only looking at the suggestion of using the alias for an ASCII address when encountering a non-EAI MTA. Can either Exim or Postfix do this?
On 16/01/2018, at 11:15 PM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:
3) Should we identify UASG Good Practices where they are not addressed one way or another within the RFCs? Eg Aliasing vs ‘downgrading’ on the fly.
JFYI, there's anything up to 2.5 million MTAs deployed with EAI support now. (It's difficult to tell exactly since a majority has the support disabled in a configuration file. But a couple of million is a good guess. Roughly a million for each of Postfix and Exim, and a few tens of thousands for up to ten other MTAs.)
Don't identify any "good practice" that's at odds with either Postfix or Exim. Even if something was a good idea, the deployed code is better by virtue of being deployed. What we need now is agreement and interoperation.
Anyone who argues that some significant deviation from Postfix/Exim is a good idea risks being heard as saying "the 2008-era RFCs were bad, the 2012-era RFCs were bad, the 2014-16 implementations were bad but THIS time we've got it right". I realise that's not the intention, but it might well be the perception, and that perception would be harmful to further deployment.
Arnt
_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
Don Hollander Universal Acceptance Steering Group www.uasg.tech don.hollander@icann.org Skype: don_hollander
Don Hollander writes:
Is there any way to tell whether these 2.5 million installations are the EAI Ready releases? Is there a repository that counts downloads perhaps?
I used shodan.io to survey the net. Shodan is a specialised search engine. You can use it to e.g. look for netgear equipment in Italy. I used it it to look for SMTP servers that offer SMTPUTF8 and via more complicated queries, for servers that could offer it but do not. The numbers/lists I've sent Jiankang and you about deployment are based in part on Shodan queries, with some refinement/extension by custom scripts I wrote. These servers are unlikely to be completely EAI-ready. One needs about three pieces of software, maybe four. Having one is a step up from zero.
At this point, we are only looking at the suggestion of using the alias for an ASCII address when encountering a non-EAI MTA. Can either Exim or Postfix do this?
Postfix cannot. IIRC Exim cannot either, but I might have missed something. (I did read the relevant source code.) Arnt
Arnt Gulbrandsen writes:
At this point, we are only looking at the suggestion of using the alias for an ASCII address when encountering a non-EAI MTA. Can either Exim or Postfix do this?
Postfix cannot. IIRC Exim cannot either, but I might have missed something. (I did read the relevant source code.)
I can put that stronger: I've either worked on or read the source of seven programs/libraries that will send EAI mail, and I don't think any of the seven would be able to fall back to an alternative address. Arnt
I can put that stronger: I've either worked on or read the source of seven programs/libraries that will send EAI mail, and I don't think any of the seven would be able to fall back to an alternative address.
That sort of fallback mostly makes sense in a webmail system where the MTA and MSA and address book are sufficiently integrated. To do it in postfix or exim you'd need to add an MTA-side address book of aliases which is rather unlike anything they do now. I use qmail which can easily tell whether addresses A and B deliver to the same place, but cannot tell you the other addresses that deliver the same as A, which is what you need here. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Arnt, John: Thanks for these comments. When a set of mail applications are bundled under a single umbrella, then the operator can do more - and the Transformation using an existing Alias is possible. But, if a mail user is using discrete components, then can you reasonably expect them to interact as we suggest transformation? Are we back to square 1' - having eliminated an algorithmic transformation of a non-ascii mailbox name? D On 17/01/18, 3:54 AM, "UA-EAI on behalf of John R. Levine" <ua-eai-bounces@icann.org on behalf of johnl@iecc.com> wrote: > I can put that stronger: I've either worked on or read the source of seven > programs/libraries that will send EAI mail, and I don't think any of the > seven would be able to fall back to an alternative address. That sort of fallback mostly makes sense in a webmail system where the MTA and MSA and address book are sufficiently integrated. To do it in postfix or exim you'd need to add an MTA-side address book of aliases which is rather unlike anything they do now. I use qmail which can easily tell whether addresses A and B deliver to the same place, but cannot tell you the other addresses that deliver the same as A, which is what you need here. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://urldefense.proofpoint.com/v2/url?u=https-3A__jl.ly&d=DwICAg&c=FmY1u3... _______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
Don Hollander writes:
When a set of mail applications are bundled under a single umbrella, then the operator can do more - and the Transformation using an existing Alias is possible.
But, if a mail user is using discrete components, then can you reasonably expect them to interact as we suggest transformation?
You can always expect more. You can always demand more. It doesn't necessarily do anyone any good. This added expectation is IMO bad. EAI is largely aimed at people who have a problem with email addresses in the latin alphabet, and this addition is largely aimed at people who don't. The addition is a loss of focus.
Are we back to square 1' - having eliminated an algorithmic transformation of a non-ascii mailbox name?
Yes. Arnt
I agree with this. You could wave your hands and invent complex ways for programs in the chain to signal back and forth, but that's all effort that would better be spent making software handle EAI directly. On Wed, 17 Jan 2018, Arnt Gulbrandsen wrote:
Don Hollander writes:
When a set of mail applications are bundled under a single umbrella, then the operator can do more - and the Transformation using an existing Alias is possible.
But, if a mail user is using discrete components, then can you reasonably expect them to interact as we suggest transformation?
You can always expect more. You can always demand more. It doesn't necessarily do anyone any good.
This added expectation is IMO bad. EAI is largely aimed at people who have a problem with email addresses in the latin alphabet, and this addition is largely aimed at people who don't. The addition is a loss of focus.
Are we back to square 1' - having eliminated an algorithmic transformation of a non-ascii mailbox name?
Yes.
Arnt
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Thanks for these comments.
When a set of mail applications are bundled under a single umbrella, then the operator can do more - and the Transformation using an existing Alias is possible.
But, if a mail user is using discrete components, then can you reasonably expect them to interact as we suggest transformation?
Are we back to square 1' - having eliminated an algorithmic transformation of a non-ascii mailbox name?
FYI, the IETF's EAI group went through all of this stuff in excruciating detail. The original experimental version had a bunch of downgrade features, nearly all of which went away in the later proposed standard because they just didn't work. I think it's safe to say that the answer to any question of the form "how about if you downgrade using approach X" will be that "X turns out not to work, you'd better use the effort to make EAI work." The only downgrade features left are ones to let old clients fetch EAI messages from POP and IMAP servers, and they don't try to make anything relplyable, just smash the headers so they're valid under RFC 5322. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
UPDATE FROM UASG HK / GZ MEETINGS After many discussions about downgrading, we have decided that the official UASG stance must be to support only aliasing of one's own mailboxes (user can elect to provide an address for auto-alias; webmail providers can auto-alias their own mailboxes when SMTPUTF8 isn't advertised; etc.). Any other mechanism is outside of UASG recommended practice, as well as IETF recommended practice. If your SW or service uses any other mechanism or transformation, that is between you and your customers. It will never be endorsed by UASG, and quite likely will be disavowed. As such, I prefer that we not continue to propose them or discuss such mechanisms on the discussion group. In fact, I think we should update the code of conduct to reflect this approach, as we would for any other unproductive line of discussion. I might just start shouting down these discussions whenever they pop up. That would be terribly rude, I think. Help me not to be terribly rude. Please don't discuss downgrading* techniques on the mailing list! /marksv *Not everyone agrees that "auto-aliasing" is even a form of "downgrading". But if you do, I request that you call it "auto-aliasing" or some other term just to help us keep the disctinction between what UASG supports (auto-aliasing) and what UASG doesn't support (everything else) distinct. -----Original Message----- From: UA-EAI [mailto:ua-eai-bounces@icann.org] On Behalf Of John R. Levine Sent: Wednesday, January 17, 2018 10:41 AM To: Don Hollander <don.hollander@icann.org> Cc: ua-eai@icann.org Subject: Re: [UA-EAI] UASG014 - Quick Guide to EAI
Thanks for these comments.
When a set of mail applications are bundled under a single umbrella, then the operator can do more - and the Transformation using an existing Alias is possible.
But, if a mail user is using discrete components, then can you reasonably expect them to interact as we suggest transformation?
Are we back to square 1' - having eliminated an algorithmic transformation of a non-ascii mailbox name?
FYI, the IETF's EAI group went through all of this stuff in excruciating detail. The original experimental version had a bunch of downgrade features, nearly all of which went away in the later proposed standard because they just didn't work. I think it's safe to say that the answer to any question of the form "how about if you downgrade using approach X" will be that "X turns out not to work, you'd better use the effort to make EAI work." The only downgrade features left are ones to let old clients fetch EAI messages from POP and IMAP servers, and they don't try to make anything relplyable, just smash the headers so they're valid under RFC 5322. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly&data=... _______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.or...
participants (6)
-
Abdalmonem Tharwat Galila -
Arnt Gulbrandsen -
Don Hollander -
Dr. Ajay DATA -
John R. Levine -
Mark Svancarek