One document matched: draft-ietf-eai-mailinglist-00.txt
Email Address Internationalization (EAI WG) Edmon Chung
Internet Draft Afilias
<draft-ietf-eai-mailinglist-00.txt>
June 19, 2006
Mailing Lists and Internationalized Email Addresses
STATUS OF THIS MEMO
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The reader is cautioned not to depend on the values that appear in
examples to be current or complete, since their purpose is primarily
educational. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Intellectual Property Rights Statement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Abstract
This document describes considerations for mailing-lists with the
introduction of internationalized email addressing capabilities.
Different scenarios involving interaction between mailing-lists and
internationalized email addresses are examined. Furthermore,
mailing-list header fields will be discussed.
Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Edmon Chung [Page 1]
EAI-Mailinglist JUNE 2006
Table of Contents
1. Introduction....................................................2
2. Scenarios Involving Mailing-Lists...............................3
2.1 Pure Case Scenarios............................................4
2.2 Mixed Case Scenarios...........................................4
3. Mailing List Header Fields......................................5
4. Managing Mailing Lists with Internationalized Email Address.....5
5. Further Discussion..............................................6
6. IANA Considerations.............................................6
7. Security Considerations.........................................6
8. Copyright Statement.............................................6
1. Introduction
Mailing-lists are an important part of email usage and collaborative
communications. The introduction of internationalized email
addresses must take into consideration impact on mailing-list
functionality. The consideration of mailing-lists in the context of
internationalized email addresses includes three main areas: (1)
transport protocol; (2) message headers; and (3) mailing-list
operation policies.
Mailing-lists are generally deployed either as a mass mailer client
or act in essence like a mail relay. In the case of a mailer client,
the mailing-list program is activated when it receives an email to
the mailing-list email account. The message is then sent to the
members on the mailing-list. In a relay model, the mail server upon
receipt of mail to the mailing-list account, relays the mail to all
members. Under both models, the mailing-list program usually
rewrites the return-path of the email to the corresponding mailing-
list. This allows recipients to observe the original sender of the
email, and be able to reply to the mailing-list conveniently.
In essence, the mail transport protocol does not differ between
regular email accounts and mailing-list accounts. Discussion on the
different scenarios involving mailing-lists and internationalized
email addresses are included in Section 2.
In terms of message headers, internationalized email address
considerations are required for the return-path rewrite as well as
internationalized email addresses in list fields as specified in
RFC2369 -- The Use of URLs as Meta-Syntax for Core Mail List Commands
and their Transport through Message Header Fields [RFC2369] and
RFC2919 -- List-Id: A Structured Field and Namespace for the
Identification of Mailing Lists [RFC2919]. This will be described in
Section 3.
A brief discussion on some key considerations for mailing-list
operation in an internationalized email address environment is
proposed in Section 4. This is followed by further discussions in
Section 5.
Edmon Chung [Page 2]
EAI-Mailinglist JUNE 2006
2. Scenarios Involving Mailing-Lists
Expanding from Sections 2.3 and 2.6 of the Scenarios document [EAI-
Scenarios], this section will provide an overview of the different
scenarios involving mailing-lists and internationalized email
addresses.
What is worth noting is that generally, for mailing-lists, each
message is transported between a sender email address and a recipient
mailing-list address or a sending mailing-list address and a
receiving member. A multi-recipient message is usually only a result
of situations where a sender includes additional addresses in the
"To" or "CC" fields while sending (or replying) to a mailing-list.
The following diagram summarizes the conceptual working of a mailing-
list (Pure Case):
(b)
-----> User1@exmaple.tld
(a) / (c)
User1@example.tld ------> mailing@list.tld ------> User2@example.tld
\ (d)
-----> ...
As observed above, the mail transport transactions (a), (b), (c) and
(d) all involves two parties, that is: 1. The mailing-list account;
and, 2. The user / member account. These scenarios are essentially
the same as those already described in Sections 2.1 and 2.4 of the
Scenarios document [EAI-Scenarios].
Multiple recipients are involved usually only when one (or more)
additional account(s) is (are) included (Mixed Case):
-----> User1@exmaple.tld
(a) /
User1@example.tld ---+--> mailing@list.tld ------> User2@example.tld
| ^ \ (d)
| | -----> ...
| | |
v | (e) |
cc@example.tld <-----+-------------(reply)--+
Under this situation, scenarios (a) and (e) resemble the situations
already described in Sections 2.2 and 2.5 of the Scenarios document
[EAI-Scenarios]. More specific discussions based on these two
general cases are included below.
Edmon Chung [Page 3]
EAI-Mailinglist JUNE 2006
2.1 Pure Case Scenarios
In the Pure Case described above, the following are possible for (a):
User1@example.tld mailing@list.tld
(1) ASCII ASCII
(2) non-ASCII ASCII
(3) ASCII non-ASCII
(4) non-ASCII non-ASCII
Among this set, (1) is simply the conventional case without involving
any internationalized email address. (2) and (3) are scenarios
described in Section 2.4 -- One i18nmail user sends to one ASCII user
-- of the Scenarios document, whereas (4) is described in Section 2.1
-- Two i18nmail users [EAI-Scenarios].
For (d) -- generalizing (b) and (c) -- it may be branched further
where:
(i) Mailing-list contains only ASCII email addresses
(ii) Mailing-list contains at least one internationalized email
address
For (ii), as the mailing-list is sending out to its members, its MTA
may encounter a situation where a downgrade [EAI-Downgrade] may be
called for. In order for a downgrade to be possible, the mailing-
list (and/or its MTA) must therefore have the alt-address or atomic
information. In general, it may be prudent for mailing-list
operators to pre-obtain this for all its member accounts. This will
ensure that mailing-list transactions within members will be able to
be delivered and replied to. Further discussion on mailing-list
policy considerations is included in section 4 of this document.
In the specific case where a non-member with an internationalized
email address is sending to a mailing-list, and that mailing-list is
UTF8SMTP-aware, and the path to a constituent member calls for a
downgrade, the mailing-list (and/or its MTA) may not have the alt-
address or atomic information of the non-member’s internationalized
email address, therefore failing to deliver the mail. Nevertheless,
this is not unique for mailing-lists. Mail relays that are UTF8SMTP-
aware will potentially encounter the same situation. Further
discussions are included in section 5 of this document.
2.2 Mixed Case Scenarios
The Mixed Case scenarios are essentially a combination of the
discussion in section 2.1 above, plus those described in Section 2.2
-- Three i18nmail users -- and, Section 2.5 -- An i18mail user sends
to one ascii user and one i18nmail user -- of the Scenarios [EAI-
Scenarios] document.
Similar issues arise with regards to members versus non-members,
especially non-members with an internationalized email address, as
discussed in the above section.
Edmon Chung [Page 4]
EAI-Mailinglist JUNE 2006
3. Mailing List Header Fields
A number of header fields specifically for mailing-lists have been
introduced in RFC2369 and RFC2919. These include, for example:
List-Id: List Header Mailing List <list-header.nisto.com>
List-Help: <mailto:list@host.com?subject=help> (List Instructions)
List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
List-Subscribe: <mailto:list@host.com?subject=subscribe>
List-Post: <mailto:list@host.com>
List-Owner: <mailto:listmom@host.com> (Contact Person for Help)
List-Archive: <mailto:archive@host.com?subject=index%20list>
As described in RFC2369, "The contents of the list header fields
mostly consist of angle-bracket ('<', '>') enclosed URLs, with
internal whitespace being ignored." [RFC2369] Whereas RFC2919
specifies that, "The list identifier will, in most cases, appear like
a host name in a domain of the list owner." [RFC2919]
By and large, the data contained in these mailing-list header fields
are URLs which contain email addresses. The same mechanism should be
used for these fields as with other fields specifically discussed in
the UTF8-Headers document [EAI-UTF8Headers]. Generally therefore,
for fields that contain an internationalized email address, it could
be expressed as a UTF8 string.
Downgrading provisions should also follow the chosen mechanism based
on the Downgrading document [EAI-Downgrade].
Because the email addresses will be expressed in URL format, further
specifications for presentation and inclusion of the alt-address and
atomic information may be necessary, other than simply following
RFC3987 Internationalized Resource Identifier (IRI) [RFC3987]
specifications. This will be further discussed in Section 5.
4. Managing Mailing Lists with Internationalized Email Address
Given the need potentially to deal with non-UTF8SMTP-aware MTAs in
the path of delivery for different members, it is advisable that
mailing-list operators obtain from all members their alt-address or
atomic information before setting up the mailing-list (or adding a
member with an internationalized email address)
In consideration for consistent delivery to all members in a mailing-
list, a mailing-list may want to consider rejecting (or otherwise
obtaining alt-address or atomic information from) a non-member who is
interacting with the mailing-list with an internationalized email
address. This is further discussed in Section 5.
Furthermore, operators should take caution to avoid setting up of an
MTA that is UTF8SMTP-aware with a mailing-list program that is non-
aware. This is especially important for mailing-list programs that
are based on a mail client and not directly integrated into an MTA.
Edmon Chung [Page 5]
EAI-Mailinglist JUNE 2006
The reverse may be less harmful but nevertheless should also be
avoided.
5. Further Discussion
While generally speaking, mailing-lists do not create additional
complexity for the deployment of internationalized email address
functionalities, the study in this document does uncover a couple of
relevant areas for further consideration. Nevertheless, neither
items are entirely unique to mailing-lists.
1. Obtaining Downgrade Information -- for a mailing-list, or mail
relay server for that matter, that is EAI-aware, receiving email from
an internationalized email address, the alt-address or atomic
information is not required from the sending MTA for the transport to
be complete. Thereupon when the mailing-list "relays" or "explodes"
the mail to all its members, it may encounter paths where a downgrade
is called for. In order to mitigate this situation, the mailing-list
may perhaps decide to reject all incoming mail from any non-member
internationalized email address or that alt-address or atomic
information is not provided. Alternatively, it may be useful to
consider having a mechanism, such as an additional SMTP command, for
the receiving MTA (in this case the mailing-list) to request for alt-
address or atomic information from the sender. This may be useful in
other scenarios as well, such as those concerning multiple
recipients.
2. Downgrading Considerations for mailto URLs -- downgrading
specifications may have to be specified particularly for mailto URLs
to take into consideration the presentation of alt-address or atomic
information. The UTF8 Headers document [EAI-UTF8Headers] suggests
including a parameter within the angled brackets of an email address
(e.g. <non-ascii@domain, alt-ascii@domain>). In the case of a mailto
URL, it may be possible to use the same mechanism, for example,
<mailto:non-ascii@example.tld?subject=help, alt-ascii@domain>,
however this should be further studied. Other places where an
internationalized email address could appear in a URL may also
require further examination.
6. IANA Considerations
This document does not make any request to IANA.
7. Security Considerations
Extensive security considerations have been included in the Framework
document [EAI-Framework].
Edmon Chung [Page 6]
EAI-Mailinglist JUNE 2006
8. Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
References
[EAI-Framework] J. Klensin and Y. Ko, "Overview and Framework for
Internationalized Email", draft-ietf-eai-framework-00.txt, May 24,
2006
[EAI-Scenarios] H. Alvestrand, "Internationalized Email Addresses:
Scenarios",draft-ietf-eai-scenarios-00.txt , May 12, 2006
[EAI-SMTPEXT] J. Yao and W. Mao, "SMTP extension for
internationalized email address", draft-ietf-eai-smtpext-00.txt, May
12, 2006
[EAI-UTF8Headers] J. Yeh, "Internationalized Email Headers", draft-
ietf-eai-utf8headers-00.txt, May 30, 2006
[EAI-Downgrade] Y. YONEYA and K. Fujiwara, "Downgrading mechanism for
Internationalized eMail Address (IMA)", draft-ietf-eai-downgrade-
00.txt, May 26, 2006
[RFC2369] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax for
Core Mail List Commands and their Transport through Message Header
Fields", July 1998
[RFC2919] R. Chandhok and G. Wenger, "List-Id: A Structured Field and
Namespace for the Identification of Mailing Lists", March 2001
[RFC3987] M. Duerst and M. Suignard,"Internationalized Resource
Identifiers (IRIs)", January 2005
Authors' Address:
Edmon Chung
Afilias
Suite 204, 4141 Yonge Street,
Toronto, Ontario,
Canada M2P 2A8
edmon@afilias.info
Edmon Chung [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 20:15:31 |