John C Klensin | 1 May 15:19 2016

FWD: Re: I-D Action: draft-ietf-appsawg-mdn-3798bis-07.txt


With apologies to anyone who is already following apps-discuss,
people on this list should be aware that this proposed
replacement to RFC 3798 (on which RFC 6533, the i18n MDN spec,
depends) is in the pipe and the objections I have raised.  If
you have comments, please address them to the
apps-discuss <at> list.


---------- Forwarded Message ----------
Date: Sunday, May 01, 2016 09:14 -0400
From: John C Klensin <john-ietf <at>>
To: apps-discuss <at>
Subject: Re: I-D Action: draft-ietf-appsawg-mdn-3798bis-07.txt

--On Sunday, May 01, 2016 04:50 -0700 internet-drafts <at>

> A New Internet-Draft is available from the on-line
> Internet-Drafts directories. This draft is a work item of the
> ART Area General Applications Working Group of the IETF.
>         Title           : Message Disposition Notification
>         Authors         : Tony Hansen
>                           Alexey Melnikov
> 	Filename        : draft-ietf-appsawg-mdn-3798bis-07.txt
> 	Pages           : 33
> 	Date            : 2016-05-01
(Continue reading)

Franck Martin | 20 Apr 22:35 2016

Re: RFC 5335

Speaking personally. When I tested EAI.

MUAs tends to not care about the format of the local part. It seems developers just take the string as is based on char boundaries found in the RFC5322.From and other places. In most places in the code, it does not matter what the local part is.

So, I think you would have little problems to send an email to an EAI address

I have also noticed that postfix, if 8bits is enabled, does not care about the local part and takes the string as is (as well as the rest of the email). it does not even need to advertise SMTPUTF8.

Things may break because the difficulty is in handling the mailbox.

Also, very few people use EAI mailboxes. So an EAI sender is usually a strong positive signal for SPAM. 

I think I still have an EAI email address, so if you want me to send you an email, please let me know in private.

On Wed, Apr 20, 2016 at 12:21 PM, Randall Gellens <rg+ietf <at>> wrote:
At 11:18 AM -0700 4/20/16, ned+ima <at> wrote:

 FWIW, I dug up the actual report, which is available for download here:

 The relevant part of the report appears to be this paragraph:

Thanks for digging up the report an extracting the relevant bits, Ned.

   ASCII characters have been exonerated and
   exploited worldwide.

Any idea what this sentence means?  It seems contradictory to say that something has been both exonerated and exploited.  (There have been ASCII-based attacks in the past, such as certain control codes, the old source-routing ("%" and "!") characters, and embedded nulls, but none of those have to do with EAI, and as far as I know, all have been fixed in current versions of any even moderately used mail servers.)

Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I pride myself on the fact that my work has no
socially  redeeming value.       --John Waters

IMA mailing list
IMA <at>

IMA mailing list
IMA <at>
Alan Ayres | 19 Apr 15:11 2016

RFC 5335

