John C Klensin | 1 May 15:19 2016

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

Hi.

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> ietf.org list.

    john

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

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

> 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
Picon

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> randy.pensive.org> wrote:
At 11:18 AM -0700 4/20/16, ned+ima <at> mrochek.com wrote:

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

 http://windowsitpro.com/isheriff/office-365-security

 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> ietf.org
https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima
Alan Ayres | 19 Apr 15:11 2016

RFC 5335




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

Alan,

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> ietf.org

You may also want to note that RFC 5335 was obsoleted by RFC 6532
<http://www.rfc-editor.org/info/rfc6532> in 2012.

Best regards,
Cindy

On Fri Apr 08 08:14:58 2016, adayres <at> monicals.com 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> ietf.org
https://www.ietf.org/mailman/listinfo/ima
Jiankang Yao | 24 Feb 03:03 2016
Picon

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.

Don


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> icann.org 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> icann.org.

 

 

 

_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima
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:
http://www.rfc-editor.org/errata_search.php?rfc=6855&eid=4029

--------------------------------------
Status: Verified
Type: Technical

Reported by: Chris Newman <chris.newman <at> oracle.com>
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).

Notes
-----
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> ietf.org
https://www.ietf.org/mailman/listinfo/ima
Shawn Steele | 24 Apr 21:21 2015
Picon

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.

-Shawn
Jiankang Yao | 23 Apr 00:53 2015
Picon

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> verisign.com>
日期: 2015年4月23日 GMT+85:50:39
收件人: "ua-international <at> icann.org" <ua-international <at> icann.org>
抄送: "UA-discuss <at> icann.org" <UA-discuss <at> icann.org>
主题: [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.

 

Scope

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

 

<image002.jpg>

 

 

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. https://mm.icann.org/mailman/listinfo/ua-international

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.

 

Best,

Dennis

 

 


_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima
Franck Martin | 15 Apr 11:24 2015
Picon

SMTPUTF8 and 8BITMIME

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
address. 

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> ietf.org
https://www.ietf.org/mailman/listinfo/ima
Arnt Gulbrandsen | 15 Apr 11:13 2015
Picon
Gravatar

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.

Arnt
John Bucy | 25 Mar 01:16 2015
Picon

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.


cheers
john
_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima
Jiankang Yao | 19 Dec 16:27 2014
Picon

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> ietf.org
https://www.ietf.org/mailman/listinfo/ima

Gmane