Please find attached my draft notes rom the EAI Meting. Please advise of any suggested changes Don
Mark’s notes: * Anti-spam providers should also be engaged. For example, a bug found recently in EAI support within EOP (the protection service within Office 365) is the reason that EAI support for Exchange Online (EXO) is currently disabled. * Creating ‘rules’ for aliases is an important feature for both software and service providers. * We should be willing to create Informational RFCs and defend them. * Types of things we can put forward in an informational RFC: * Adding a bootstrap alias to the body of a message * Dealing with aliases may be script-specific * Determining rules and formats for NDR messages * How to handle when email address looks like EAI (e.g. Unicode@Unicode) but the UTF8 declaration is missing * What to do when local part contains ACE prefix (i.e. “xn—“) and when remainder is compatible with Punycode transformation * When to normalize local parts (consensus was that we shouldn’t ever change local parts, so this informational would just be a documentation of that consensus) * Normalization can modify digital signatures * Suggestions to mailbox providers regarding which Unicode compositions are preferred * Different providers handle messages sent to multiple senders differently. * Shodun search engine may provide insight. * About 10% of XIM deployments are supporting EAI. That seems bad, but actually at the rate of uptake of those patches, it will be 50+% in 3 years. * I think we agreed that we would advocate for IDNA2008 with compatibility mode to prevent spoofing of German, Greek and Cyrillic – but actually not sure if we got consensus or not * Since reputation if the current approach to anti-malware (as opposed to blocklisting), we should be testing SPF/DKIM. * Local networks can be a problem (anecdote about hotel breaking SMTPUTF8) * I wrote that there is an “EAI ambiguity” in the RFC 5228 Sieve, but I didn’t capture the nature of the ambiguity… Mark’s action items: * Clarify is sending-to is currently supported differently than receiving-from in EXO. This would be a transient issue (since support is nominally disabled for both at this time) but it is interesting to investigate. * Get Outlook bugs in Thailand from Throughwave and my local contact there * Contact Terry Zink (Microsoft EOP) and see if he can represent UASG/EAI in Lisbon Jun 12th. From: ua-eai-bounces@icann.org [mailto:ua-eai-bounces@icann.org] On Behalf Of Don Hollander Sent: Saturday, April 15, 2017 5:57 PM To: ua-eai@icann.org Subject: [UA-EAI] Draft Notes Please find attached my draft notes rom the EAI Meting. Please advise of any suggested changes Don
Cisco Firewalling method is likely to not know about SMTPUTF8, and as they do deep packet inspection, they are likely to reject packets. We need to find a contact there. On Mon, Apr 17, 2017 at 10:26 AM, Mark Svancarek via UA-EAI < ua-eai@icann.org> wrote:
Mark’s notes:
- Anti-spam providers should also be engaged. For example, a bug found recently in EAI support within EOP (the protection service within Office 365) is the reason that EAI support for Exchange Online (EXO) is currently disabled. - Creating ‘rules’ for aliases is an important feature for both software and service providers. - We should be willing to create Informational RFCs and defend them. - Types of things we can put forward in an informational RFC: - Adding a bootstrap alias to the body of a message - Dealing with aliases may be script-specific - Determining rules and formats for NDR messages - How to handle when email address looks like EAI (e.g. Unicode@Unicode) but the UTF8 declaration is missing - What to do when local part contains ACE prefix (i.e. “xn—“) and when remainder is compatible with Punycode transformation - When to normalize local parts (consensus was that we shouldn’t ever change local parts, so this informational would just be a documentation of that consensus) - Normalization can modify digital signatures - Suggestions to mailbox providers regarding which Unicode compositions are preferred - Different providers handle messages sent to multiple senders differently. - Shodun search engine may provide insight. - About 10% of XIM deployments are supporting EAI. That seems bad, but actually at the rate of uptake of those patches, it will be 50+% in 3 years. - I think we agreed that we would advocate for IDNA2008 with compatibility mode to prevent spoofing of German, Greek and Cyrillic – but actually not sure if we got consensus or not - Since reputation if the current approach to anti-malware (as opposed to blocklisting), we should be testing SPF/DKIM. - Local networks can be a problem (anecdote about hotel breaking SMTPUTF8) - I wrote that there is an “EAI ambiguity” in the RFC 5228 Sieve, but I didn’t capture the nature of the ambiguity…
Mark’s action items:
- Clarify is sending-to is currently supported differently than receiving-from in EXO. This would be a transient issue (since support is nominally disabled for both at this time) but it is interesting to investigate. - Get Outlook bugs in Thailand from Throughwave and my local contact there - Contact Terry Zink (Microsoft EOP) and see if he can represent UASG/EAI in Lisbon Jun 12th.
*From:* ua-eai-bounces@icann.org [mailto:ua-eai-bounces@icann.org] *On Behalf Of *Don Hollander *Sent:* Saturday, April 15, 2017 5:57 PM *To:* ua-eai@icann.org *Subject:* [UA-EAI] Draft Notes
Please find attached my draft notes rom the EAI Meting.
Please advise of any suggested changes
Don
_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
participants (3)
-
Don Hollander -
Franck Martin -
Mark Svancarek