From: Cindy Morgan via RT <iesg-secretary <at>>
To: <adayres <at>>
Sent: 4/18/2016 4:46 PM
Subject: [ #119754] RFC 5335


You have reached the IETF Secretariat, and as such, we are not qualified to
answer your question.

It looks like RFC 5335 was product of the Email Address Internationalization
Working Group, which concluded back in 2013. However, the mailing list for that
group is still active, and you may have better luck if you try your question
there. The address for that mailing list is: ima <at>

You may also want to note that RFC 5335 was obsoleted by RFC 6532
<> in 2012.

Best regards,

On Fri Apr 08 08:14:58 2016, adayres <at> wrote:
> Recently a part by iSHERIFF titled "Office 365 Security: Why you need
> to be worried" came across my desk slamming Office 365.
> Per the article, a claim is made that Office 365 does not follow
> current RFC standards for email headers. The claim goes on to
> suggest that a lack of RFC 5335 exposes anyone to unauthorized
> intercept, editing and the ability to resend these messages with
> malicious content within the headers of the message. As you appear
> to be an authority of RFC 5335, I was hoping you would add your
> input to these claims as pertaining to RFC 5335.
> - Alan

IMA mailing list
IMA <at>
Jiankang Yao | 24 Feb 03:03 2016

Fw: EAI <at> UA

Dear all,
    You may be interested in the following messages.
Jiankang Yao
Date: 2016-02-24 09:57
Subject: EAI <at> UA

Jiankang Yao,

This is for you and others that you know who are working on EAI.  Please forward.


UASG Email Address Internationalization (EAI) Program

24 February 2016



Short version: If you’re part of the email community, send a note to don.hollander <at> join the UASG EAI Program to shape the deployment of internationalized email addresses (e.g., Борис <at> пример.рф).


More detail: The Universal Acceptance Steering Group (UASG) is a community initiative that’s supported by ICANN with a goal of addressing Universal Acceptance – the idea that all domain names work equally well.  


EAI (Email Address Internationalization) is an important part of the UASG’s work.  Our mission is to encourage wide implementation of EAI and to do this we’re keen to coordination and facilitate discussions among EAI practitioners.


The UASG has launched the “UASG EAI Program” to coordinate interoperability testing and discussion of internationalized email addresses.


Internationalized email addresses have non-ASCII characters in the local part (to the left of the <at> symbol in left-to-right scripts) of the email address. They can (and usually do) have an internationalized domain name. For example: Борис <at> пример.рф


The standards for internationalized email addresses are defined in RFCs 6530, 6531, and 6532. Since they have yet to be widely adopted, there are few industry best-practices for behaviors that are outside their scope.


The goals of the UASG EAI Program are to demonstrate the ability to:

-       Create EAI Addresses

-       Send mail to EAI Addresses

-       Receive mail at EAI addresses

-       Identify gaps in the RFCs: things that need to be covered before widespread adoption is realistic

-       Identify ‘good practice’ for EAI deployment

-       Provide a forum for EAI practitioners to talk.


Potential challenges might include:

-       Dealing with spoofing

-       What happens when EAI mail goes to a non-EAI compliant platform

-       Validating EAI mail outside of email systems

-       Dealing with right-to-left scripts (does the domain go on the right or the left?)

-       Address normalization

-       Dealing with aliases

-       And much, much more.


The UASG EAI Program is now seeking participants from the e-mail software and service provider community.


Expectations for service providers:

-       Scope a project within your organization to implement support for EAI and the RFCs linked above.

-       Provide a single point-of-contact for the UASG EAI Program. (This can be the same person who’s working on the project internally.)

-       Allow other members of the UASG EAI Program to access a limited number of test accounts for interoperability testing.


Towards these ends, we’ve created an EAI mailing list and will be working to identify EAI practitioners and facilitating interaction.


If you’d like to participate, please send a note to don.hollander <at>




IMA mailing list
IMA <at>
RFC Errata System | 24 Feb 00:49 2016

[Errata Verified] RFC6855 (4029)

The following errata report has been verified for RFC6855,
"IMAP Support for UTF-8". 

You may review the report below and at:

Status: Verified
Type: Technical

Reported by: Chris Newman <chris.newman <at>>
Date Reported: 2014-06-27
Verified by: Barry Leiba (IESG)

Section: 3

Original Text
   Once an IMAP client has enabled UTF-8 support with the "ENABLE
   UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
   contains a charset specification.  If an IMAP server receives such a
   "SEARCH" command in that situation, it SHOULD reject the command with
   a "BAD" response (due to the conflicting charset labels).

Corrected Text
   Once an IMAP client has enabled UTF-8 support with the "ENABLE
   UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
   contains a charset specification. If an IMAP server receives such a
   "SEARCH" command in that situation, it SHOULD reject the command with
   a "BAD" response (due to the conflicting charset labels). This also
   applies to any IMAP command or extension that includes an optional
   charset label and associated strings in the command arguments,
   including the MULTISEARCH extension. For commands with a mandatory
   charset field, such as SORT and THREAD, servers SHOULD reject charset
   values other than UTF-8 with a “BAD” response (due to the conflicting
   charset labels).

This is a straightforward extrapolation of the existing text, but a literal reading of the existing text is
silent about how to deal with this situation.

RFC6855 (draft-ietf-eai-5738bis-12)
Title               : IMAP Support for UTF-8
Publication Date    : March 2013
Author(s)           : P. Resnick, Ed., C. Newman, Ed., S. Shen, Ed.
Category            : PROPOSED STANDARD
Source              : Email Address Internationalization
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

IMA mailing list
IMA <at>
Shawn Steele | 24 Apr 21:21 2015

IDN in Unicode

> The basic propose is to find solution for IDN domains and email addresses be present in original scripts.  

That seems like a completely different discussion than "let's use UTF-32".  

Many applications handle domain names natively in either UTF-8 or UTF-16, either of which are sufficient
to describe the domains in their original scripts.  

Punycode is kind of a hack to provide a mechanism to resolve domain names using the preexisting
infrastructure that is limited to the ASCII space.  However many applications, like EAI, prefer UTF-8.

Our recommendations provide for IDN to be looked up with Punycode only in the resolution phase.  For many
apps that is transparent to the app and they can just use Unicode with the system API set.  Some apps, however
may need to recognize Punycode domains for whatever reason or additional protocol limitations.  However
in those cases it is still recommended that they prefer Unicode and only use the Punycode when absolutely necessary.

Jiankang Yao | 23 Apr 00:53 2015

Fwd: [UA-discuss] UA Internationalization Project Group kicks off!

For those who might be interested in it, the following list may be helpful.

发件人: "Tan Tanaka, Dennis" <dtantanaka <at>>
日期: 2015年4月23日 GMT+85:50:39
收件人: "ua-international <at>" <ua-international <at>>
抄送: "UA-discuss <at>" <UA-discuss <at>>
主题: [UA-discuss] UA Internationalization Project Group kicks off!

<!-- /* Font Definitions */ <at> font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} <at> font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} <at> font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} <at> font-face {font-family:"\ <at> SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif"; color:black;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} <at> page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ <at> list l0 {mso-list-id:166332374; mso-list-type:hybrid; mso-list-template-ids:112494492 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1 {mso-list-id:291057015; mso-list-type:hybrid; mso-list-template-ids:1502929956 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l1:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} -->

Dear Project Group members,


The Internationalization (i18n for short) Project Group is open for business!


Here are a few items to get us started.



The i18n Project Group will be focused on the IDN ecosystem as it pertains to these four major categories:

1.       Standards (i.e., IETF, Unicode, W3C)

2.       Practices (i.e. guidelines established by others)

3.       Tools (i.e., apis, programming languages)

4.       Applications (e.g. browsers, email clients, other apps)

By IDN ecosystem we mean IDNA, EAI and IRI





Next Steps and action items

1.       Increase membership – We don’t pretend to know it all. We need help! Please share the mailing list address to anyone who you think is interested in the subject of IDNs, EAI and IRIs.

2.       Meetings – Our first group meeting will be in the week of May 11. This will allow Dusan and I time to prepare so that we have a meaningful and productive discussion. I will circulate a doodle poll to agree on a time.






IMA mailing list
IMA <at>
Franck Martin | 15 Apr 11:24 2015


it seems that a few MTA can be thrown at an email with a EAI RFC5321.mailfrom and pass the message fine to other
MTA or local delivery, as long as the MTA supports 8BITMIME and the RFC5321.rcptto is a standard email

replying to such email is a challenge, but it does not seem any MTA or MUA (with 8BITMIME) will complain
because the RFC5321.from is an EAI...

What’s your experience?
IMA mailing list
IMA <at>
Arnt Gulbrandsen | 15 Apr 11:13 2015

FWIW, draft-ietf-dane-openpgpkey-03

Some of you might want to take an interest in that. Might.

My wife pointed me to it, I've glanced at it and a) it seems to copy 4255, 
which AFAICT hasn't been much of a success and b) it adds to PGP, ditto. I 
can't find any motivation to care. But perhaps one of you should, so it'll 
avoid gratuitous incompatibility with 6530.

John Bucy | 25 Mar 01:16 2015

SMTPUTF8 for non EAI messages

This is a spillover from a discussion on dmarc <at>

Has the wg considered the case of using SMTPUTF8 as a means to avoid 2047/2231 encoding for messages that don't contain any eai addresses? I understand eai avoids downgrading since it doesn't really work for addr-spec but it seems like it should be harmless for places where encoded-word is allowed along the lines of the "gateway transformation" described in 6152.

IMA mailing list
IMA <at>
Jiankang Yao | 19 Dec 16:27 2014

Chinese email address

Dear all, 

    For those who can recognize the Chinese character, you can log on the    Following link to register a Chinese email address. You can also have an opportunity to get iPhone 6 as a prize.

IMA mailing list
IMA <at>