From ima-bounces@ietf.org Wed Nov 01 00:12:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf8Na-00062O-Lm; Wed, 01 Nov 2006 00:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf8NY-00061q-Pm for ima@ietf.org; Wed, 01 Nov 2006 00:11:08 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf8NW-00023E-BU for ima@ietf.org; Wed, 01 Nov 2006 00:11:08 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gf8N7-0003kr-D0 for ima@ietf.org; Wed, 01 Nov 2006 06:10:41 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 06:10:41 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 06:10:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-smtpext-02.txt ( draft-ietf-eai-utf8headers-02.txt ) Date: 01 Nov 2006 07:10:34 +0200 Lines: 90 Message-ID: <5dvelzrbud.fsf@Hurtta06k.keh.iki.fi> References: <5dzmbjtdq1.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes: > draft-ietf-eai-smtpext-02.txt: > > | Assuming that the server advertises UTF8SMTP and 8BITMIME, and at > | least one non-ASCII address, with or without ALT-ADDRESS, the precise > | interpretation of these parameters on the MAIL command is: > | 1. Headers are in UTF-8, body parts are in ASCII. > | 2. Headers are in UTF-8, some or all body parts contain 8-bit line- > | oriented data. > | 3. Headers are in UTF-8, some or all body parts contain binary data > | without restriction as to line lengths or delimiters. > > So model is following: > > Indication for internationalized email is > Header-Type: UTF8 > > header field on mail DATA. > > let's compare this to model of 8-bit MIME email model: > > Indication for 8-bit (MIME) emila is > BODY=BITMIME > > parameter on MAIL -command > > However there is also > Content-Transfer-Encoding: 8bit > > header field on mail DATA, but 8BITMIME extension did > not select that for indication. > > > > So perhaps it make sense to compare what are differences > on these two situations? > > Question is: > > Why 8BITMIME needed BODY=BITMIME parameter for MAIL -command > when same information is available on email header > fields ? > > Why UTF8SMTP does not need parameter for MAIL -command, > but instead is relying email header field about that. > > > > I do not say that there is something wrong, > but I ask reasoning of selections. One reason, why perhaps MAIL FROM: BODY=8BITMIME was used as indication instead of DATA .... Content-Transfer-Encoding: 8bit is that MAIL -command occur before RCPT -command. Therefore SMTP recipient can reject RCPT TO -command, if it knows that it can not downgrade email. However RFC 1652 do not confirm that reason. To UTF8SMTP sequence is MAIL FROM:<7-bit-address@domain1> RCPT TO:<7-bit-localpart@domain2> RCPT TO:<7-bit-localpart@domain3> DATA Header-Type: UTF8 ... Subject: Ääkkösiä ... Content-Ttype: text/plain Content-Transfer-Encoding: 7bit 7-bit-text . domain2 is known to support UTF8SMTP and domain3 is known to not support UTF8SMTP. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 01:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf9bI-0005aS-0S; Wed, 01 Nov 2006 01:29:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf9Y7-0004w0-KR for ima@ietf.org; Wed, 01 Nov 2006 01:26:07 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf9L0-0007fR-4s for ima@ietf.org; Wed, 01 Nov 2006 01:12:35 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0241A2596D7; Wed, 1 Nov 2006 07:09:45 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21175-01; Wed, 1 Nov 2006 07:09:38 +0100 (CET) Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE6A12596D6; Wed, 1 Nov 2006 07:09:37 +0100 (CET) Message-ID: <45483AC9.8040209@alvestrand.no> Date: Wed, 01 Nov 2006 07:12:25 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Charles Lindsey Subject: Automatic LHS downgrading is not on the agenda (Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label) References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> <5DAAD30D180E1A4125249F98@p3.JCK.COM> <453C899E.124F@xyzzy.claranet.de> <453C99E2.3020307@icu.ac.kr> <453CB14F.2A21@xyzzy.claranet.de> <6E1EBC5B4E9473014387D9A7@p3.JCK.COM> <8D2BD2C1379D72F9180C1BAC@p3.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > > Are you now accepting that the use of Punycode for downgrding > local-parts is now back on the agenda, subject to a suitable technical > specification of exactly how to do it (and possibly in conjuction with > an ATOMIC, or more likely DOWNGRADABLE, keyword)? (chair hat on) I am not accepting that. If you insist, I can make it the subject of a formal poll, but I think we've debated this enough times, and if anything the decision that "the sender decides what the downgraded address should be" has become more absolutist over time (this was why ATOMIC was removed). Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 06:52:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEd6-0003zl-5H; Wed, 01 Nov 2006 06:51:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEd4-0003x3-PA for ima@ietf.org; Wed, 01 Nov 2006 06:51:34 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfEcy-00039u-4G for ima@ietf.org; Wed, 01 Nov 2006 06:51:34 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfEch-0000pe-8C for ima@ietf.org; Wed, 01 Nov 2006 12:51:11 +0100 Received: from pd9fba99f.dip0.t-ipconnect.de ([217.251.169.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 12:51:11 +0100 Received: from nobody by pd9fba99f.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 12:51:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject Date: Wed, 01 Nov 2006 12:44:22 +0100 Organization: Lines: 98 Message-ID: <45488896.64C8@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> <4546AA9A.16B@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba99f.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > I don't understand what you are saying above. Perhaps a word > is missing; perhaps I'm just confused. Maybe it's just some case of "DEnglish" on my side. I agree completely with our description of a backup MX forced to fight on its own while the primary MX (or any other source to get up to date info wrt local recipients) is down. It's in a bad position, if it accepts almost anything it will get numerous rejects later, causing bounces to random addresses. That's of course unacceptable, it would be handled as net abuse, adding the IPs of the MTA sending those bounces later (that's not necessarily the same MTA as the backup MX) on block lists. After that some valid DSNs won't make it to the senders, their mail is lost in a black hole. Therefore the backup MX should try to limit mails it accepts as good as possible, rejecting anything that's "unclear" (e.g. from alleged "dynamic IPs", or similar black lists). With TempFail or greylisting it can survive on its own for about 100 hours. That's the best it can do - of course there's no problem at all with SPF PASS or FAIL mails if the backup MX supports SPF, but most mails today won't offer this good/bad Return-Path indicator. > When the target server is off-net or offline, the backup MX > receives all traffic bound for the target server and stores it > for future delivery Receives, yes, but it won't accept all. Otherwise botnets could take out the primary MX, and then flood the backup MX with their crap. > as I understand it, your proposal would prohibit those kinds of > arrangements entirely, since the backup MX host would not have > knowledge of the authenticity of sending addresses No, it only needs to reject more radically than an ordinary MX, e.g. TempFail based on DNSBLs - as far as I'm concerned it could accept SPF PASS without further checks, but probably it's cheaper to check DNSBLs first. Implementation details, how it does this is its own business. Unsolicited DSNs will be reported as spam no matter what we say. I tried to convince the SpamCop folks that such reports should be limited to (unnecessary) SPF FAIL bounces, precisely because of this "backup MX" scenario (among others like "over quota"), but they didn't like that, claiming that "backup MX" is a hopelessly obsolete concept. :-( > it couldn't do real-time forward checks (VRFY?) Or what you described here in another article, an SMTP dialogue with the next hop, squeezed into the timeout between RCPT TO and DATA, emulating VRFY by MAIL FROM + RCPT TO. > I don't think that conclusion, and prohibition, is tolerable, at > least without an email regime in which only trusted hosts are > permitted to send mail White listed senders are a piece of the puzzle: If the backup MX knows that anything from say w3.org is normally "good" it only has to verify that a client claiming to be w3.org really is w3.org - if I try `nslookup -q=txt frink.w3.org` it's not hard to decide. A very simple check eliminating some zombies could insist on one dot, not found in "ehlo oemcomputer". I really wish my ISP would try that instead of their post-SMTP sieve-magic, when it's far too late for any reliable way to deal with suspicious mails. Updating those zombies to get at least the dot right is no serious hurdle, but IMO a step in the right direction. > we are nowhere near getting there. YMMD. It's - no surprise - specified in RFC 4408 + errata, the original concept are RFC 821 reverse paths (skipping RMX and other details). > as Charles has pointed out, all of these issues exist without any > i18n extensions, so they are not really the province of this WG. ACK, but he also wrote this in : | The only difference in the case of UTF8SMTP is that such messages | may create more bounces than regular messages usually do. EAI must not make it worse than it is. It should use neutral terms like "reject" instead of "bounce" where applicable. That was the point of the subject "issue: framework 4.1 - reject". If a border MTA accepts mails "on probation", claiming that they always could be bounced later, it's probably doing something wrong. Maybe based on "(as indicated by the reverse-path)" as false premise for 80% of the mail traffic today. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 07:23:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfF8E-0005gz-7N; Wed, 01 Nov 2006 07:23:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfF8D-0005gZ-4W for ima@ietf.org; Wed, 01 Nov 2006 07:23:45 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfF89-0008Vx-31 for ima@ietf.org; Wed, 01 Nov 2006 07:23:45 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 1 Nov 2006 12:23:25 +0000 Message-ID: <454891B3.6010802@isode.com> Date: Wed, 01 Nov 2006 12:23:15 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] WG LAST CALL: draft-ietf-eai-framework-02 References: <45339923.8030900@alvestrand.no> <4546623A.9070709@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Charles Lindsey , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >--On Monday, 30 October, 2006 20:36 +0000 Alexey Melnikov > wrote: > > >>Charles Lindsey wrote: >> >> >>>>3. Document Plan >>>> In addition to this document, the following documents make >>>> up this specification and provide advice and context for >>>> it. o SMTP extensions. This document >>>> [I18Nemail-SMTPext] provides an SMTP extension for >>>> internationalized addresses, as provided for in RFC >>>> 2821. >>>> >>>> >>>Is not LMTP extended in the same way? >>> >>> >>Good point. >> >> >Not in the charter. In other words, one thing at a time. If we >can get this right for SMTP and then move toward standards-track >specs, certainly an LMTP upgrade should be part of that effort. > > This is a one line change to LMTP, IMHO: "The same SMTP extension can also be used with LMTP". But otherwise I agree with "one thing at a time". >>>> There are many places in MUAs or in user presentation in >>>> which email addresses or domain names appear. Examples >>>> include the conventional From, To, or Cc header fields; >>>> Message-IDs; In-Reply-To fields that may contain >>>> addresses or domain names; and in message bodies. >>>> >>>> >>>Arrrrrgghhhhh! No! Message-IDs do NOT contain email addresses >>>(they just look >>>like email addresses). >>> >>> >>Yes, I've stumbled on this text as well. >> >>I think Message-ID/In-Reply-To are examples of the "or domain >>names" part. >> >> > >Yes. But I have restructured the sentence to clarify this and >noted that Message-IDs may be a special case. > > Good. >>>> ago and not just those delivered seconds ago. As such, >>>> MUAs and mail filtering software will need to continue to >>>> accept and decode header fields that use the "encoded >>>> word" mechanism [RFC2047] to accommodate >>>> >>>> >>> ^ >>> and the >>> mechanisms of >>>[RFC2231] >>> >>> >>>> non-ASCII characters in some header fields. >>>> >>>> >>>Not sure what "filtering software" you have in mind that >>>might need to decode >>>2047 and 2231 stuff. >>> >>> >>E.g. Sieve mail filtering, which can run inside MTAs or MDAs. >> >> >Yes, that is what we had in mind along with some non-standard >techniques. Do you think Sieve should be explicitly referenced >as an example and, if so, should the reference be to 3028 or to >something else? > > I don't think there is any need, but an informative reference to RFC 3028 would be fine with me. (IETF LC for 3028bis just ended, but it doesn't really matter which one is referenced) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 08:28:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfG8X-0003Fu-Bl; Wed, 01 Nov 2006 08:28:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfG8V-0003Fo-Vv for ima@ietf.org; Wed, 01 Nov 2006 08:28:08 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfG8S-0003rt-K0 for ima@ietf.org; Wed, 01 Nov 2006 08:28:07 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C5942596C6; Wed, 1 Nov 2006 14:25:15 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31814-03; Wed, 1 Nov 2006 14:25:06 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0CD52596C7; Wed, 1 Nov 2006 14:25:05 +0100 (CET) Message-ID: <4548A0DA.9060508@alvestrand.no> Date: Wed, 01 Nov 2006 05:27:54 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Frank Ellermann References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> In-Reply-To: <45343AE1.5F1C@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ima@ietf.org Subject: [EAI] #1388: framework -3 - missing MIME considerations X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This issue has been assigned #1388. I believe the debate has shown: - The most controversial aspect here is whether message/rfc822 can be used for passing around UTF8SMTP messages or not. - There are multiple people who think that doing so is asking for trouble, so we should do something else, and one person (Charles) who believes that it should be so used. - A separate draft, draft-hurtta-eai-encapsulation, has been written, but not submitted (kari, can you get it onto a website somewhere? If necessary, send it to me..), detailing one "something else" I believe the needed change to the Framework document is to state that the "headers" document also needs to describe the interactions between UTF8SMTP messages and MIME, and the details need to be tackled as part of the discussion on the headers document (and possibly Kari's document). Makes sense? Harald Frank Ellermann wrote: > The "document plan" in chapter 3 tries to get away with updating 2822 > in the utf8headers I-D. That's not good enough for some darker corners > of MIME like UTF-8 in comments in Content-* header fields or preambles. > > The utf8headers I-D must explain why a new message subtype (different > from rfc822) isn't desirable, why using message/rfc822 with UTF-8 > headers won't cause havoc, and how it might affect application/mbox. > > The "document plan" should note this - a separate draft for MIME issues > (separated from the utf8headers I-D) would be too confusing. > > Frank > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 08:45:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGPl-0005Uj-5J; Wed, 01 Nov 2006 08:45:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGPj-0005Gz-JV for ima@ietf.org; Wed, 01 Nov 2006 08:45:55 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfGPi-0008Kb-7z for ima@ietf.org; Wed, 01 Nov 2006 08:45:55 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D06182596C6; Wed, 1 Nov 2006 14:43:04 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32175-02; Wed, 1 Nov 2006 14:42:57 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C45202596C7; Wed, 1 Nov 2006 14:42:57 +0100 (CET) Message-ID: <4548A50A.1050102@alvestrand.no> Date: Wed, 01 Nov 2006 05:45:46 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Frank Ellermann References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> In-Reply-To: <45343E6F.6AC4@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ima@ietf.org Subject: [EAI] #1389: framework 4.1 - reject X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This issue is assigned #1389. From reading the discussion, I conclude: - The word "bounce" is clearly not understood in only one way within the community. So if the editor wishes to continue to use the word, rather than a construct like "reject or send an NDN", a definition needs to be added to the document. - There is no consensus in this WG about whether or not the SMTP model should be changed from "send an NDN if you have to drop a message" to "reject the message if you're not sure you can deliver it". Fortunately, that is also a question that is not on the charter of this WG, and is thus offtopic for this mailing list. I suggest that the resolution to this issue will involve language in the framework document saying that the decision to send an NDN, reject, or drop the message when an UTF8SMTP problem is encountered should be done consistently with the policies in force for normal SMTP traffic (whatever those are). Makes sense? Harald Frank Ellermann wrote: > s/bounce/reject/g A "bounce" is commonly understood as sending spam > (unsolicited NDRs) to innocent bystanders as part of a DDoS. > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 08:56:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGZD-0003Ci-Dn; Wed, 01 Nov 2006 08:55:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGZC-0003CZ-BX for ima@ietf.org; Wed, 01 Nov 2006 08:55:42 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfGZB-0002Au-0c for ima@ietf.org; Wed, 01 Nov 2006 08:55:42 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9BB4D2596C7; Wed, 1 Nov 2006 14:52:51 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32188-10; Wed, 1 Nov 2006 14:52:45 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A21002596C6; Wed, 1 Nov 2006 14:52:45 +0100 (CET) Message-ID: <4548A756.3090607@alvestrand.no> Date: Wed, 01 Nov 2006 05:55:34 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 5 - delivery to final delivery MTA References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4535E6D9.4040201@icu.ac.kr> <4535FD19.169A@xyzzy.claranet.de> <45366BDA.63B2@xyzzy.claranet.de> In-Reply-To: <45366BDA.63B2@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.6 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org (technical contributor hat) In the RFC series, the first occurences of MDA as an acronym in a mail context appear to be in RFC 4406 (Sender ID), 4417 (IAB Messaging workshop), and 4496 (OPES use cases). We might be best served by avoiding the term altogether. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 09:00:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGdk-0002cO-1n; Wed, 01 Nov 2006 09:00:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGdg-0002ZO-LH for ima@ietf.org; Wed, 01 Nov 2006 09:00:21 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfGdY-00039c-GZ for ima@ietf.org; Wed, 01 Nov 2006 09:00:20 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfGdA-0001fk-6X for ima@ietf.org; Wed, 01 Nov 2006 14:59:48 +0100 Received: from pd9fba99f.dip0.t-ipconnect.de ([217.251.169.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 14:59:48 +0100 Received: from nobody by pd9fba99f.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 14:59:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Wed, 01 Nov 2006 14:53:08 +0100 Organization: Lines: 70 Message-ID: <4548A6C4.429@xyzzy.claranet.de> References: <6.0.0.20.2.20061026182815.05d4a530@localhost> <4541DB8F.5FD8@xyzzy.claranet.de> <6.0.0.20.2.20061029173555.04c54080@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba99f.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: uri@w3.org Subject: [EAI] Re: I-D ACTION:draft-duerst-mailto-bis-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst wrote (): > There is a special proceduce with which you can request an exception > from the 'no downreferences' rule. If I remember correctly, it was > proposed by John :-). The proposed experiment didn't make it. And if RFC 3967 was published before 4409... now I'm curious if I can reconstruct this: pidtracker.cgi?command=view_id&dTag=11010 says that 3967 was approved 2004-07-23 and published 2005-01-04. pidtracker.cgi?command=view_id&dTag=11926 says that 4409 was approved 2005-05-16 and published almost a year later. And the Last Call was 2005-01-27. The tracker didn't note the text of this Last Call, asking GMaNe I get Nothing about 3967 and Down-Ref, the normative reference of 2821 is an error. The dependency tool finds RFC 2821, but it doesn't red-flag it as Down-Ref. Some IETF rules & rituals are stranger than "humming" :-) > Can you say exactly what you want to happen with In-Reply-To? > (ideally some proposed text?). Your text is fine, you only forgot to list it together with the known- to-be-harmless hname "subject=" in chapter 4. Where you have a hname "body=", which is known-to-be-not-harmless. And you have no "cc=" in chapter 4, it's IMO better than the dubious "to=". Let's move the mailto details to another list - the URI list isn't my favourite, finding 2822 experts like Bruce is simpler on the rfc822 list, but you mentioned that you don't read that in the "archived-at" Last Call. I can't set a Reply-To or Followups-To via GMaNe, so this is only an X-Post, please remove EAI. >> or even UTF-8, encoded with 2047 (or a CTE + Content-Type for the >> insane body= construct). > What would be the issue with this? This would be the right thing > to do pre-EAI, and is shown in various examples in the draft. ACK, I meant UTF-8 C3 80 misinterpreted as say windows-1252 C3 + 80, converted to C3 83 + E2 82 AC, and at that point adding 2047 doen't help anymore, =?utf-8?q?=c3=83=e2=82=ac?= or similar is unrelated to the u+00C0 I want. [after the EAI experiment] > at that time we would also add the syntax for fallback addresses, > if we think it makes sense, yes? Yes, apparently they intend to take square brackets or curly braces. John said the former might be better than the latter, but wrt URIs it's apparently equivalent, 1738 had both in , and 3986 requires to percent-encode both - IPv? delimiters in an don't affect mailto:, it has no and no , it uses percent-encoded . >> Then we'll also have IDNAbis, and folks are used to work with >> normal IRIs, not this worst case "mailto:" > Can you say exactly what you are alluding to? When IRIs are used everywhere folks will also want to use them for mailto:. They won't start to use IRIs with mailto:. My crystal ball says (caveat - the same crystal ball claims that we all use X.400 for more than a decade now, shortly after X.25 and X.75 have replaced the last pockets of IP :-) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 09:06:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGj8-0003tk-Gs; Wed, 01 Nov 2006 09:05:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGj6-0003sC-KP for ima@ietf.org; Wed, 01 Nov 2006 09:05:56 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfGj2-0004dq-7l for ima@ietf.org; Wed, 01 Nov 2006 09:05:56 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 1 Nov 2006 14:05:51 +0000 Message-ID: <4548A9B1.3040606@isode.com> Date: Wed, 01 Nov 2006 14:05:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [EAI] ISSUE: framework 5 - delivery to final delivery MTA References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4535E6D9.4040201@icu.ac.kr> <4535FD19.169A@xyzzy.claranet.de> <45366BDA.63B2@xyzzy.claranet.de> <4548A756.3090607@alvestrand.no> In-Reply-To: <4548A756.3090607@alvestrand.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > (technical contributor hat) > > In the RFC series, the first occurences of MDA as an acronym in a mail > context appear to be in RFC 4406 (Sender ID), 4417 (IAB Messaging > workshop), and 4496 (OPES use cases). > > We might be best served by avoiding the term altogether. (The MDA acronym is frequently used in Sieve WG.) My personaly preference would be to ask Dave Crocker to publish draft-crocker-email-arch-05.txt as RFC and change the framework document to reference it. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 09:11:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGoa-0006MS-GA; Wed, 01 Nov 2006 09:11:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGoa-0006MN-0V for ima@ietf.org; Wed, 01 Nov 2006 09:11:36 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfGoY-0005nQ-Md for ima@ietf.org; Wed, 01 Nov 2006 09:11:35 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 391EF2596C7; Wed, 1 Nov 2006 15:08:45 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32529-10; Wed, 1 Nov 2006 15:08:39 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0DC42596C6; Wed, 1 Nov 2006 15:08:39 +0100 (CET) Message-ID: <4548AB10.3020704@alvestrand.no> Date: Wed, 01 Nov 2006 06:11:28 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Frank Ellermann References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> In-Reply-To: <453443FC.4A2F@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ima@ietf.org Subject: [EAI] #1391: framework 5 - delivery to final delivery MTA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This issue is assigned #1391. (chair hat on) I think discussion shows that "final delivery MTA" needs a definition in section 1.3, but not much more needs to be changed; once that definition is clear, the text is too. Makes sense? Harald Frank Ellermann wrote: > A "delivery to the final delivery MTA" is confusing, should that be > a "delivery by the final delivery MTA", or a "forward to the" MDA ? > > Maybe replace "or after delivery to the final delivery MTA" by > "or at final delivery by the MDA" (acronym introduced in section 3). > > Frank > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 09:30:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfH6Z-0003Oj-SB; Wed, 01 Nov 2006 09:30:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfH6Y-0003Od-9v for ima@ietf.org; Wed, 01 Nov 2006 09:30:10 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfH6U-0001iu-UW for ima@ietf.org; Wed, 01 Nov 2006 09:30:10 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfH6R-00025B-Uk; Wed, 01 Nov 2006 09:30:04 -0500 Date: Wed, 01 Nov 2006 09:30:03 -0500 From: John C Klensin To: Harald Alvestrand , Frank Ellermann Subject: Re: [EAI] #1389: framework 4.1 - reject Message-ID: <1C83043D52C72D00393A364F@p3.JCK.COM> In-Reply-To: <4548A50A.1050102@alvestrand.no> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <4548A50A.1050102@alvestrand.no> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 01 November, 2006 05:45 -0800 Harald Alvestrand wrote: > This issue is assigned #1389. > > From reading the discussion, I conclude: > > - The word "bounce" is clearly not understood in only one way > within the community. So if the editor wishes to continue to > use the word, rather than a construct like "reject or send an > NDN", a definition needs to be added to the document. Done. Tentative language follows; tuning welcome: As specified in RFC 2821, a message that is undeliverable for some reason is expected to result in notification to the sender. This can occur in either of two ways. One involves "rejection" by an SMTP server that generates a command response that contains a reply code indicating a fatal error (a "5yz" code). The other involves accepting the message during SMTP processing and then generating a message to the sender, typically known as a "Non-delivery notification" or "NDN". Current practice often favors rejection over NDNs because of the reduced likelihood that the generation of NDN themselves will be used as a spamming technique. The latter, NDN, case is unavoidable if an intermediate MTA accepts a message that is then rejected by the next-hop server. The term "bounce" is used informally below to cover both the rejection and NDN cases. > - There is no consensus in this WG about whether or not the > SMTP model should be changed from "send an NDN if you have to > drop a message" to "reject the message if you're not sure you > can deliver it". Fortunately, that is also a question that is > not on the charter of this WG, and is thus offtopic for this > mailing list. > > I suggest that the resolution to this issue will involve > language in the framework document saying that the decision to > send an NDN, reject, or drop the message when an UTF8SMTP > problem is encountered should be done consistently with the > policies in force for normal SMTP traffic (whatever those are). > > Makes sense? It does to me. Is the above text sufficient, or should words be added that indicate explicitly that policies for UTF8SMTP messages should be identical to those for all-ASCII messages? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 09:31:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfH7W-0003Rp-Us; Wed, 01 Nov 2006 09:31:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfH7V-0003Rk-Qr for ima@ietf.org; Wed, 01 Nov 2006 09:31:09 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfH7P-0001p1-Gs for ima@ietf.org; Wed, 01 Nov 2006 09:31:09 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfH6s-0008Ns-D5 for ima@ietf.org; Wed, 01 Nov 2006 15:30:30 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 15:30:30 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 15:30:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] #1388: framework -3 - missing MIME considerations Date: 01 Nov 2006 16:30:17 +0200 Lines: 34 Message-ID: <5dfyd3tf2e.fsf@Hurtta06k.keh.iki.fi> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand writes in gmane.ietf.ima: > This issue has been assigned #1388. > > I believe the debate has shown: > > - The most controversial aspect here is whether message/rfc822 can be > used for passing around UTF8SMTP messages or not. I think that message/rfc822 can be used for UTF8SMTP messages when it is inside on UTF8SMTP environment, but message/rfc822 can not be used for encapsulation. > - There are multiple people who think that doing so is asking for > trouble, so we should do something else, and one person (Charles) who > believes that it should be so used. > - A separate draft, draft-hurtta-eai-encapsulation, has been written, > but not submitted (kari, can you get it onto a website somewhere? If > necessary, send it to me..), detailing one "something else" Ok. I try put it to website (possibly today or tomorrow.) > I believe the needed change to the Framework document is to state that > the "headers" document also needs to describe the interactions between > UTF8SMTP messages and MIME, and the details need to be tackled as part > of the discussion on the headers document (and possibly Kari's > document). > > Makes sense? > > Harald > / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 09:39:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHFw-0007N4-Ju; Wed, 01 Nov 2006 09:39:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHFv-0007KF-SB for ima@ietf.org; Wed, 01 Nov 2006 09:39:51 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHFt-0003tM-HO for ima@ietf.org; Wed, 01 Nov 2006 09:39:51 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB6422596C6; Wed, 1 Nov 2006 15:36:55 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00456-10; Wed, 1 Nov 2006 15:36:42 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 361062596C7; Wed, 1 Nov 2006 15:36:42 +0100 (CET) Message-ID: <4548B1A3.40105@alvestrand.no> Date: Wed, 01 Nov 2006 06:39:31 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Frank Ellermann References: <45339923.8030900@alvestrand.no> <453445CC.7F86@xyzzy.claranet.de> In-Reply-To: <453445CC.7F86@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ima@ietf.org Subject: [EAI] #1392: framework 6 - delete section X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Resolution: On scanning id-checklist, no requirement was found for such a section. The section will be deleted. Frank Ellermann wrote: > The complete I-D is about I18N, it doesn't need this redundant section. > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 10:04:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHdw-0002ri-I4; Wed, 01 Nov 2006 10:04:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHdv-0002rd-T6 for ima@ietf.org; Wed, 01 Nov 2006 10:04:39 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHds-0000k9-Ui for ima@ietf.org; Wed, 01 Nov 2006 10:04:39 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfHdq-0002M0-JJ; Wed, 01 Nov 2006 10:04:34 -0500 Date: Wed, 01 Nov 2006 10:04:33 -0500 From: John C Klensin To: Harald Alvestrand , Frank Ellermann Subject: Re: [EAI] #1388: framework -3 - missing MIME considerations Message-ID: <64DE6FC0A6A84765E6A0668E@p3.JCK.COM> In-Reply-To: <4548A0DA.9060508@alvestrand.no> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 01 November, 2006 05:27 -0800 Harald Alvestrand wrote: > This issue has been assigned #1388. > > I believe the debate has shown: > > - The most controversial aspect here is whether message/rfc822 > can be used for passing around UTF8SMTP messages or not. > - There are multiple people who think that doing so is asking > for trouble, so we should do something else, and one person > (Charles) who believes that it should be so used. > - A separate draft, draft-hurtta-eai-encapsulation, has been > written, but not submitted (kari, can you get it onto a > website somewhere? If necessary, send it to me..), detailing > one "something else" > > I believe the needed change to the Framework document is to > state that the "headers" document also needs to describe the > interactions between UTF8SMTP messages and MIME, and the > details need to be tackled as part of the discussion on the > headers document (and possibly Kari's document). > > Makes sense? Yes. Proposed text for Framework, added to section 3, bullet 2: This document, possibly with one or more supplemental ones, will also need to address the interactions with MIME, including relationships between UTF8SMTP and internal MIME headers and content types. Is that adequate? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 10:25:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHxf-0003ck-UR; Wed, 01 Nov 2006 10:25:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHxe-0003cN-Mg for ima@ietf.org; Wed, 01 Nov 2006 10:25:02 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHxB-0006Tn-3v for ima@ietf.org; Wed, 01 Nov 2006 10:24:49 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C4022596CA; Wed, 1 Nov 2006 16:21:43 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02178-03; Wed, 1 Nov 2006 16:21:35 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C02B32596C6; Wed, 1 Nov 2006 16:21:35 +0100 (CET) Message-ID: <4548BC28.9010507@alvestrand.no> Date: Wed, 01 Nov 2006 07:24:24 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] #1388: framework -3 - missing MIME considerations References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> <64DE6FC0A6A84765E6A0668E@p3.JCK.COM> In-Reply-To: <64DE6FC0A6A84765E6A0668E@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > > > Yes. Proposed text for Framework, added to section 3, bullet 2: > > This document, possibly with one or more supplemental > ones, will also need to address the interactions with > MIME, including relationships between UTF8SMTP and > internal MIME headers and content types. > > Is that adequate? It seems adequate to me. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 10:28:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfI0W-0004as-7M; Wed, 01 Nov 2006 10:28:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHxp-0003iW-Kk for ima@ietf.org; Wed, 01 Nov 2006 10:25:13 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHrj-0004Xr-UX for ima@ietf.org; Wed, 01 Nov 2006 10:19:34 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BDC92596C7; Wed, 1 Nov 2006 16:16:06 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01828-08; Wed, 1 Nov 2006 16:15:57 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC99C2596C6; Wed, 1 Nov 2006 16:15:57 +0100 (CET) Message-ID: <4548BAD6.5020805@alvestrand.no> Date: Wed, 01 Nov 2006 07:18:46 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Charles Lindsey Subject: Name of effort, name of protocol (Re: [EAI] Comments on draft-ietf-eai-downgrade-02) References: <20061020.220825.68136113.fujiwara@jprs.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Fri, 20 Oct 2006 14:08:25 +0100, wrote: > > >>> From: "Charles Lindsey" >>> Date: Mon, 04 Sep 2006 20:21:38 +0100 >>> >>> s/EAI/UTF8SMTP/ throughout the document, including in the title. >> >> I'm hesitating EAI or UTF8SMTP. >> framework document is 'EAI Framework'. >> Which is this protocol set name, EAI or UTF8SMTP ? > > I think some gathering at an IETF agreed that the visible name of our > endeavour should have "UTF8" in it, and the provisional choice was > "UTF8SMTP" (I would have preferred "UTF8-Headers" myself). I don't > think the world out there is going to accept the term "EAI" (they will > have enough trouble remembering what it stands for :-( ). We have been over this ground quite a few times. From the framework document, a section with which no issue has been raised: The umbrella term to describe the email address internationalization specified by this document and its companion documents is "UTF8SMTP". For example, an address permitted by this specification is referred as a "UTF8SMTP (compliant) address". The name of the protocol set, which is used wherever we can, is "UTF8SMTP". This has been the consistent answer ever since the conclusions from the EAI interim meeting in Beijing were sent to the list on June 14 of this year. The name of the working group is "EAI". This was chosen, in part, because nobody could find a present usage of the term "EAI" that someone would violently object to on the basis that it was confusing to have an email WG with that acronym. The name of the framework document is "Overview and Framework for Internationalized Email". If you can find the term "EAI" in that string, you have better eyes than me. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 10:28:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHy7-0003rE-69; Wed, 01 Nov 2006 10:25:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHy5-0003pP-LN for ima@ietf.org; Wed, 01 Nov 2006 10:25:29 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHn3-0003JC-7k for ima@ietf.org; Wed, 01 Nov 2006 10:14:09 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfHn2-0002SN-Lz; Wed, 01 Nov 2006 10:14:04 -0500 Date: Wed, 01 Nov 2006 10:14:03 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 4.1 - reject Message-ID: <9D933E18C32AA7F4B1D9B526@p3.JCK.COM> In-Reply-To: <45488896.64C8@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> <4546AA9A.16B@xyzzy.claranet.de> <45488896.64C8@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 01 November, 2006 12:44 +0100 Frank Ellermann wrote: > John C Klensin wrote: > >> I don't understand what you are saying above. Perhaps a word >> is missing; perhaps I'm just confused. > > Maybe it's just some case of "DEnglish" on my side. I agree > completely with our description of a backup MX forced to fight > on its own while the primary MX (or any other source to get up > to date info wrt local recipients) is down. > > It's in a bad position, if it accepts almost anything it will > get numerous rejects later, causing bounces to random > addresses. > > That's of course unacceptable, it would be handled as net > abuse, adding the IPs of the MTA sending those bounces later > (that's not necessarily the same MTA as the backup MX) on > block lists. After that some valid DSNs won't make it to the > senders, their mail is lost in a black hole. > > Therefore the backup MX should try to limit mails it accepts as > good as possible, rejecting anything that's "unclear" (e.g. > from alleged "dynamic IPs", or similar black lists). With > TempFail or greylisting it can survive on its own for about > 100 hours. >... Frank, This is a complex problem and, as has been pointed out, not one for this WG. Your insistent efforts to get your view written into the standard is one reason 2821bis has been permitted to quietly expire, but that is another issue. I will tell you that the notion of requiring the use of black (or grey) lists supplied by third parties is going to be operationally unacceptable to many server operators (and probably a standardization showstopper as a result) unless there are clear rules governing the behavior of those operators with clear lines of responsibility and liability for their actions. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 10:48:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIK2-00085U-Rv; Wed, 01 Nov 2006 10:48:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIK1-00085P-In for ima@ietf.org; Wed, 01 Nov 2006 10:48:09 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfIJy-0005wu-7q for ima@ietf.org; Wed, 01 Nov 2006 10:48:09 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfIJx-0002jR-LB; Wed, 01 Nov 2006 10:48:05 -0500 Date: Wed, 01 Nov 2006 10:48:04 -0500 From: John C Klensin To: Harald Alvestrand Subject: Re: [EAI] #1391: framework 5 - delivery to final delivery MTA Message-ID: <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> In-Reply-To: <4548AB10.3020704@alvestrand.no> References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 01 November, 2006 06:11 -0800 Harald Alvestrand wrote: > This issue is assigned #1391. > > (chair hat on) > I think discussion shows that "final delivery MTA" needs a > definition in section 1.3, but not much more needs to be > changed; once that definition is clear, the text is too. > > Makes sense? Proposed definition (new third paragraph of section 3); tuning welcome: However, the term "final delivery MTA" is used in this document in a fashion equivalent to the term "delivery system" or "final delivery system" of RFC 2821. This is the SMTP server that controls the format of, and is permitted to inspect and interpret, local-part addresses. It receives messages from the network for delivery to mailboxes, rather than relaying. From the perspective of the network, any local delivery arrangements such as saving to a message store, handoff to specific message delivery programs or agents, and mechanisms for retrieving messages are all "behind" the final delivery MTA and hence not part of the SMTP transport or delivery process. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 11:02:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIXg-0001jl-G0; Wed, 01 Nov 2006 11:02:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIXf-0001jf-GC for ima@ietf.org; Wed, 01 Nov 2006 11:02:15 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfIXe-0001gW-6J for ima@ietf.org; Wed, 01 Nov 2006 11:02:15 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfIXd-0002tS-TD; Wed, 01 Nov 2006 11:02:14 -0500 Date: Wed, 01 Nov 2006 11:02:12 -0500 From: John C Klensin To: Harald Alvestrand Subject: Re: [EAI] #1392: framework 6 - delete section Message-ID: <74FBC6C6C8BE7198ECE68A7D@p3.JCK.COM> In-Reply-To: <4548B1A3.40105@alvestrand.no> References: <45339923.8030900@alvestrand.no> <453445CC.7F86@xyzzy.claranet.de> <4548B1A3.40105@alvestrand.no> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 01 November, 2006 06:39 -0800 Harald Alvestrand wrote: > Resolution: > > On scanning id-checklist, no requirement was found for such a > section. > > The section will be deleted. Done john > Frank Ellermann wrote: >> The complete I-D is about I18N, it doesn't need this >> redundant section. >> >> >> >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www1.ietf.org/mailman/listinfo/ima >> >> > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 11:26:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIuM-0003X1-Ll; Wed, 01 Nov 2006 11:25:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIuL-0003Jm-FE for ima@ietf.org; Wed, 01 Nov 2006 11:25:41 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfIfh-0003y7-Q1 for ima@ietf.org; Wed, 01 Nov 2006 11:10:35 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfIfh-0002wP-EC; Wed, 01 Nov 2006 11:10:33 -0500 Date: Wed, 01 Nov 2006 11:10:32 -0500 From: John C Klensin To: Alexey Melnikov Subject: Re: [EAI] WG LAST CALL: draft-ietf-eai-framework-02 Message-ID: <6B7A571113262CF3C1DB0F97@p3.JCK.COM> In-Reply-To: <454891B3.6010802@isode.com> References: <45339923.8030900@alvestrand.no> <4546623A.9070709@isode.com> <454891B3.6010802@isode.com> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 01 November, 2006 12:23 +0000 Alexey Melnikov wrote: > John C Klensin wrote: > >> --On Monday, 30 October, 2006 20:36 +0000 Alexey Melnikov >> wrote: >> >> >>> Charles Lindsey wrote: >>> >>> >>>>> 3. Document Plan >>>>> In addition to this document, the following documents make >>>>> up this specification and provide advice and context for >>>>> it. o SMTP extensions. This document >>>>> [I18Nemail-SMTPext] provides an SMTP extension for >>>>> internationalized addresses, as provided for in RFC >>>>> 2821. >>>>> >>>>> >>>> Is not LMTP extended in the same way? >>>> >>>> >>> Good point. >>> >>> >> Not in the charter. In other words, one thing at a time. If >> we can get this right for SMTP and then move toward >> standards-track specs, certainly an LMTP upgrade should be >> part of that effort. >> >> > This is a one line change to LMTP, IMHO: "The same SMTP > extension can also be used with LMTP". > > But otherwise I agree with "one thing at a time". This, or something a little stronger, is IMO exactly right for a standards-track document that updates both SMTP and LMTP. >... >>>> Not sure what "filtering software" you have in mind that >>>> might need to decode >>>> 2047 and 2231 stuff. >>>> >>> E.g. Sieve mail filtering, which can run inside MTAs or MDAs. >>> >> Yes, that is what we had in mind along with some non-standard >> techniques. Do you think Sieve should be explicitly >> referenced as an example and, if so, should the reference be >> to 3028 or to something else? >> > I don't think there is any need, but an informative reference > to RFC 3028 would be fine with me. > (IETF LC for 3028bis just ended, but it doesn't really matter > which one is referenced) Reference to 3028 inserted. Please keep an eye on this -- if 3028bis is published before this doc, we should update it on principle. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 12:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJWF-0007ZH-8S; Wed, 01 Nov 2006 12:04:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJWD-0007Yx-Iz for ima@ietf.org; Wed, 01 Nov 2006 12:04:49 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJWA-0005o9-7a for ima@ietf.org; Wed, 01 Nov 2006 12:04:49 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C10392596C6 for ; Wed, 1 Nov 2006 18:01:56 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04646-07 for ; Wed, 1 Nov 2006 18:01:00 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 449082596C4 for ; Wed, 1 Nov 2006 18:01:00 +0100 (CET) Message-ID: <4548D374.4080609@alvestrand.no> Date: Wed, 01 Nov 2006 18:03:48 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed X-Virus-Scanned: by amavisd-new at alvestrand.no Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [EAI] Status of issues, EAI Framework document Last Call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The WG Last Call for the Framework document has now ended. I have recorded a total of 11 issues raised against the document: 9 from Frank, 1 from Martin, and 1 from Bj=C3=B6rn H=C3=B6hrmann (messages where= the subject line starts with "ISSUE", as per the instructions in the Last Call text). The ticket numbers go from 1387 to 1397. I'll try to review the discussion of the issues and propose resolutions ASAP. At a glance, none of them seem terribly difficult to resolve, and none seem to be likely to cause a drastic revision to the framework. Once these issues are resolved, and the editors have updated the document according to the resolutions, there will be a brief Last Call on the resolved document, to verify that the resolution of the issues raised is according to the will of the WG; NO NEW ISSUES WILL BE ACCEPTED AT THAT TIME. After this, the document will be sent to the IESG for approval. Thanks for your input, and looking forward to getting even more things nailed down by San Diego. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 12:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJZb-0003jS-Bj; Wed, 01 Nov 2006 12:08:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJZa-0003im-0s for ima@ietf.org; Wed, 01 Nov 2006 12:08:18 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJZD-0007ey-SR for ima@ietf.org; Wed, 01 Nov 2006 12:08:17 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfJYv-0000ri-0B for ima@ietf.org; Wed, 01 Nov 2006 18:07:37 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 18:07:36 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 18:07:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: draft-hurtta-eai-encapsulation (Re: [EAI] #1388: framework -3 - missing MIME considerations) Date: 01 Nov 2006 19:06:57 +0200 Lines: 12 Message-ID: <5dbqnrt7ta.fsf_-_@Hurtta06k.keh.iki.fi> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand writes in gmane.ietf.ima: > - A separate draft, draft-hurtta-eai-encapsulation, has been written, > but not submitted (kari, can you get it onto a website somewhere? If > necessary, send it to me..), detailing one "something else" See: / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 12:52:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfKGS-0007HJ-AR; Wed, 01 Nov 2006 12:52:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfKGR-0007H1-3m for ima@ietf.org; Wed, 01 Nov 2006 12:52:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfKGF-0000P1-O3 for ima@ietf.org; Wed, 01 Nov 2006 12:52:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfKFA-0001u8-2Y for ima@ietf.org; Wed, 01 Nov 2006 18:51:16 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 18:51:16 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 18:51:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 01 Nov 2006 19:49:54 +0200 Lines: 116 Message-ID: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This is perhaps too late, but anyway I considered that alt-address issue again. There is: angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] utf8-addr-spec = utf8-local-part "@" utf8-domain utf8-local-part= utf8-dot-atom / quoted-string / obs-local-part utf8-domain = utf8-dot-atom / domain-literal / obs-domain alt-address = [CFWS] "[" addr-spec "]" [CFWS] RFC 2822 have: addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part domain = dot-atom / domain-literal / obs-domain domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] dcontent = dtext / quoted-pair dtext = NO-WS-CTL / ; Non white space controls %d33-90 / ; The rest of the US-ASCII %d94-126 ; characters not including "[", ; "]", or "\" So there is possible following header fields: From: Käyttäjätuki From: Käyttäjätuki From: Käyttäjätuki From: Käyttäjätuki How easy it is to parse ? This is un-ambiguous, but still quite dangerous. That dcontext syntax is quote similar to quoted strings: qtext = NO-WS-CTL / ; Non white space controls %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-126 ; or the quote character qcontent = qtext / quoted-pair quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] So [something] is probably parsed as one token. Similar than "something" is parsed. Both allow most of characters and both use \ for escaping. That alt-address implies quite different kind parsing. I'm not sure that this is problem, but this do not look like most easiest syntax to write parser for. Possible other possibilities: 1) angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] alt-address = [CFWS] "[" addr-spec "]" [CFWS] this was suggested by someone other, but that do not look much better if [ ] are used. 2) angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] alt-address = [CFWS] ',' addr-spec [CFWS] 3) angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] alt-address = [CFWS] ';' addr-spec [CFWS] 4) angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] alt-address = [CFWS] "<" addr-spec ">" [CFWS] perhaps that is not so bad as it looks? 5) angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] alt-address = [CFWS] "<" addr-spec ">" [CFWS] Note that this all possibilities avoid characters used on atext. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 13:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfKvR-0001oR-KM; Wed, 01 Nov 2006 13:34:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfKvJ-0001hU-74 for ima@ietf.org; Wed, 01 Nov 2006 13:34:49 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfKpi-0001QW-PX for ima@ietf.org; Wed, 01 Nov 2006 13:29:09 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfKpL-0001Vs-Ng for ima@ietf.org; Wed, 01 Nov 2006 19:28:40 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 19:28:39 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 19:28:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: 01 Nov 2006 20:28:30 +0200 Lines: 61 Message-ID: <5d3b93t41d.fsf@Hurtta06k.keh.iki.fi> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > So [something] is probably parsed as one token. Similar than > "something" is parsed. Both allow most of characters and both use > \ for escaping. > > That alt-address implies quite different kind parsing. > > > I'm not sure that this is problem, but this do not look like most easiest > syntax to write parser for. > > Possible other possibilities: > > 1) > > angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] > > alt-address = [CFWS] "[" addr-spec "]" [CFWS] > > > this was suggested by someone other, but that do not look much better if > [ ] are used. > > 2) > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > alt-address = [CFWS] ',' addr-spec [CFWS] > > 3) > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > alt-address = [CFWS] ';' addr-spec [CFWS] > > 4) > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > alt-address = [CFWS] "<" addr-spec ">" [CFWS] > > perhaps that is not so bad as it looks? > > > 5) > > angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] > > alt-address = [CFWS] "<" addr-spec ">" [CFWS] > > > > > Note that this all possibilities avoid characters used on atext. It occured to me that there is ALSO possible to use unicode characters > 127 assuming that particular character is removed from allowed utf8-addr-spec characters. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 13:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLCs-0004Jv-HL; Wed, 01 Nov 2006 13:52:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLCr-0004Jl-BW for ima@ietf.org; Wed, 01 Nov 2006 13:52:57 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfLCl-0000Pj-R1 for ima@ietf.org; Wed, 01 Nov 2006 13:52:57 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfLCg-0006no-0H for ima@ietf.org; Wed, 01 Nov 2006 19:52:46 +0100 Received: from pd9fba99f.dip0.t-ipconnect.de ([217.251.169.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 19:52:45 +0100 Received: from nobody by pd9fba99f.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 19:52:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: OT: 2821bis (was: [EAI] ISSUE: framework 4.1 - reject) Date: Wed, 01 Nov 2006 19:49:26 +0100 Organization: Lines: 64 Message-ID: <4548EC36.5A27@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> <4546AA9A.16B@xyzzy.claranet.de> <45488896.64C8@xyzzy.claranet.de> <9D933E18C32AA7F4B1D9B526@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba99f.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >> I agree completely with our description of a backup MX s/our/your/ - I hope that typo was obvious. > This is a complex problem and, as has been pointed out, > not one for this WG. Only the terminology, "reject" vs. "bounce", is relevant. Some say that the terms like "reverse path", "MAIL FROM", "return-path", "envelope sender", etc. were always wrong, and it should have been "bounces-to". They say STD 10 is or rather was wrong. Others say these terms mean what they say, and that's no bug. Folks who had the misfortune to be hit by thousands of "misdirected bounces" tend to think that that's wrong. > Your insistent efforts to get your view written into the > standard is one reason 2821bis has been permitted to > quietly expire, but that is another issue. I don't agree that it's only my personal view. And nobody could force you to write something into a draft-klensin-* that you don't like. I was perfectly happy with your plan to get it in a shape with all listed and unlisted errata fixed, and then start a WG taking that state as its input. Compare , you proposed to get rid of the term "bounce" in 2821bis-01 Reading some of those old mails, it wasn't me who started that old (2005) "reject vs. bounce" thread. And at that time you wrote that you don't want to publish a -01 draft before an 2822bis-00 is ready. That was your decision, and all I contributed to that line of reasoning was that I'm not exactly interested in a 2822bis before USEFOR is ready (at the moment it's ready but not yet approved). > the notion of requiring the use of black (or grey) lists > supplied by third parties is going to be operationally > unacceptable to many server operators They can use their own black lists. "Greylisting" is a local technique (unrelated to DNSBLs), for a definition see And yes, I tried to get draft-irtf-asrg-dnsbl-02 published, but it's trapped in some procedural limbo about IRTF RFCs - or rather that's the last state I know (early 2006). Nobody (or at least not me) would expect that a new 2821bis would *_require_* specific wild and wonderful things like "greylisting", DNSBLs, 4408, call forward, and what else. I think you need a better reason than "Frank doesn't like misdirected bounces" for the 2821bis issue, I forwarded the announcement of 2821bis-00 to at least four groups (RFCI, SC, SPF, dan-am) as the most interesting IETF event for years. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 15:23:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMbr-0006Qo-Dd; Wed, 01 Nov 2006 15:22:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMbq-0006Qj-Bs for ima@ietf.org; Wed, 01 Nov 2006 15:22:50 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMbm-0001qs-SH for ima@ietf.org; Wed, 01 Nov 2006 15:22:50 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfMZU-0000n4-J9 for ima@ietf.org; Wed, 01 Nov 2006 21:20:24 +0100 Received: from pd9fba99f.dip0.t-ipconnect.de ([217.251.169.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 21:20:24 +0100 Received: from nobody by pd9fba99f.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 21:20:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Wed, 01 Nov 2006 20:56:35 +0100 Organization: Lines: 47 Message-ID: <4548FBF3.27E8@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba99f.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [EAI] Re: #1391: framework 5 - delivery to final delivery MTA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >| However, the term "final delivery MTA" is used in this >| document in a fashion equivalent to the term "delivery >| system" or "final delivery system" of RFC 2821. This >| is the SMTP server that controls the format of, and is >| permitted to inspect and interpret, local-part addresses. >| It receives messages from the network for delivery to >| mailboxes, rather than relaying. Is that really the same as "A relay SMTP server is usually the target of a DNS MX record that designates it, rather than the final delivery system." ? (2821 3.7) There are only two "delivery system" in 2821. 2821 2.3.3 says: ''the final ("delivery") MTA would be thought of as handing the mail off to an MUA (or at least transferring responsibility to it, e.g., by depositing the message in a "message store").'' What you describe above is apparently an MX or anything behind an MX, or in other words a "mail receiving network". Any MTA in the MRN can interpret local parts, e.g. replace BATV local parts by the real local part, or do something with "!" or "%" we don't need to discuss here. The STD 10 definition is "final delivery" = "leaves SMTP", and 2821 4.4 uses the same words: "Here, final delivery means the message has left the SMTP environment." Apparently you don't like ''(sometimes called "MDA")'' in chapter 3 of the framework draft, a simple fix would be to remove it, the term MDA isn't used elsewhere. And in chapter 5 "after delivery to the final delivery MTA" just sounds odd, maybe "after acceptance by the final delivery MTA" or "after forwarding to" is the same idea. Frank -- Found in : | that patchwork effort, unsurprisingly, didn't result in | completely consistent terminology. As far as I'm | concerned, 2821bis is our opportunity to smooth out | whatever rough edges, especially those of terminology, | that people can identify and think are work fixing. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 15:28:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMgp-0000qB-VV; Wed, 01 Nov 2006 15:27:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMgp-0000q6-9W for ima@ietf.org; Wed, 01 Nov 2006 15:27:59 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMgn-00031p-Ve for ima@ietf.org; Wed, 01 Nov 2006 15:27:59 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfMgA-0002Qr-4H for ima@ietf.org; Wed, 01 Nov 2006 21:27:18 +0100 Received: from pd9fba99f.dip0.t-ipconnect.de ([217.251.169.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 21:27:18 +0100 Received: from nobody by pd9fba99f.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 21:27:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 5 - delivery to final delivery MTA Date: Wed, 01 Nov 2006 21:26:17 +0100 Organization: Lines: 7 Message-ID: <454902E9.37B@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4535E6D9.4040201@icu.ac.kr> <4535FD19.169A@xyzzy.claranet.de> <45366BDA.63B2@xyzzy.claranet.de> <4548A756.3090607@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba99f.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.6 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: [MDA] > We might be best served by avoiding the term altogether. +1 (the email-arch-05 4.3.3 definition is of course fine) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 15:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMv7-00052f-0Q; Wed, 01 Nov 2006 15:42:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMv6-000501-0O for ima@ietf.org; Wed, 01 Nov 2006 15:42:44 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMv1-0005e2-PZ for ima@ietf.org; Wed, 01 Nov 2006 15:42:43 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfMuw-0005Bl-Vq; Wed, 01 Nov 2006 15:42:35 -0500 Date: Wed, 01 Nov 2006 15:42:34 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: OT: 2821bis (was: [EAI] ISSUE: framework 4.1 - reject) Message-ID: In-Reply-To: <4548EC36.5A27@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> <4546AA9A.16B@xyzzy.claranet.de> <45488896.64C8@xyzzy.claranet.de> <9D933E18C32AA7F4B1D9B526@p3.JCK.COM> <4548EC36.5A27@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 01 November, 2006 19:49 +0100 Frank Ellermann wrote: > John C Klensin wrote: > >>> I agree completely with our description of a backup MX > > s/our/your/ - I hope that typo was obvious. > >> This is a complex problem and, as has been pointed out, >> not one for this WG. > > Only the terminology, "reject" vs. "bounce", is relevant. The text has been clarified. See previous note. > Some say that the terms like "reverse path", "MAIL FROM", > "return-path", "envelope sender", etc. were always wrong, > and it should have been "bounces-to". They say STD 10 is > or rather was wrong. > > Others say these terms mean what they say, and that's no > bug. Folks who had the misfortune to be hit by thousands > of "misdirected bounces" tend to think that that's wrong. Having been hit by thousands of such bounces in one capacity or another, I continue to believe those terms mean what they say. >> Your insistent efforts to get your view written into the >> standard is one reason 2821bis has been permitted to >> quietly expire, but that is another issue. > > I don't agree that it's only my personal view. And nobody > could force you to write something into a draft-klensin-* > that you don't like. I was perfectly happy with your plan > to get it in a shape with all listed and unlisted errata > fixed, and then start a WG taking that state as its input. I didn't claim that it was only your personal view. I claimed (and claim) only that the amount of noise about changed requirements and changed definitions caused me to reach the point that I concluded I had more useful things to do with my time. > Compare , > you proposed to get rid of the term "bounce" in 2821bis-01 Indeed. And it was, if I recall, removed from the working draft... before I gave up. > Reading some of those old mails, it wasn't me who started > that old (2005) "reject vs. bounce" thread. That is correct, and I didn't mean to imply otherwise... only that introducing it into yet another context is not helpful. > And at that > time you wrote that you don't want to publish a -01 draft > before an 2822bis-00 is ready. That was your decision, and > all I contributed to that line of reasoning was that I'm > not exactly interested in a 2822bis before USEFOR is ready > (at the moment it's ready but not yet approved). As you presumably know, 2822bis has been posted. I don't know what the plans are for processing it if any exist. >> the notion of requiring the use of black (or grey) lists >> supplied by third parties is going to be operationally >> unacceptable to many server operators > > They can use their own black lists. "Greylisting" is a > local technique (unrelated to DNSBLs), for a definition see > > > And yes, I tried to get draft-irtf-asrg-dnsbl-02 published, > but it's trapped in some procedural limbo about IRTF RFCs - > or rather that's the last state I know (early 2006). > > Nobody (or at least not me) would expect that a new 2821bis > would *_require_* specific wild and wonderful things like > "greylisting", DNSBLs, 4408, call forward, and what else. > > I think you need a better reason than "Frank doesn't like > misdirected bounces" for the 2821bis issue, I forwarded the > announcement of 2821bis-00 to at least four groups (RFCI, SC, > SPF, dan-am) as the most interesting IETF event for years. Again, I didn't mean to imply "Frank doesn't like it" or "Frank is unhappy" was the issue. The issue was the balance between trying to deal with several proposals (from several people) that seemed to have the tone of "unless these protocol changes are made, 2821bis is just not worth the effort" and other ways to spend my, and, to the extent to which I'm entitled to an opinion, the IETF's, time. Put differently, it is my personal opinion that there is no way to advance either 2821bis or 2822bis without a fairly strong community consensus that those documents will represent clarifications and corrections to errors only. If it is necessary to have discussions about desired changes in practices, or even about whether particular changes have already occurred, then an update is fairly hopeless, at least given my impression of the level of energy people are willing to invest. john john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 15:54:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN6D-0000Iw-0H; Wed, 01 Nov 2006 15:54:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN6B-0000BN-5K for ima@ietf.org; Wed, 01 Nov 2006 15:54:11 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfN69-00081D-OO for ima@ietf.org; Wed, 01 Nov 2006 15:54:11 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfN60-0007o5-M1 for ima@ietf.org; Wed, 01 Nov 2006 21:54:00 +0100 Received: from pd9fba99f.dip0.t-ipconnect.de ([217.251.169.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 21:54:00 +0100 Received: from nobody by pd9fba99f.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 21:54:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] #1389: framework 4.1 - reject Date: Wed, 01 Nov 2006 21:49:41 +0100 Organization: Lines: 36 Message-ID: <45490865.56FA@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <4548A50A.1050102@alvestrand.no> <1C83043D52C72D00393A364F@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba99f.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > Is the above text sufficient It's good, but there are only four "bounce" in the document, and you can replace them all without an extra definition: - * Bounce the message so that the sender can make another plan. + * Reject or return the message so that the sender can make another plan. - available to reliably downgrade it, it MUST be bounced. + available to reliably downgrade it, it MUST be returned. - o Reject or bounce the message, requiring the sender to resubmit it + o Reject or return the message, requiring the sender to resubmit it = The first of these two options, that of rejecting or returning the - the internationalized form of the message is rejected or bounced by + the internationalized form of the message is rejected or returned by The "=" line meaning "as is", with that modification you can get rid of the last statement in your proposed text: - The term "bounce" is used informally below to cover both the rejection - and NDN cases. + If "bounce" is defined to be "reject or return" the existing "reject or bounce" part would be strange. The "MUST be bounced" (or returned) is no EAI-specific MUSTard, it's a 2821-MUST, maybe add the source (= 3.7, the famous "as indicated by the reverse-path" MUSTard). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 16:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNdR-000509-G2; Wed, 01 Nov 2006 16:28:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNdQ-0004xu-FK for ima@ietf.org; Wed, 01 Nov 2006 16:28:32 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNdM-00065m-7e for ima@ietf.org; Wed, 01 Nov 2006 16:28:32 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfNd9-0006SC-Vl for ima@ietf.org; Wed, 01 Nov 2006 22:28:15 +0100 Received: from pd9fba99f.dip0.t-ipconnect.de ([217.251.169.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 22:28:15 +0100 Received: from nobody by pd9fba99f.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Nov 2006 22:28:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: Wed, 01 Nov 2006 22:27:49 +0100 Organization: Lines: 64 Message-ID: <45491155.559F@xyzzy.claranet.de> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba99f.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: = > From: K=C3=A4ytt=C3=A4j=C3=A4tuki > From: K=C3=A4ytt=C3=A4j=C3=A4tuki > From: K=C3=A4ytt=C3=A4j=C3=A4tuki > From: K=C3=A4ytt=C3=A4j=C3=A4tuki = > How easy it is to parse ? This is un-ambiguous, but still quite = > dangerous. Easy, I don't see the danger here, can't be empty. = The [something] is always a . > angle-addr =3D [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-addres= s] > alt-address =3D [CFWS] "[" addr-spec "]" [CFWS] That has two adjacent [CFWS], you'd have to eliminate one - the prose in 2822 talking about adjacent CFWS is tricky (in essence saying that they're unintended, and MUST NOT result in anywhere) Extracting the alt-addr from the angle brackets makes me nervous. > angle-addr =3D [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFW= S] > alt-address =3D [CFWS] ',' addr-spec [CFWS] Comma is used in the obs-domain-list of an obs-angle-addr, I'm not sure if that's a good idea. > angle-addr =3D [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFW= S] > alt-address =3D [CFWS] ';' addr-spec [CFWS] Semicolon is IMO better than comma. > angle-addr =3D [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFW= S] > alt-address =3D [CFWS] "<" addr-spec ">" [CFWS] = > perhaps that is not so bad as it looks? No, it's interesting. = > angle-addr =3D [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-addres= s] > alt-address =3D [CFWS] "<" addr-spec ">" [CFWS] That's again the case of an extracted alt-address, and makes me again nervous - even more than above :-) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 16:32:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNhB-0000At-0r; Wed, 01 Nov 2006 16:32:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNhA-00009D-1j for ima@ietf.org; Wed, 01 Nov 2006 16:32:24 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNh8-0007G4-OA for ima@ietf.org; Wed, 01 Nov 2006 16:32:24 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfNh8-0005YV-AR; Wed, 01 Nov 2006 16:32:22 -0500 Date: Wed, 01 Nov 2006 16:32:21 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] #1389: framework 4.1 - reject Message-ID: In-Reply-To: <45490865.56FA@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <4548A50A.1050102@alvestrand.no> <1C83043D52C72D00393A364F@p3.JCK.COM> <45490865.56FA@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 01 November, 2006 21:49 +0100 Frank Ellermann wrote: > John C Klensin wrote: > >> Is the above text sufficient > > It's good, but there are only four "bounce" in the document, > and you can replace them all without an extra definition: > > - * Bounce the message so that the sender can make another > plan. + * Reject or return the message so that the sender can > make another plan. Still have to carefully define "reject" and "return". And "return" is going to imply full text and attachments to many people, which is definitely not a current requirement (and the notification request machinery purports to control this). > - available to reliably downgrade it, it MUST be bounced. > + available to reliably downgrade it, it MUST be returned. As I pointed out to Kari, while it would be unusual, there is always a chance of arranging things so that they can be rejected. >... I'll look at the rest of these. Harald and XiaoDong?? Instructions? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 17:36:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOh7-0000oQ-Te; Wed, 01 Nov 2006 17:36:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOh6-0000jy-9E for ima@ietf.org; Wed, 01 Nov 2006 17:36:24 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOh0-0002qP-MU for ima@ietf.org; Wed, 01 Nov 2006 17:36:24 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3^clerew#man#ac$uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 4549214e.10dad.1d3 for ima@ietf.org; Wed, 1 Nov 2006 22:35:58 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kA1MZkkN008821 for ; Wed, 1 Nov 2006 22:35:47 GMT To: "ima@ietf.org" Subject: Re: [EAI] #1388: framework -3 - missing MIME considerations References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> <5dfyd3tf2e.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Wed, 01 Nov 2006 22:35:46 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dfyd3tf2e.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 01 Nov 2006 14:30:17 -0000, Kari Hurtta wrote: > Harald Alvestrand writes in gmane.ietf.ima: > >> This issue has been assigned #1388. >> >> I believe the debate has shown: >> >> - The most controversial aspect here is whether message/rfc822 can be >> used for passing around UTF8SMTP messages or not. > > I think that message/rfc822 can be used for UTF8SMTP messages when > it is inside on UTF8SMTP environment, but message/rfc822 can not be > used for encapsulation. Yes, that is exactly my view, so that makes two of us. For encapsulation, we need something else, and it is likely to be somewhat ugly. But let us see your draft. My view is that we don't need encapsulation (i.e. we haven't found a pressing need for it yet). Therefore, we should leave that issue alone until a pressing need rears its igly head. I think that was John's view too. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 17:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOnM-00008k-NI; Wed, 01 Nov 2006 17:42:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOnK-00008H-LN for ima@ietf.org; Wed, 01 Nov 2006 17:42:50 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOnF-00048W-Jx for ima@ietf.org; Wed, 01 Nov 2006 17:42:50 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3*clerew#man#ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 454922df.9c93.283 for ima@ietf.org; Wed, 1 Nov 2006 22:42:39 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kA1MgcnR009241 for ; Wed, 1 Nov 2006 22:42:39 GMT To: "ima@ietf.org" Subject: Re: [EAI] #1389: framework 4.1 - reject References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <4548A50A.1050102@alvestrand.no> <1C83043D52C72D00393A364F@p3.JCK.COM> Message-ID: Date: Wed, 01 Nov 2006 22:42:37 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <1C83043D52C72D00393A364F@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 01 Nov 2006 14:30:03 -0000, John C Klensin wrote: > Done. Tentative language follows; tuning welcome: > > As specified in RFC 2821, a message that is > undeliverable for some reason is expected to result in > notification to the sender. This can occur in either of > two ways. One involves "rejection" by an SMTP server that > generates a command response that contains a reply code > indicating a fatal error (a "5yz" code). The other > involves accepting the message during SMTP processing and > then generating a message to the sender, typically known > as a "Non-delivery notification" or "NDN". Current > practice often favors rejection over NDNs because of the > reduced likelihood that the generation of NDN themselves > will be used as a spamming technique. The latter, NDN, > case is unavoidable if an intermediate MTA accepts a > message that is then rejected by the next-hop server. The > term "bounce" is used informally below to cover both the > rejection and NDN cases. I think I would prefer to use the word "bounce" for what you call NDN (and define it clearly so), and to use "reject" for when a 5xx response (or occasionaly a 4xx) is sent. And then to ensure all drafts follow that convention (that process of ensuring already seems to be under way). My belief is that that is how "bounce" is usually understood "out there", and that the term "NDN" would not be so easily recognised if used in its place. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 17:52:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOwK-0008DK-Cy; Wed, 01 Nov 2006 17:52:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOwJ-0008DB-4u for ima@ietf.org; Wed, 01 Nov 2006 17:52:07 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOwH-0006PW-Ib for ima@ietf.org; Wed, 01 Nov 2006 17:52:06 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3*clerew#man*ac$uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 45492512.25be.b6 for ima@ietf.org; Wed, 1 Nov 2006 22:52:02 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kA1MpvMq009814 for ; Wed, 1 Nov 2006 22:51:58 GMT To: "ima@ietf.org" Subject: Re: [EAI] #1391: framework 5 - delivery to final delivery MTA References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> Message-ID: Date: Wed, 01 Nov 2006 22:51:57 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 01 Nov 2006 15:48:04 -0000, John C Klensin wrote: > Proposed definition (new third paragraph of section 3); tuning > welcome: > > However, the term "final delivery MTA" is used in this > document in a fashion equivalent to the term "delivery > system" or "final delivery system" of RFC 2821. This > is the SMTP server that controls the format of, and is > permitted to inspect and interpret, local-part > addresses. It receives messages from the network for > delivery to mailboxes, rather than relaying. From the > perspective of the network, any local delivery > arrangements such as saving to a message store, handoff > to specific message delivery programs or agents, and > mechanisms for retrieving messages are all "behind" the > final delivery MTA and hence not part of the SMTP > transport or delivery process. In addition to message store, handoff to POP3/IMAP, etc., there is also the case of "forward to another address" (whether as part of a mailing list expansion or not, and whether with some change to the message or not. At that point (and especially where the is no change) it is back in the SMTP world, and becomes again subject to rejection, bouncing or downgrading, and finally arrives at yet another "final delivery MTA". I think your wording needs to include this case. In particular, it SHOULD NOT normally be upgraded at this point (that privilege should be reserved for the final final delivery MTA). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 18:00:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfP4D-0002mm-I2; Wed, 01 Nov 2006 18:00:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfP4B-0002mW-WB for ima@ietf.org; Wed, 01 Nov 2006 18:00:16 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfP48-00084u-1X for ima@ietf.org; Wed, 01 Nov 2006 18:00:15 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew*man*ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 454926ce.d4cd.4a9 for ima@ietf.org; Wed, 1 Nov 2006 22:59:26 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kA1MxNEb010270 for ; Wed, 1 Nov 2006 22:59:24 GMT To: "ima@ietf.org" Subject: Re: [EAI] Fwd: I-D ACTION:draft-duerst-mailto-bis-03.txt References: <6.0.0.20.2.20061026182815.05d4a530@localhost> <4541DB8F.5FD8@xyzzy.claranet.de> <6.0.0.20.2.20061029173555.04c54080@localhost> Message-ID: Date: Wed, 01 Nov 2006 22:59:23 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 31 Oct 2006 12:12:18 -0000, Charles Lindsey wrote: > And this WG would certainly expect to be consulted if some proposal to > include alt-addresses were to be incorporated. On further examination, it seems that the List-* headers mostly accept a comma-separated list of URIs (or maybe IRIs). So if you want a utf8-address and an alt-address, you can out two mailto:s there, and the user can click on whichever he wants or thinks will work. Yes, not as good as a genuine alt-address-within-a-mailto as Martin hopes to do, and I hope he still does it. But it does mean there is an interim solution for List-* headers, which could then take advantage of Martin's new mailto when it happens. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 18:33:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPZo-0003Br-Rf; Wed, 01 Nov 2006 18:32:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPZn-0003BC-70 for ima@ietf.org; Wed, 01 Nov 2006 18:32:55 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfPZl-0004Oj-Q4 for ima@ietf.org; Wed, 01 Nov 2006 18:32:55 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfPZl-0006Vy-6D for ima@ietf.org; Wed, 01 Nov 2006 18:32:53 -0500 Date: Wed, 01 Nov 2006 18:32:52 -0500 From: John C Klensin To: ima@ietf.org Subject: Re: [EAI] #1391: framework 5 - delivery to final delivery MTA Message-ID: <5829AF329F2EFCF1C2185460@p3.JCK.COM> In-Reply-To: References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 01 November, 2006 22:51 +0000 Charles Lindsey wrote: > On Wed, 01 Nov 2006 15:48:04 -0000, John C Klensin > wrote: > >> Proposed definition (new third paragraph of section 3); tuning >> welcome: >> >> However, the term "final delivery MTA" is used in this >> document in a fashion equivalent to the term "delivery >> system" or "final delivery system" of RFC 2821. This >> is the SMTP server that controls the format of, and is >> permitted to inspect and interpret, local-part >> addresses. It receives messages from the network for >> delivery to mailboxes, rather than relaying. From the >> perspective of the network, any local delivery >> arrangements such as saving to a message store, handoff >> to specific message delivery programs or agents, and >> mechanisms for retrieving messages are all "behind" the >> final delivery MTA and hence not part of the SMTP >> transport or delivery process. > > In addition to message store, handoff to POP3/IMAP, etc., > there is alsothe case of "forward to another address" (whether > as part of a mailinglist expansion or not, and whether with > some change to the message or not. > > At that point (and especially where the is no change) it is > back in theSMTP world, and becomes again subject to rejection, > bouncing ordowngrading, and finally arrives at yet another > "final delivery MTA". Ithink your wording needs to include > this case. In particular, it SHOULDNOT normally be upgraded at > this point (that privilege should be reservedfor the final > final delivery MTA). Charles, it is up to the WG as to where to draw the line, but I'm personally reluctant to reprise the model structure -- either of 2821 or of the document Dave Crocker is working on -- in the framework doc. Doing so would make the document longer, encourage people to believe that they don't really need to understand SMTP to understand this work, and introduce dependencies that are probably best avoided. It may be that some of the issues you raise should be addressed in the downgrade or mailing list documents, but my personal opinion is that we should keep "framework" away from post-delivery analyses. Again, just my personal opinion. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 19:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQC3-0003aT-9e; Wed, 01 Nov 2006 19:12:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQC2-0003a3-Jf for ima@ietf.org; Wed, 01 Nov 2006 19:12:26 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfQB9-0001X8-Gk for ima@ietf.org; Wed, 01 Nov 2006 19:11:32 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfQB8-00053G-Id for ima@ietf.org; Thu, 02 Nov 2006 01:11:30 +0100 Received: from pd9fba928.dip0.t-ipconnect.de ([217.251.169.40]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 01:11:30 +0100 Received: from nobody by pd9fba928.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 01:11:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 02 Nov 2006 01:07:56 +0100 Organization: Lines: 60 Message-ID: <454936DC.2B88@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> <4546AA9A.16B@xyzzy.claranet.de> <45488896.64C8@xyzzy.claranet.de> <9D933E18C32AA7F4B1D9B526@p3.JCK.COM> <4548EC36.5A27@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba928.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [EAI] Re: OT: 2821bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >> Others say these terms mean what they say, and that's no >> bug. Folks who had the misfortune to be hit by thousands >> of "misdirected bounces" tend to think that that's wrong. > Having been hit by thousands of such bounces in one capacity or > another, I continue to believe those terms mean what they say. The "wrong" was about the "some" (e.g. Dave), not about the "others" - it's good to hear that you're one of the "others". > the amount of noise about changed requirements and changed > definitions caused me to reach the point that I concluded > I had more useful things to do with my time. I'd love to replace the 1123 5.3.6(a) "feature" more quietly. Some good RFCs like 3834 depend on no-nonsense Return-Paths. Unfortunately I found nobody interested to extract at least the historical parts from 2821 (anything with source routes + SOML/SAML/SEND FROM cruft), in the hope that the rest might be just manageable for a 2821bis. > As you presumably know, 2822bis has been posted. No, I missed that, I didn't look into anything IETF for some weeks (April to July) after the IAB decision and 4408 AUTH48 for various reasons including a trailing dot - I found the SMTP-list thread where Ned convinced you to remove it again from your 2821bis draft much later. > I don't know what the plans are for processing it if any > exist. Apparently it's discussed "nowhere" (= not on any list I'm aware of, and googlebot claims also nowhere else), strange. If you say 2821bis was too noisy then the opposite isn't necessarily better. Maybe Bruce and others also missed it. > it is my personal opinion that there is no way to advance > either 2821bis or 2822bis without a fairly strong community > consensus that those documents will represent clarifications > and corrections to errors only. 2822 is fairly clear, either you like NO-WS-CTL, or you don't like it, it can be fixed or kept as is, plus similar details. The most exciting point could be "do we really want Resent-* as specified, or can we please deprecate it ?" Or in theory "fix" it to be compatible with 4406. Or if all fails update 4409 8.1, that's at least in a kind of "text proposed" state. 2821 on the other hand is a hard case. It's long. Everybody has his or her favourite way to read it. Splitting it into smaller pieces might help. E.g. it should be possible to get a consensus for a clean ABNF. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 19:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQNC-0002Aw-P3; Wed, 01 Nov 2006 19:23:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQNC-0002Aq-2o for ima@ietf.org; Wed, 01 Nov 2006 19:23:58 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfQNA-0003yj-EV for ima@ietf.org; Wed, 01 Nov 2006 19:23:57 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfQN7-0006ox-Uk for ima@ietf.org; Wed, 01 Nov 2006 19:23:54 -0500 Date: Wed, 01 Nov 2006 19:23:53 -0500 From: John C Klensin To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [EAI] knowing the encoding for something before it is encountered X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi. Several ideas have been floating around that seem to violate, or come close to violating, a design principle for email and some other systems. Maybe it is worth trying to articulate that design principle. The principle is that we insist on know the content structure (to the extent possible) and the encoding before you get the content or values. In particular, one should not have to parse something and then back up when one figures out how material already encountered is to be interpreted, nor should one need to do heuristics to figure out what something is. Traditional MIME conforms exactly to that rule: one knows that the headers are in ASCII, the main header can contain a content-type and content-transfer-encoding that specify the structure and encoding of the body, but all of that header material is in ASCII so there are no encoding issues with it. There are no headers that say "go back and reinterpret all of the other headers in some other way". In addition, the internal MIME headers are entirely in ASCII. That has proven to be a good thing because it is common practice to slice body parts out of messages (in MUAs and the like, after delivery) and treat them in separate ways. Needing some remote information (e.g., in the main headers) to find out how internal MIME headers are encoded makes that task considerably more difficult and implies that one must build up and carry much more message structure to handle them. As we move into the UTF8SMTP world, we get onto slippery slopes with this. We can do UTF-8 in headers because the envelope tells us that they may be coming (and because ASCII characters are proper UTF-8). But, once the envelope is stripped away, we are proposing to rely on a header that changes the encoding of other headers, which would be pretty close to a first. We are also looking at proposals to change the coding of parts of both the main content-type header and of internal MIME headers based on that header field. That isn't necessarily bad, but it is a little scary, at least to me. And I think we should all at least try to understand the issues. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 01 22:39:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfTPk-0006or-NR; Wed, 01 Nov 2006 22:38:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfTPj-0006od-Bd for ima@ietf.org; Wed, 01 Nov 2006 22:38:47 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfTPh-0003xm-Vg for ima@ietf.org; Wed, 01 Nov 2006 22:38:47 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GfTPh-0008Tu-DT for ima@ietf.org; Wed, 01 Nov 2006 22:38:45 -0500 Date: Wed, 01 Nov 2006 22:38:44 -0500 From: John C Klensin To: ima@ietf.org Subject: Re: [EAI] #1388: framework -3 - missing MIME considerations Message-ID: X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 01 November, 2006 22:35 +0000 Charles Lindsey wrote: >> I think that message/rfc822 can be used for UTF8SMTP >> messages when it is inside on UTF8SMTP environment, but >> message/rfc822 can not be used for encapsulation. > > Yes, that is exactly my view, so that makes two of us. While this would probably meet the criterion of "knowing the encoding for something before it is encountered" (see next note), it makes me a little anxious. I've raised the question off-list with a few MIME experts (including those who specified that content type); either Harald or I will report back when we've heard from them. FWIW, a recent IM note from one of them prominently featured the technical term "Ick" in his description of the situation :-(. > For encapsulation, we need something else, and it is likely to > be somewhatugly. But let us see your draft. > > My view is that we don't need encapsulation (i.e. we haven't > found apressing need for it yet). Therefore, we should leave > that issue aloneuntil a pressing need rears its igly head. I > think that was John's viewtoo. To be a little more precise, I am quite convinced that there is a case for which we need encapsulation. But I don't see it on the WG Charter, so I hope we can convince ourselves it is possible and then avoid getting tangled up in it. The extreme version of that case involves a user who is UTF8SMTP-capable receiving a message at her UTF8SMTP address that contains UTF-8 headers, etc. She then decides to forward the message, as an attachment (additional body part) to an ASCII-only user with a first body part containing a textual introduction in ASCII text. The only way to construct that attachment requires some sort of encapsulation of the incoming, UTF8SMTP, message. Note that there is no on-the-wire or automated downgrade environment here; _everything_ that needs to be done must be done in the user's MUA environment. Also note that there are a number of variations on this scenario, but most of them require the same type of encapsulation. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 00:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfUgU-0008KS-Bc; Thu, 02 Nov 2006 00:00:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfUgS-0008KM-84 for ima@ietf.org; Thu, 02 Nov 2006 00:00:08 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfUgP-0005GD-UQ for ima@ietf.org; Thu, 02 Nov 2006 00:00:08 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfUgF-0000cH-J3 for ima@ietf.org; Thu, 02 Nov 2006 05:59:55 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 05:59:55 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 05:59:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: 02 Nov 2006 06:59:39 +0200 Lines: 40 Message-ID: <5dlkmujves.fsf@Hurtta06k.keh.iki.fi> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <45491155.559F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > > From: Käyttäjätuki > > From: Käyttäjätuki > > From: Käyttäjätuki > > From: Käyttäjätuki > > > How easy it is to parse ? This is un-ambiguous, but still quite > > dangerous. > > Easy, I don't see the danger here, can't be empty. > The [something] is always a . Yes. It is un-ambiguous. I was more considered how tokenizer can be used. Käyttäjätuki Maybe someone want tokekize as Käyttäjätuki WSP < Käyttäjätuki @ [something] [ support @ [something] ] > On there was problem [ versus [something] selection/conflict. That is easy if top-down parser is used, but not otherwise. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 01:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfVga-0008Ei-2p; Thu, 02 Nov 2006 01:04:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfVgY-0008EV-Bl for ima@ietf.org; Thu, 02 Nov 2006 01:04:18 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfVgW-0003km-R9 for ima@ietf.org; Thu, 02 Nov 2006 01:04:18 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfVgK-0000l4-Ty for ima@ietf.org; Thu, 02 Nov 2006 07:04:04 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 07:04:04 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 07:04:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: multipart/report (Re: [EAI] #1388: framework -3 - missing MIME considerations) Date: 02 Nov 2006 08:03:55 +0200 Lines: 46 Message-ID: <5dhcxijsfo.fsf_-_@Hurtta06k.keh.iki.fi> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand writes in gmane.ietf.ima: > This issue has been assigned #1388. > > I believe the debate has shown: > > - The most controversial aspect here is whether message/rfc822 can be > used for passing around UTF8SMTP messages or not. > - There are multiple people who think that doing so is asking for > trouble, so we should do something else, and one person (Charles) who > believes that it should be so used. > - A separate draft, draft-hurtta-eai-encapsulation, has been written, > but not submitted (kari, can you get it onto a website somewhere? If > necessary, send it to me..), detailing one "something else" First thing where these are needed are non delivery reports ie. multipart/report. Normally there is multipart/report text/plain message/delivery-status text/rfc822-headers or multipart/report text/plain message/delivery-status message/rfc822 Either text/rfc822-headers and message/rfc822 specification need to be changed or these types need to be replaced with some other types. draft-hurtta-eai-encapsulation-00 gives types text/rfc822-headers => text/utf8-header message/rfc822 => multipart/multipart/utf8-encapsulated; type=message although these types was not proposed for multipart/report / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 01:17:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfVtj-00010S-4F; Thu, 02 Nov 2006 01:17:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfVth-00010M-MQ for ima@ietf.org; Thu, 02 Nov 2006 01:17:53 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfVtg-0007Y2-CX for ima@ietf.org; Thu, 02 Nov 2006 01:17:53 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfVtW-0002hK-Sd for ima@ietf.org; Thu, 02 Nov 2006 07:17:42 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 07:17:42 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 07:17:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] knowing the encoding for something before it is encountered Date: 02 Nov 2006 08:17:35 +0200 Lines: 39 Message-ID: <5dac3ajrsw.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes in gmane.ietf.ima: <...> > As we move into the UTF8SMTP world, we get onto slippery slopes > with this. We can do UTF-8 in headers because the envelope > tells us that they may be coming (and because ASCII characters > are proper UTF-8). But, once the envelope is stripped away, we > are proposing to rely on a header that changes the encoding of > other headers, which would be pretty close to a first. We are > also looking at proposals to change the coding of parts of both > the main content-type header and of internal MIME headers based > on that header field. That isn't necessarily bad, but it is a > little scary, at least to me. And I think we should all at > least try to understand the issues. > > john Yes. I also asked that why UTF8SMTP do not need parameter on SMTP when 8BITMIME uses BODY=UTF8SMTP parameter. So if outside indicator is need then it means 1) HDR=UTF8 parameter is needed for MAIL -command 2) message/rfc822 need to be replaced with somewhat else, ie. message/utf8 or application/utf8-message ( or with that encapsulation was on my draft ) 3) text/rfc822-headers need be replaced with something else ie. text/utf8-header (that was from my draft) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 03:21:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXoI-0004ma-Bs; Thu, 02 Nov 2006 03:20:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXoH-0004mV-CX for ima@ietf.org; Thu, 02 Nov 2006 03:20:25 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfXoB-00032v-V3 for ima@ietf.org; Thu, 02 Nov 2006 03:20:25 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfXo9-0005CY-50 for ima@ietf.org; Thu, 02 Nov 2006 09:20:17 +0100 Received: from pd9fba965.dip0.t-ipconnect.de ([217.251.169.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 09:20:17 +0100 Received: from nobody by pd9fba965.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 09:20:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 02 Nov 2006 09:19:17 +0100 Organization: Lines: 21 Message-ID: <4549AA05.465C@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> <5dbqnrt7ta.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba965.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [EAI] Re: draft-hurtta-eai-encapsulation X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > http://www.elmme-mailer.org/ID/draft-hurtta-eai-encapsulation-00.txt Thanks, I'm not ready with reading it, a first impression: A mail with UTF-8 headers can be a mixture of "raw" UTF-8 + MIME-encoding like 2047. When it's downgraded some UTF-8 headers end up 2047-encoded. When it's upgraded it will be again a mixture, but potentially a _different_ mixture, of UTF-8 and MIME-magic. "Different" could cause havoc for signatures. But with encapsulation it's reconstructed as it was before the downgrade. Is that on track, one of the problems you try to solve ? The text/utf8-header for a multipart/report is clear. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 03:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXsO-0008O8-GD; Thu, 02 Nov 2006 03:24:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXsL-0008O3-Qf for ima@ietf.org; Thu, 02 Nov 2006 03:24:37 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfXsK-0003cz-GC for ima@ietf.org; Thu, 02 Nov 2006 03:24:37 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64E522596BD for ; Thu, 2 Nov 2006 09:21:46 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31717-07 for ; Thu, 2 Nov 2006 09:21:39 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CF4E2580C6 for ; Thu, 2 Nov 2006 09:21:39 +0100 (CET) Message-ID: <4549AB3C.8050409@alvestrand.no> Date: Thu, 02 Nov 2006 00:24:28 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [EAI] DRAFT meeting agenda, EAI meeting in San Diego X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This is a DRAFT agenda. Apologies for its lateness. Please make proposals for changes ASAP! Date: Thursday, November 9, 2006 Time: 1300-1500 Place: Spinnaker Agenda: 1300: Welcome, scribes, blue sheet, agenda bashing 1310: Verification of Last Call resolutions, Framework Document: draft-ietf-eai-framework-02 1315: Open issues, -smtpext Document: draft-ietf-eai-smtpext-02 Known issues: - ORCPT and DSN support 1330: Open issues, -utf8headers and -downgrade Documents: http://www.twnic.net.tw/jeff/draft-ietf-eai-utf8headers-02.txt draft-ietf-eai-downgrade-02.txt 1415: Open issues, end-system operations Documents (unchanged since before Montreal): draft-ietf-eai-pop-00.txt draft-ietf-eai-imap-utf8-00.txt draft-ietf-eai-mailinglist-00.txt 1430: Related issues, other documents http://www.elmme-mailer.org/ID/draft-hurtta-eai-encapsulation-00.txt draft-duerst-mailto-bis-03.txt draft-ietf-eai-scenarios-01.txt 1445: Summary of decisions and action items 1500: End of meeting _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 03:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYHd-0002Fb-G5; Thu, 02 Nov 2006 03:50:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYHc-0002FW-4U for ima@ietf.org; Thu, 02 Nov 2006 03:50:44 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfYHW-0008FD-Qn for ima@ietf.org; Thu, 02 Nov 2006 03:50:44 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfYHM-0001ha-8i for ima@ietf.org; Thu, 02 Nov 2006 09:50:28 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 09:50:28 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 09:50:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: draft-hurtta-eai-encapsulation Date: 02 Nov 2006 10:50:51 +0200 Lines: 31 Message-ID: <5dfyd2s044.fsf@leija.fmi.fi> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> <5dbqnrt7ta.fsf_-_@Hurtta06k.keh.iki.fi> <4549AA05.465C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > > http://www.elmme-mailer.org/ID/draft-hurtta-eai-encapsulation-00.txt > > Thanks, I'm not ready with reading it, a first impression: > > A mail with UTF-8 headers can be a mixture of "raw" UTF-8 > + MIME-encoding like 2047. When it's downgraded some > UTF-8 headers end up 2047-encoded. When it's upgraded > it will be again a mixture, but potentially a _different_ > mixture, of UTF-8 and MIME-magic. > > "Different" could cause havoc for signatures. But with > encapsulation it's reconstructed as it was before the > downgrade. Is that on track, one of the problems you > try to solve ? Yes. Another one was trying to not invoke signature checking when message is downgraded. There was also some other usages. > The text/utf8-header for a multipart/report is clear. > > Frank / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 04:47:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZAQ-0005En-OZ; Thu, 02 Nov 2006 04:47:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZAQ-00058p-1b for ima@ietf.org; Thu, 02 Nov 2006 04:47:22 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfZAO-0002xw-Ii for ima@ietf.org; Thu, 02 Nov 2006 04:47:22 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 696EC2596BF; Thu, 2 Nov 2006 10:44:30 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01225-03; Thu, 2 Nov 2006 10:44:24 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3310B2596BE; Thu, 2 Nov 2006 10:44:24 +0100 (CET) Message-ID: <4549BEA1.7060503@alvestrand.no> Date: Thu, 02 Nov 2006 01:47:13 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] #1389: framework 4.1 - reject References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <4548A50A.1050102@alvestrand.no> <1C83043D52C72D00393A364F@p3.JCK.COM> <45490865.56FA@xyzzy.claranet.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I think Frank has a point that you don't need the term "bounce", and it's easier to remove it than to define it (especially as that was already done in the 2821bis work). I don't like "it must be returned" either, "an error report must be returned" is more correct (the error report may or may not include the whole message). If you want to define a term for "return an error report", that's OK with me. Unless I hear shouts from the WG, you can take that as chair's guidance. Harald John C Klensin wrote: > --On Wednesday, 01 November, 2006 21:49 +0100 Frank Ellermann > wrote: > > >> John C Klensin wrote: >> >> >>> Is the above text sufficient >>> >> It's good, but there are only four "bounce" in the document, >> and you can replace them all without an extra definition: >> >> - * Bounce the message so that the sender can make another >> plan. + * Reject or return the message so that the sender can >> make another plan. >> > > Still have to carefully define "reject" and "return". And > "return" is going to imply full text and attachments to many > people, which is definitely not a current requirement (and the > notification request machinery purports to control this). > > >> - available to reliably downgrade it, it MUST be bounced. >> + available to reliably downgrade it, it MUST be returned. >> > > As I pointed out to Kari, while it would be unusual, there is > always a chance of arranging things so that they can be rejected. > > >> ... >> > > I'll look at the rest of these. > Harald and XiaoDong?? Instructions? > > john > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 06:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfaiY-0007pc-0W; Thu, 02 Nov 2006 06:26:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfaiW-0007pX-Kj for ima@ietf.org; Thu, 02 Nov 2006 06:26:40 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfaiO-0005ih-ON for ima@ietf.org; Thu, 02 Nov 2006 06:26:40 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew*man^ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.235) id 4549d5e4.16b31.1854 for ima@ietf.org; Thu, 2 Nov 2006 11:26:28 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kA2BQQHE020479 for ; Thu, 2 Nov 2006 11:26:27 GMT To: "ima@ietf.org" Subject: Re: [EAI] #1391: framework 5 - delivery to final delivery MTA References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> <5829AF329F2EFCF1C2185460@p3.JCK.COM> Message-ID: Date: Thu, 02 Nov 2006 11:26:25 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5829AF329F2EFCF1C2185460@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 01 Nov 2006 23:32:52 -0000, John C Klensin wrote: > --On Wednesday, 01 November, 2006 22:51 +0000 Charles Lindsey > wrote: >> >> At that point (and especially where the is no change) it is >> back in theSMTP world, and becomes again subject to rejection, >> bouncing ordowngrading, and finally arrives at yet another >> "final delivery MTA". Ithink your wording needs to include >> this case. In particular, it SHOULDNOT normally be upgraded at >> this point (that privilege should be reservedfor the final >> final delivery MTA). > > Charles, it is up to the WG as to where to draw the line, but > I'm personally reluctant to reprise the model structure -- > either of 2821 or of the document Dave Crocker is working on -- > in the framework doc. Doing so would make the document longer, > encourage people to believe that they don't really need to > understand SMTP to understand this work, and introduce > dependencies that are probably best avoided. I think the only point that needs to be made is that the "final delivery agent" as you have defined it may not be as "final" as it sounds, insofar as there may yet be a "final final delivery agent" (or even final**n). What I have in mind is simple forwarding by some /etc/aliases or ,forward file, rather than a full-fledged list expander. > > It may be that some of the issues you raise should be addressed > in the downgrade or mailing list documents, but my personal > opinion is that we should keep "framework" away from > post-delivery analyses. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 07:14:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfbSO-0003AU-CI; Thu, 02 Nov 2006 07:14:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfbSN-0003AP-Eh for ima@ietf.org; Thu, 02 Nov 2006 07:14:03 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfbSJ-0002PC-DK for ima@ietf.org; Thu, 02 Nov 2006 07:14:03 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew*man*ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.235) id 4549e0f8.bb23.21b5 for ima@ietf.org; Thu, 2 Nov 2006 12:13:44 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kA2CDfgN023521 for ; Thu, 2 Nov 2006 12:13:43 GMT To: "ima@ietf.org" Subject: Re: [EAI] knowing the encoding for something before it is encountered References: <5dac3ajrsw.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Thu, 02 Nov 2006 12:13:40 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dac3ajrsw.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 02 Nov 2006 06:17:35 -0000, Kari Hurtta wrote: > Yes. I also asked that why UTF8SMTP do not need parameter > on SMTP when 8BITMIME uses BODY=UTF8SMTP parameter. > > So if outside indicator is need then it means > > 1) HDR=UTF8 parameter is needed for MAIL -command Yes, I can see some merit in that. With that in place, then all MTAs would be aware that the message might require more careful scrutiny for places that might need to be downgraded. MDAs (whatever they are) would know, because the MTAs that delivered to them would tell them. Sending MUAs would know because they constructed it that way. So it only leaves gateways that might have to scan the whole message looking for Header-Type: UTF8 and gateways nearly always get involved in messy processing such as scanning things twice. Actually, it should only be necessary to scan the top-level header-fields for that Header-Type header, and only look further if it was present. > > 2) message/rfc822 need to be replaced with somewhat else, Or else they need to occur only in an environment which is protected as in (1) (with messiness in gateways as usual), -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 09:07:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfdDB-0003qR-Rt; Thu, 02 Nov 2006 09:06:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfdDB-0003qM-AX for ima@ietf.org; Thu, 02 Nov 2006 09:06:29 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfdD6-0006O4-SU for ima@ietf.org; Thu, 02 Nov 2006 09:06:29 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 2 Nov 2006 14:06:13 +0000 Message-ID: <4549FB4B.7090304@isode.com> Date: Thu, 02 Nov 2006 14:06:03 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kari Hurtta Subject: Re: multipart/report (Re: [EAI] #1388: framework -3 - missing MIME considerations) References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> <5dhcxijsfo.fsf_-_@Hurtta06k.keh.iki.fi> In-Reply-To: <5dhcxijsfo.fsf_-_@Hurtta06k.keh.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: >Harald Alvestrand writes in gmane.ietf.ima: > > > >>This issue has been assigned #1388. >> >>I believe the debate has shown: >> >>- The most controversial aspect here is whether message/rfc822 can be >>used for passing around UTF8SMTP messages or not. >>- There are multiple people who think that doing so is asking for >>trouble, so we should do something else, and one person (Charles) who >>believes that it should be so used. >>- A separate draft, draft-hurtta-eai-encapsulation, has been written, >>but not submitted (kari, can you get it onto a website somewhere? If >>necessary, send it to me..), detailing one "something else" >> >> > >First thing where these are needed are non delivery reports >ie. multipart/report. > >Normally there is > multipart/report > text/plain > message/delivery-status > text/rfc822-headers > >or > > multipart/report > text/plain > message/delivery-status > message/rfc822 > > >Either text/rfc822-headers and message/rfc822 specification need >to be changed or these types need to be replaced with some other types. > > Correct. Note that message/delivery-status has to be updated as well to allow for UTF-8. Chris Newman and I are planning to discuss issues related to DSN reports next week. >draft-hurtta-eai-encapsulation-00 gives types > > text/rfc822-headers => text/utf8-header > > message/rfc822 => multipart/multipart/utf8-encapsulated; type=message > >although these types was not proposed for multipart/report > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 09:30:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfdaV-0005Ok-TL; Thu, 02 Nov 2006 09:30:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfdaU-0005Od-Jv for ima@ietf.org; Thu, 02 Nov 2006 09:30:34 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfdaQ-0003RI-4g for ima@ietf.org; Thu, 02 Nov 2006 09:30:34 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gfda9-0006fH-UB for ima@ietf.org; Thu, 02 Nov 2006 15:30:14 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 15:30:13 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 15:30:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] knowing the encoding for something before it is encountered Date: 02 Nov 2006 16:30:38 +0200 Lines: 65 Message-ID: <5d8xit2a5t.fsf@leija.fmi.fi> References: <5dac3ajrsw.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Thu, 02 Nov 2006 06:17:35 -0000, Kari Hurtta > wrote: > > > Yes. I also asked that why UTF8SMTP do not need parameter > > on SMTP when 8BITMIME uses BODY=UTF8SMTP parameter. > > > > So if outside indicator is need then it means > > > > 1) HDR=UTF8 parameter is needed for MAIL -command > > Yes, I can see some merit in that. With that in place, then all MTAs > would be aware that the message might require more careful scrutiny > for places that might need to be downgraded. MDAs (whatever they are) > would know, because the MTAs that delivered to them would tell > them. Sending MUAs would know because they constructed it that way. > > So it only leaves gateways that might have to scan the whole message > looking for > Header-Type: UTF8 > and gateways nearly always get involved in messy processing such as > scanning things twice. Actually, it should only be necessary to scan > the top-level header-fields for that Header-Type header, and only > look further if it was present. > > > > > 2) message/rfc822 need to be replaced with somewhat else, > > Or else they need to occur only in an environment which is protected > as in (1) (with messiness in gateways as usual), On someway that can also follow 1) ie. Content-Type: message/rfc822; hdr=UTF8 if UTF8 on top level do not imply that all attached messages also are UTF8SMTP messages. I think that it (UTF8 on top level) does not necessary imply that. So indication may be still needed. Anyway attached UTF8SMTP means that top level is also UTF8. If top level is not UTF8, then that, what I suggested on my encapsulation draft, is needed. (or application/utf8-message, but I think that this is not wanted.) After all that UTF8 flag makes difference, Is message using some unknown 8-bit headers (very many system uses raw 8-bit ISO-8859-* charcters on subject without any labeling) versus Is UTF8 expected / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 09:31:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfdbc-0005VH-PU; Thu, 02 Nov 2006 09:31:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfdba-0005VC-O8 for ima@ietf.org; Thu, 02 Nov 2006 09:31:42 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfdbW-0003jc-85 for ima@ietf.org; Thu, 02 Nov 2006 09:31:42 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E14472596C0; Thu, 2 Nov 2006 15:28:47 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07858-09; Thu, 2 Nov 2006 15:28:42 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A59552596BE; Thu, 2 Nov 2006 15:28:42 +0100 (CET) Message-ID: <454A0144.7050301@alvestrand.no> Date: Thu, 02 Nov 2006 06:31:32 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] #1391: framework 5 - delivery to final delivery MTA References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Wed, 01 Nov 2006 15:48:04 -0000, John C Klensin > wrote: > >> Proposed definition (new third paragraph of section 3); tuning >> welcome: >> >> However, the term "final delivery MTA" is used in this >> document in a fashion equivalent to the term "delivery >> system" or "final delivery system" of RFC 2821. This >> is the SMTP server that controls the format of, and is >> permitted to inspect and interpret, local-part >> addresses. It receives messages from the network for >> delivery to mailboxes, rather than relaying. From the >> perspective of the network, any local delivery >> arrangements such as saving to a message store, handoff >> to specific message delivery programs or agents, and >> mechanisms for retrieving messages are all "behind" the >> final delivery MTA and hence not part of the SMTP >> transport or delivery process. > > In addition to message store, handoff to POP3/IMAP, etc., there is > also the case of "forward to another address" (whether as part of a > mailing list expansion or not, and whether with some change to the > message or not. > > At that point (and especially where the is no change) it is back in > the SMTP world, and becomes again subject to rejection, bouncing or > downgrading, and finally arrives at yet another "final delivery MTA". > I think your wording needs to include this case. In particular, it > SHOULD NOT normally be upgraded at this point (that privilege should > be reserved for the final final delivery MTA). If it is part of alias expansion (no change to envelope sender), the MTA is not final. If it is part of mailing list expansion (change to envelope sender), the MTA is final. The fact that it's hard to tell from a Sendmail aliases file which one is taking place is a Sendmail problem, not a problem with the Internet mail architecture. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 10:32:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeY9-0006AY-53; Thu, 02 Nov 2006 10:32:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeY7-0006AT-HT for ima@ietf.org; Thu, 02 Nov 2006 10:32:11 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfeY0-0005zV-U6 for ima@ietf.org; Thu, 02 Nov 2006 10:32:11 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfeXK-0001P9-BF for ima@ietf.org; Thu, 02 Nov 2006 16:31:22 +0100 Received: from d253154.dialin.hansenet.de ([80.171.253.154]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 16:31:22 +0100 Received: from nobody by d253154.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 16:31:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: smtpext MAIL keyword (was: [EAI] #1391: framework 5 - delivery to final delivery MTA) Date: Thu, 02 Nov 2006 16:27:06 +0100 Organization: Lines: 48 Message-ID: <454A0E4A.7CF4@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> <5829AF329F2EFCF1C2185460@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253154.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > I think the only point that needs to be made is that the "final delivery > agent" as you have defined it may not be as "final" as it sounds, insofar > as there may yet be a "final final delivery agent" (or even final**n). > What I have in mind is simple forwarding by some /etc/aliases or ,forward > file, rather than a full-fledged list expander. Yes, that's discussed in 2821 4.4, bottom of page 50, "it is sometimes difficult" etc. And at the begin, the abstractions like "final delivery MTA" can depend on the circumstances (2.2.3), "However, while these terms are used with the appearance of great precision" etc. Is there something special wrt EAI ? Kari's proposal that we might need some ESMTP keyword for the MAIL FROM is interesting: EHLO i18n.client.example MAIL FROM:<=E4=F6=FC@=FC=E4=F6.example> ALT-ADDRESS=3Daeoeue@ueoeae.exam= ple RCPT TO: RCPT TO: That's obvious, no extra keyword needed, the server can simply reject all RCPT TO addresses where it knows that it can't downgrade for some reason. Without optional ALT-ADDRESS it's not obvious, the server doesn't know if it should reject the message to "un-downgradable" receivers: EHLO i18n.client.example MAIL FROM: RCPT TO: RCPT TO: DATA Header-Type: UTF8 [...] In theory it could look "into" the mail, "see" the Header-Type: UTF8, and say "thanks, but no thanks" after DATA for all recipients if some of them are "un-downgradable". But it should better get a clue before DATA in the MAIL FROM, then it can reject RCPT TO selectively. For an UTF-8 MAIL FROM:<=E4=F6=FC.=FC=F6=E4.example> that's overkill, the= server would "see" that this is not US-ASCII. But for an ASCII MAIL FROM waiting until DATA with "Header-Type: UTF8" is too late for selective rejects. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 10:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfexW-0002v4-PS; Thu, 02 Nov 2006 10:58:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfexV-0002uz-7k for ima@ietf.org; Thu, 02 Nov 2006 10:58:25 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfexR-0000F0-BR for ima@ietf.org; Thu, 02 Nov 2006 10:58:25 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gfeww-0006wy-5m for ima@ietf.org; Thu, 02 Nov 2006 16:57:50 +0100 Received: from d253154.dialin.hansenet.de ([80.171.253.154]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 16:57:50 +0100 Received: from nobody by d253154.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 16:57:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: Thu, 02 Nov 2006 16:56:26 +0100 Organization: Lines: 18 Message-ID: <454A152A.2085@xyzzy.claranet.de> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <45491155.559F@xyzzy.claranet.de> <5dlkmujves.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253154.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > I was more considered how tokenizer can be used. What would you like better ? I'm not sure about the proposals with the alt-address outside of i.e. behind the ">", and about a comma as separator as in . IIRC John didn't like to add "{" and "}". You had more proposals: > and If that's later inserted as is in a cc= or similar of a 2368ter mailto: using semicolon could be a bad idea. Folks try to replace "&" in query parts by ";", and complex rules where some semicolons have to be percent-encoded and others not aren't attractive. If that makes sense > is an alternative for . Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 11:55:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GffqA-0004gg-PF; Thu, 02 Nov 2006 11:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gffq9-0004gY-4x for ima@ietf.org; Thu, 02 Nov 2006 11:54:53 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gffpw-0006Oe-MG for ima@ietf.org; Thu, 02 Nov 2006 11:54:53 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gffpf-0003Mm-CO for ima@ietf.org; Thu, 02 Nov 2006 17:54:23 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 17:54:23 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 17:54:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: 02 Nov 2006 18:54:04 +0200 Lines: 29 Message-ID: <5dac39ssb7.fsf@Hurtta06k.keh.iki.fi> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <45491155.559F@xyzzy.claranet.de> <5dlkmujves.fsf@Hurtta06k.keh.iki.fi> <454A152A.2085@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > > I was more considered how tokenizer can be used. > > What would you like better ? I'm not sure about the proposals with > the alt-address outside of i.e. behind the ">", and about a > comma as separator as in . IIRC John didn't like to add > "{" and "}". You had more proposals: > and > > If that's later inserted as is in a cc= or similar of a 2368ter > mailto: using semicolon could be a bad idea. Folks try to replace > "&" in query parts by ";", and complex rules where some semicolons > have to be percent-encoded and others not aren't attractive. > > If that makes sense > is an alternative for . That > seems workable. ( But there maybe something what I do not have thinked. Someone may perhaps reduce > to but I do not think that this is problem. ) > Frank / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 20:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfoIR-0001Yk-U2; Thu, 02 Nov 2006 20:56:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfoIQ-0001Tv-Qe for ima@ietf.org; Thu, 02 Nov 2006 20:56:38 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfoIM-0004xY-Ui for ima@ietf.org; Thu, 02 Nov 2006 20:56:38 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kA31uVmV011291 for ; Fri, 3 Nov 2006 10:56:31 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 475c_86db4334_6ade_11db_8d83_0014221fa3c9; Fri, 03 Nov 2006 10:56:31 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:34910) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 3 Nov 2006 10:56:05 +0900 Message-Id: <6.0.0.20.2.20061102171637.0686ea70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 02 Nov 2006 17:22:20 +0900 To: Kari Hurtta , ima@ietf.org From: Martin Duerst Subject: Re: multipart/report (Re: [EAI] #1388: framework -3 - missing MIMEconsiderations) In-Reply-To: <5dhcxijsfo.fsf_-_@Hurtta06k.keh.iki.fi> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> <5dhcxijsfo.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org In this context, I'd like to reiterate my proposal for making non-delivery reports standardized enough that a MUA could automatically resend (or, as much as possible, help the user to resend) a mail with fallback addresses if it got stuck somewhere. So the scenario would be: Mail with UTF-8 address sent -> passes some SMTP servers -> hits an SMTP server that doesn't downgrade, but sends back a non-delivery report -> report gets back, ultimately to MUA -> MUA analyses, finds out that the report indeed is for a mail it sent (one has to be careful these days because of all the spam around) and that it's because of the UTF-8 address -> mailer prepares the mail again, this time with the alt address -> mail is sent again I'm not sure whether or not this is already possible, but it sure would help MUAs and probably also the adoption of UTF8SMTP (an error that has an easy solution is much less of an obstacle than an error without obvious solution for a non-expert user). Regards, Martin. At 15:03 06/11/02, Kari Hurtta wrote: >Harald Alvestrand writes in gmane.ietf.ima: > >> This issue has been assigned #1388. >> >> I believe the debate has shown: >> >> - The most controversial aspect here is whether message/rfc822 can be >> used for passing around UTF8SMTP messages or not. >> - There are multiple people who think that doing so is asking for >> trouble, so we should do something else, and one person (Charles) who >> believes that it should be so used. >> - A separate draft, draft-hurtta-eai-encapsulation, has been written, >> but not submitted (kari, can you get it onto a website somewhere? If >> necessary, send it to me..), detailing one "something else" > > >First thing where these are needed are non delivery reports >ie. multipart/report. > >Normally there is > multipart/report > text/plain > message/delivery-status > text/rfc822-headers > >or > > multipart/report > text/plain > message/delivery-status > message/rfc822 > > >Either text/rfc822-headers and message/rfc822 specification need >to be changed or these types need to be replaced with some other types. > >draft-hurtta-eai-encapsulation-00 gives types > > text/rfc822-headers => text/utf8-header > > message/rfc822 => multipart/multipart/utf8-encapsulated; type=message > >although these types was not proposed for multipart/report > >/ Kari Hurtta > > > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www1.ietf.org/mailman/listinfo/ima #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 20:58:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfoJw-0002m0-FK; Thu, 02 Nov 2006 20:58:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfoJv-0002lu-AL for ima@ietf.org; Thu, 02 Nov 2006 20:58:11 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfoJs-0005AW-KS for ima@ietf.org; Thu, 02 Nov 2006 20:58:11 -0500 Received: from [211.72.211.109] (pc109.twnic.net.tw [211.72.211.109]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id kA31w69a029997; Fri, 3 Nov 2006 09:58:06 +0800 Message-ID: <454AA4DA.2030705@twnic.net.tw> Date: Fri, 03 Nov 2006 10:09:30 +0800 From: Jeff User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <45491155.559F@xyzzy.claranet.de> <5dlkmujves.fsf@Hurtta06k.keh.iki.fi> <454A152A.2085@xyzzy.claranet.de> <5dac39ssb7.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: <5dac39ssb7.fsf@Hurtta06k.keh.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > Frank Ellermann writes in gmane.ietf.ima: > > >> Kari Hurtta wrote: >> >> >>> I was more considered how tokenizer can be used. >>> >> What would you like better ? I'm not sure about the proposals with >> the alt-address outside of i.e. behind the ">", and about a >> comma as separator as in . IIRC John didn't like to add >> "{" and "}". You had more proposals: > and >> >> If that's later inserted as is in a cc= or similar of a 2368ter >> mailto: using semicolon could be a bad idea. Folks try to replace >> "&" in query parts by ";", and complex rules where some semicolons >> have to be percent-encoded and others not aren't attractive. >> >> If that makes sense > is an alternative for . >> > > That > seems workable. > > ( But there maybe something what I do not have thinked. > > Someone may perhaps reduce > to > but I do not think that this is problem. > ) > In RFC 2822, it reads: mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr So, "From: jeff@twnic.net.tw" is good. I'm not sure if this make confuse under a case like. From: jeff@twnic.net.tw # angle-addr with display name to From: jeff@twnic.net.tw # only addr-spec, no display name, have alt-address I like the idea to move "alt-addr" out "<" and ">". :) Jeff Yeh -TWNIC _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 02 21:20:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfof1-0003nv-6r; Thu, 02 Nov 2006 21:19:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfoez-0003np-Og for ima@ietf.org; Thu, 02 Nov 2006 21:19:57 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfoey-0008Pu-2P for ima@ietf.org; Thu, 02 Nov 2006 21:19:57 -0500 Received: from [211.72.211.109] (pc109.twnic.net.tw [211.72.211.109]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id kA32JslK006505; Fri, 3 Nov 2006 10:19:54 +0800 Message-ID: <454AA9F5.1070609@twnic.net.tw> Date: Fri, 03 Nov 2006 10:31:17 +0800 From: Jeff User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jeff Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <45491155.559F@xyzzy.claranet.de> <5dlkmujves.fsf@Hurtta06k.keh.iki.fi> <454A152A.2085@xyzzy.claranet.de> <5dac39ssb7.fsf@Hurtta06k.keh.iki.fi> <454AA4DA.2030705@twnic.net.tw> In-Reply-To: <454AA4DA.2030705@twnic.net.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Sr Jeff wrote: > > > > Kari Hurtta wrote: >> Frank Ellermann writes in gmane.ietf.ima: >> >> >>> Kari Hurtta wrote: >>> >>> >>>> I was more considered how tokenizer can be used. >>>> >>> What would you like better ? I'm not sure about the proposals with >>> the alt-address outside of i.e. behind the ">", and about a >>> comma as separator as in . IIRC John didn't like to add >>> "{" and "}". You had more proposals: > and >>> >>> If that's later inserted as is in a cc= or similar of a 2368ter >>> mailto: using semicolon could be a bad idea. Folks try to replace >>> "&" in query parts by ";", and complex rules where some semicolons >>> have to be percent-encoded and others not aren't attractive. >>> If that makes sense > is an alternative for . >>> >> >> That > seems workable. >> >> ( But there maybe something what I do not have thinked. Someone >> may perhaps reduce > to >> but I do not think that this is problem. >> ) >> > In RFC 2822, it reads: > > mailbox = name-addr / addr-spec > > name-addr = [display-name] angle-addr > > angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr > > So, "From: jeff@twnic.net.tw" is good. > I'm not sure if this make confuse under a case like. > From: jeff@twnic.net.tw # angle-addr with > display name > to > From: jeff@twnic.net.tw # only addr-spec, no > display name, have alt-address > > I like the idea to move "alt-addr" out "<" and ">". :) > > Jeff Yeh > -TWNIC Sorry, miss reading on >. But the possible situation still comes up. Jeff _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 03 00:14:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfrMz-0007hw-0Y; Fri, 03 Nov 2006 00:13:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfrMx-0007ha-AO for ima@ietf.org; Fri, 03 Nov 2006 00:13:31 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfrMu-0006FF-Ra for ima@ietf.org; Fri, 03 Nov 2006 00:13:31 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfrMs-0005Rt-UE for ima@ietf.org; Fri, 03 Nov 2006 06:13:27 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Nov 2006 06:13:26 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Nov 2006 06:13:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: 03 Nov 2006 07:13:20 +0200 Lines: 117 Message-ID: <5dd585kt8v.fsf@Hurtta06k.keh.iki.fi> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <45491155.559F@xyzzy.claranet.de> <5dlkmujves.fsf@Hurtta06k.keh.iki.fi> <454A152A.2085@xyzzy.claranet.de> <5dac39ssb7.fsf@Hurtta06k.keh.iki.fi> <454AA4DA.2030705@twnic.net.tw> <454AA9F5.1070609@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Jeff writes in gmane.ietf.ima: > Sr > > Jeff wrote: > > > > > > > > Kari Hurtta wrote: > >> Frank Ellermann writes in gmane.ietf.ima: > >> > >> > >>> Kari Hurtta wrote: > >>> > >>>> I was more considered how tokenizer can be used. > >>>> > >>> What would you like better ? I'm not sure about the proposals with > >>> the alt-address outside of i.e. behind the ">", and about a > >>> comma as separator as in . IIRC John didn't like to add > >>> "{" and "}". You had more proposals: > and > >>> > >>> If that's later inserted as is in a cc= or similar of a 2368ter > >>> mailto: using semicolon could be a bad idea. Folks try to replace > >>> "&" in query parts by ";", and complex rules where some semicolons > >>> have to be percent-encoded and others not aren't attractive. If > >>> that makes sense > is an alternative for . > >>> > >> > >> That > seems workable. > >> > >> ( But there maybe something what I do not have thinked. Someone > >> may perhaps reduce > to > >> but I do not think that this is problem. > >> ) > >> > > In RFC 2822, it reads: > > > > mailbox = name-addr / addr-spec > > > > name-addr = [display-name] angle-addr > > > > angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr > > > > So, "From: jeff@twnic.net.tw" is good. > > I'm not sure if this make confuse under a case like. > > From: jeff@twnic.net.tw # angle-addr with > > display name > > to > > From: jeff@twnic.net.tw # only addr-spec, no > > display name, have alt-address > > > > I like the idea to move "alt-addr" out "<" and ">". :) > > > > Jeff Yeh > > -TWNIC > Sorry, miss reading on >. > But the possible situation still comes up. Syntax discussed was angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] alt-address = [CFWS] "<" addr-spec ">" [CFWS] Notice that alt-address is only defined for angle-address. Also From: Käyttäjätuki@example.org is NOT allowed. utf8-addr-spec requires '<' and '>'. That means From: On that it is possible to use < > also on alt-address From: > > Jeff On my one possible alternatives there was "alt-addr" outside of "<" and ">". That was angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] alt-address = "<" addr-spec ">" [CFWS] This was not liked. It will mean From: I wrote these examples/alternatives because I suspected that '[' ']' causes problem for writing tokenizer. This is different thing: From: Käyttäjätuki@example.org Käyttäjätuki@example.org is 'display-name' :-) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 03 04:58:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfvo5-00085k-83; Fri, 03 Nov 2006 04:57:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfvo4-00085f-Le for ima@ietf.org; Fri, 03 Nov 2006 04:57:48 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfvo3-0002EM-92 for ima@ietf.org; Fri, 03 Nov 2006 04:57:48 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gfvnf-0002hg-Om for ima@ietf.org; Fri, 03 Nov 2006 10:57:23 +0100 Received: from pd9fbad68.dip0.t-ipconnect.de ([217.251.173.104]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Nov 2006 10:57:23 +0100 Received: from nobody by pd9fbad68.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Nov 2006 10:57:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: Fri, 03 Nov 2006 10:56:06 +0100 Organization: Lines: 23 Message-ID: <454B1236.1A6A@xyzzy.claranet.de> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <45491155.559F@xyzzy.claranet.de> <5dlkmujves.fsf@Hurtta06k.keh.iki.fi> <454A152A.2085@xyzzy.claranet.de> <5dac39ssb7.fsf@Hurtta06k.keh.iki.fi> <454AA4DA.2030705@twnic.net.tw> <454AA9F5.1070609@twnic.net.tw> <5dd585kt8v.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad68.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > "alt-addr" outside of "<" and ">". That was > angle-addr =3D [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-addre= ss] > alt-address =3D "<" addr-spec ">" [CFWS] > This was not liked. It will mean > From: = Yes, maybe I'm only paranoid. If some spec. uses something like... weird-addr-lists =3D 1*angle-addr =2E..then it's not more clear what's an in such lists. Maybe no spec. does this at the moment, but it's an "obvious" idea that won't work as expected for the syntax shown above. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 03 09:54:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0Pm-000086-Qv; Fri, 03 Nov 2006 09:53:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0Pl-00007U-PW for ima@ietf.org; Fri, 03 Nov 2006 09:53:01 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg0Pj-0004Sx-Bw for ima@ietf.org; Fri, 03 Nov 2006 09:53:01 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gg0NN-00006U-Dm for ima@ietf.org; Fri, 03 Nov 2006 15:50:33 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Nov 2006 15:50:33 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Nov 2006 15:50:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: 03 Nov 2006 16:49:27 +0200 Lines: 74 Message-ID: <5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: <...> > Possible other possibilities: > > 1) > > angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] > > alt-address = [CFWS] "[" addr-spec "]" [CFWS] > > > this was suggested by someone other, but that do not look much better if > [ ] are used. > > 2) > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > alt-address = [CFWS] ',' addr-spec [CFWS] > > 3) > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > alt-address = [CFWS] ';' addr-spec [CFWS] > > 4) > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > alt-address = [CFWS] "<" addr-spec ">" [CFWS] > > perhaps that is not so bad as it looks? ( this alternative is best so far? ) > > 5) > > angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] > > alt-address = [CFWS] "<" addr-spec ">" [CFWS] 6) angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] alt-address = addr-spec [CFWS] 7) angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] alt-address = [CFWS] ':' [CFWS] addr-spec [CFWS] Perhaps not good. > > Note that this all possibilities avoid characters used on atext. specials = "(" / ")" / ; Special characters used in "<" / ">" / ; other parts of the syntax "[" / "]" / ":" / ";" / "@" / "\" / "," / "." / DQUOTE There is not a lot of characters (if unicode characters > 127 are not used.) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 03 12:34:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2vA-0005Oy-Rw; Fri, 03 Nov 2006 12:33:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2v9-0005Os-NT for ima@ietf.org; Fri, 03 Nov 2006 12:33:35 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg2v0-00089n-9x for ima@ietf.org; Fri, 03 Nov 2006 12:33:35 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gg2ux-0002qQ-FE; Fri, 03 Nov 2006 12:33:23 -0500 Date: Fri, 03 Nov 2006 12:33:22 -0500 From: John C Klensin To: Harald Alvestrand Subject: Re: [EAI] #1389: framework 4.1 - reject Message-ID: <4F5E66E0FC4ED9FD83E64964@p3.JCK.COM> In-Reply-To: <4549BEA1.7060503@alvestrand.no> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <4548A50A.1050102@alvestrand.no> <1C83043D52C72D00393A364F@p3.JCK.COM> <45490865.56FA@xyzzy.claranet.de> <4549BEA1.7060503@alvestrand.no> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 02 November, 2006 01:47 -0800 Harald Alvestrand wrote: > I think Frank has a point that you don't need the term > "bounce", and it's easier to remove it than to define it > (especially as that was already done in the 2821bis work). > > I don't like "it must be returned" either, "an error report > must be returned" is more correct (the error report may or may > not include the whole message). If you want to define a term > for "return an error report", that's OK with me. > > Unless I hear shouts from the WG, you can take that as chair's > guidance. Since there were no shouts (other than from me), the term "bounce" has been removed. I have generally avoided "error report" in favor of phrases such as "generate and return a non-delivery message", which is consistent with the language of 821. The WG will need to determine whether the style of those comments is consistent and clear enough after seeing -03. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 03 12:35:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2xD-0008Mq-BB; Fri, 03 Nov 2006 12:35:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2xB-0008K9-1D for ima@ietf.org; Fri, 03 Nov 2006 12:35:41 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg2x8-0008QZ-K2 for ima@ietf.org; Fri, 03 Nov 2006 12:35:41 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gg2x6-0002sB-1J; Fri, 03 Nov 2006 12:35:36 -0500 Date: Fri, 03 Nov 2006 12:35:35 -0500 From: John C Klensin To: Harald Alvestrand , Charles Lindsey Subject: Re: [EAI] #1391: framework 5 - delivery to final delivery MTA Message-ID: <687AB556E8DED59C2C58E7F0@p3.JCK.COM> In-Reply-To: <454A0144.7050301@alvestrand.no> References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> <454A0144.7050301@alvestrand.no> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 02 November, 2006 06:31 -0800 Harald Alvestrand wrote: > Charles Lindsey wrote: >> On Wed, 01 Nov 2006 15:48:04 -0000, John C Klensin >> wrote: >> >>> Proposed definition (new third paragraph of section 3); >>> tuning welcome: >>> >>> However, the term "final delivery MTA" is used in >>> this document in a fashion equivalent to the term >>> "delivery system" or "final delivery system" of RFC >>> 2821. This is the SMTP server that controls the >>> format of, and is permitted to inspect and >>> interpret, local-part addresses. It receives >>> messages from the network for delivery to mailboxes, >>> rather than relaying. From the perspective of the >>> network, any local delivery arrangements such as >>> saving to a message store, handoff to specific >>> message delivery programs or agents, and mechanisms >>> for retrieving messages are all "behind" the final >>> delivery MTA and hence not part of the SMTP >>> transport or delivery process. >> >> In addition to message store, handoff to POP3/IMAP, etc., >> there is also the case of "forward to another address" >> (whether as part of a mailing list expansion or not, and >> whether with some change to the message or not. >> >> At that point (and especially where the is no change) it is >> back in the SMTP world, and becomes again subject to >> rejection, bouncing or downgrading, and finally arrives at >> yet another "final delivery MTA". I think your wording needs >> to include this case. In particular, it SHOULD NOT normally >> be upgraded at this point (that privilege should be reserved >> for the final final delivery MTA). > If it is part of alias expansion (no change to envelope > sender), the MTA is not final. > If it is part of mailing list expansion (change to envelope > sender), the MTA is final. > > The fact that it's hard to tell from a Sendmail aliases file > which one is taking place is a Sendmail problem, not a problem > with the Internet mail architecture. Agreed. Unless I hear instructions to the contrary, I'm taking this as "no additional textual change needed". johnb _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 03 13:04:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3OU-0000OO-8w; Fri, 03 Nov 2006 13:03:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3OT-0000OI-5R for ima@ietf.org; Fri, 03 Nov 2006 13:03:53 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg3OR-0002CK-NP for ima@ietf.org; Fri, 03 Nov 2006 13:03:53 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gg3ON-00033A-KC; Fri, 03 Nov 2006 13:03:47 -0500 Date: Fri, 03 Nov 2006 13:03:46 -0500 From: John C Klensin To: Martin Duerst , Kari Hurtta , ima@ietf.org Subject: Re: multipart/report (Re: [EAI] #1388: framework -3 - missing MIMEconsiderations) Message-ID: In-Reply-To: <6.0.0.20.2.20061102171637.0686ea70@localhost> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <4548A0DA.9060508@alvestrand.no> <5dhcxijsfo.fsf_-_@Hurtta06k.keh.iki.fi> <6.0.0.20.2.20061102171637.0686ea70@localhost> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 02 November, 2006 17:22 +0900 Martin Duerst wrote: > In this context, I'd like to reiterate my proposal for > making non-delivery reports standardized enough that > a MUA could automatically resend (or, as much as possible, > help the user to resend) a mail with fallback > addresses if it got stuck somewhere. > > So the scenario would be: > Mail with UTF-8 address sent -> > passes some SMTP servers -> > hits an SMTP server that doesn't downgrade, but sends > back a non-delivery report -> > report gets back, ultimately to MUA -> > MUA analyses, finds out that the report indeed is for a > mail it sent (one has to be careful these days because of > all the spam around) and that it's because of the UTF-8 > address -> mailer prepares the mail again, this time with the > alt address -> mail is sent again > > I'm not sure whether or not this is already possible, but it > sure would help MUAs and probably also the adoption of UTF8SMTP > (an error that has an easy solution is much less of an obstacle > than an error without obvious solution for a non-expert user). > > Regards, Martin. Martin, First, I think this would be a wonderful idea, and for far more reasons than the i18nemail work. The reasons for it are very old, e.g., the thing that caused the idea of an error reply of "user address changed, new address is..." to never work in a reasonable fashion was that it fell apart in relay environments. And, as you suggest, being able to get a reliable message all the way back to a sending MUA (or sending submission server) with instructions that it sort downgrade issues out would vastly simplify our work. However... (1) It is not in our charter. (2) Attempts to standardize things that much have met with slow adoption and sometimes active resistance. We've still got a number of mail systems out there that do not support the NDN formats that have been established for years (over a decade now if one counts from RFC 1894). (3) Given the current spam and malware environment, one would have to address the question of the authenticity of such a message with some care. That question opens all of the PKI and related cans of worms. One would also have to figure out whether an authentic error reply message in response to an incoming message that could not be authenticated would be a good idea. I don't think it would make things any worse, but haven't thought it through. I suppose one could specify things so that any host that offered the UTF8SMTP extension would be required to support a specific NDN format for error messages, but I'd suspect that, in practice, it would really slow down deployment of key features. So, sadly, I don't see a practical way to do this. Just my opinion. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 03 18:10:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8Aa-0004sX-JI; Fri, 03 Nov 2006 18:09:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8AZ-0004sS-8Q for ima@ietf.org; Fri, 03 Nov 2006 18:09:51 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg8AS-0007wL-Ih for ima@ietf.org; Fri, 03 Nov 2006 18:09:51 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3$clerew$man$ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 454bcc36.7e51.45 for ima@ietf.org; Fri, 3 Nov 2006 23:09:42 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kA3N9e7l009702 for ; Fri, 3 Nov 2006 23:09:41 GMT To: "ima@ietf.org" Subject: Re: [EAI] #1391: framework 5 - delivery to final delivery MTA References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> <454A0144.7050301@alvestrand.no> Message-ID: Date: Fri, 03 Nov 2006 23:09:39 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <454A0144.7050301@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 02 Nov 2006 14:31:32 -0000, Harald Alvestrand wrote: > Charles Lindsey wrote: >> >> In addition to message store, handoff to POP3/IMAP, etc., there is also >> the case of "forward to another address" (whether as part of a mailing >> list expansion or not, and whether with some change to the message or >> not. >> >> At that point (and especially where the is no change) it is back in the >> SMTP world, and becomes again subject to rejection, bouncing or >> downgrading, and finally arrives at yet another "final delivery MTA". I >> think your wording needs to include this case. In particular, it SHOULD >> NOT normally be upgraded at this point (that privilege should be >> reserved for the final final delivery MTA). > If it is part of alias expansion (no change to envelope sender), the MTA > is not final. Exactly so. But the alias expansion cannot take place without looking at the , and as John frequently points out to us, MTAs that are not "final delivery MTA"s are not supposed to look inside the . This is not a technical problem - rather a possible confusion of terminology. But it is worse in the case of UTF8SMTP because "looking at the " may require a little upgrading first (but not of the rest of the message, because it may yet meet another non-UTF8SMTP MTA on its further travels). That is why I think John needs to say something about this in his framework, just to make sure that nobody gets confused. > If it is part of mailing list expansion (change to envelope sender), the > MTA is final. Yes, in that case it is definitely a new message that is being constructed (usually) so the expander is definitely final (finally so). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 03 18:35:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8Yu-0004jf-BI; Fri, 03 Nov 2006 18:35:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8Ys-0004iZ-Pv for ima@ietf.org; Fri, 03 Nov 2006 18:34:58 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg8Yr-0004LR-Ea for ima@ietf.org; Fri, 03 Nov 2006 18:34:58 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA3NYmQ0024345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Nov 2006 15:34:48 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA3NYijm019037; Fri, 3 Nov 2006 15:34:46 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 3 Nov 2006 15:33:11 -0800 To: "Charles Lindsey" , "ima@ietf.org" From: Randall Gellens Subject: Re: [EAI] ISSUE: framework 4.1 - reject Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 10:56 AM +0000 10/31/06, Charles Lindsey wrote: > So I think the most we can do is draw attention to these problems > under Security Considerations, in which case count me as +1 for (2). +1 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- [P]olitics, as a practice, whatever its professions, has always been the systematic organization of hatreds. --American historian Henry Adams _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 03 18:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8tu-0000Vr-G7; Fri, 03 Nov 2006 18:56:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8ts-0000Vm-TQ for ima@ietf.org; Fri, 03 Nov 2006 18:56:40 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg8tr-00079P-IG for ima@ietf.org; Fri, 03 Nov 2006 18:56:40 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA3NubYm025967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 3 Nov 2006 15:56:38 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA3Nua1n006085 for ; Fri, 3 Nov 2006 15:56:37 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <45488896.64C8@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> <4546AA9A.16B@xyzzy.claranet.de> <45488896.64C8@xyzzy.claranet.de> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 3 Nov 2006 15:53:49 -0800 To: ima@ietf.org From: Randall Gellens Subject: Re: [EAI] ISSUE: framework 4.1 - reject Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 12:44 PM +0100 11/1/06, Frank Ellermann wrote: > EAI must not make it worse than it is. It should use neutral terms > like "reject" instead of "bounce" where applicable. I'm not sure "reject" is a neutral term, any more than "bounce". One implies returning a error code during an SMTP transaction, the other sending a DSN. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- If the code and the comments disagree, then both are probably wrong. --Norm Schryer _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 03 22:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgCJK-0003rd-EK; Fri, 03 Nov 2006 22:35:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgCJJ-0003rP-CG for ima@ietf.org; Fri, 03 Nov 2006 22:35:09 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgCJF-0003wc-Rv for ima@ietf.org; Fri, 03 Nov 2006 22:35:09 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GgCJ5-00030s-F4 for ima@ietf.org; Sat, 04 Nov 2006 04:34:56 +0100 Received: from pd9fbacf2.dip0.t-ipconnect.de ([217.251.172.242]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Nov 2006 04:34:55 +0100 Received: from nobody by pd9fbacf2.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Nov 2006 04:34:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject Date: Sat, 04 Nov 2006 04:31:14 +0100 Organization: Lines: 28 Message-ID: <454C0982.53F9@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> <4546AA9A.16B@xyzzy.claranet.de> <45488896.64C8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbacf2.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Randall Gellens wrote: > I'm not sure "reject" is a neutral term, any more than "bounce". One > implies returning a error code during an SMTP transaction, the other > sending a DSN. Yes, that's the (or a) common definition for the latter, but not the 2821-concept: | Delivery SMTP systems MAY reject ("bounce") such messages rather than | deliver them. "Reject" is a very sound action from a sender's POV, at least the mail didn't vanish in some black hole, and "the sender can make another plan", as the framework draft put it. With a "bounce" (your DSN-definition, not the 2821-reject-alias) on the other hand the first question of innocent bystanders hit by it will be "why on earth did they accept it, if they can't deliver it ?" 210,000 Google hits for "misdirected bounce", probably all talking about unsolicited DSNs, a "misdirected reject" would be quite a stunt with SMTP. A "cannot downgrade reject" is a bit like a "551 user not local". Do we need a kind of "251 attempting downgrade" reply ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 04 18:09:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgUd2-0004ms-Qu; Sat, 04 Nov 2006 18:08:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgUd2-0004j2-3g for ima@ietf.org; Sat, 04 Nov 2006 18:08:44 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgUd0-0000Bx-Pq for ima@ietf.org; Sat, 04 Nov 2006 18:08:44 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A1DF22596B7; Sun, 5 Nov 2006 00:05:50 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31818-03; Sun, 5 Nov 2006 00:05:46 +0100 (CET) Received: from [10.242.56.88] (m010f36d0.tmodns.net [208.54.15.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20E822580CF; Sun, 5 Nov 2006 00:05:44 +0100 (CET) Message-ID: <454D1D77.4090004@alvestrand.no> Date: Sun, 05 Nov 2006 00:08:39 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] #1391: framework 5 - delivery to final delivery MTA References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> <454A0144.7050301@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > > Exactly so. But the alias expansion cannot take place without looking > at the , and as John frequently points out to us, MTAs > that are not "final delivery MTA"s are not supposed to look inside the > . > > This is not a technical problem - rather a possible confusion of > terminology. But it is worse in the case of UTF8SMTP because "looking > at the " may require a little upgrading first (but not of > the rest of the message, because it may yet meet another non-UTF8SMTP > MTA on its further travels). Charles, PLEASE respect the decision of the WG to: - abandon ATOMIC - require use of ALT-ADDR for downgrading Together, these two decisions mean that the idea of "upgrading" an address before an MTA takes action on it is totally, utterly, completely and unconditionally meaningless. There is no information in the local-part of the RCPT TO parameter that can be "upgraded". Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 06 05:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh24g-0000F5-O5; Mon, 06 Nov 2006 05:51:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh24f-0000F0-KO for ima@ietf.org; Mon, 06 Nov 2006 05:51:29 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh24b-0000Ba-1O for ima@ietf.org; Mon, 06 Nov 2006 05:51:29 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3#clerew$man&ac*uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 454f13aa.100bf.14b for ima@ietf.org; Mon, 6 Nov 2006 10:51:22 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kA6ApKxQ007561 for ; Mon, 6 Nov 2006 10:51:21 GMT To: "ima@ietf.org" Subject: Re: [EAI] ISSUE: framework 4.1 - reject References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> <4546AA9A.16B@xyzzy.claranet.de> <45488896.64C8@xyzzy.claranet.de> Message-ID: Date: Mon, 06 Nov 2006 10:51:20 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 03 Nov 2006 23:53:49 -0000, Randall Gellens wrote: > At 12:44 PM +0100 11/1/06, Frank Ellermann wrote: > >> EAI must not make it worse than it is. It should use neutral terms >> like "reject" instead of "bounce" where applicable. > > I'm not sure "reject" is a neutral term, any more than "bounce". One > implies returning a error code during an SMTP transaction, the other > sending a DSN. We seem to have settled on "reject" and "return" as the two critical words. "Return" is fine, because it uses the correspondingly named "Return-Path". But I just wonder whether "refuse" might be a better term than "reject" for giving a 5xx response, since it conveys the idea of something that is more "immediate". -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 06 18:51:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEEw-0002HP-0J; Mon, 06 Nov 2006 18:50:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEEd-0001n0-3j; Mon, 06 Nov 2006 18:50:36 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEEd-0000b6-1F; Mon, 06 Nov 2006 18:50:35 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GhEEa-0005el-Cv; Mon, 06 Nov 2006 18:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 1F752175F7; Mon, 6 Nov 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GhEE5-0004Ki-MY; Mon, 06 Nov 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 06 Nov 2006 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-02.txt Pages : 14 Date : 2006-11-6 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-6162849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-6162849.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Tue Nov 07 08:26:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhQx3-0005pS-S1; Tue, 07 Nov 2006 08:25:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhQx2-0005ng-Ri for ima@ietf.org; Tue, 07 Nov 2006 08:25:16 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhQt3-0001kF-QY for ima@ietf.org; Tue, 07 Nov 2006 08:21:11 -0500 Received: (eyou send program); Tue, 07 Nov 2006 21:20:55 +0800 Message-ID: <362905655.29383@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 07 Nov 2006 21:20:55 +0800 Message-ID: <019101c7026f$92c38120$aa02470a@YaoJK> From: "Yao Jiankang" To: , "Frank Ellermann" References: <45339923.8030900@alvestrand.no><45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no><6C50875B746DB0E507B47392@p3.JCK.COM><4536EC66.3A14@xyzzy.claranet.de><45386B14.C0D@xyzzy.claranet.de><4538B9A9.6101@xyzzy.claranet.de><4546AA9A.16B@xyzzy.claranet.de><45488896.64C8@xyzzy.claranet.de> <362611356.09095@cnnic.cn> Subject: Re: [EAI] ISSUE: framework 4.1 - reject Date: Tue, 7 Nov 2006 21:20:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org ----- Original Message ----- From: "Frank Ellermann" To: Sent: Saturday, November 04, 2006 11:31 AM Subject: Re: [EAI] ISSUE: framework 4.1 - reject > Randall Gellens wrote: > > > I'm not sure "reject" is a neutral term, any more than "bounce". One > > implies returning a error code during an SMTP transaction, the other > > sending a DSN. > > Yes, that's the (or a) common definition for the latter, but not the > 2821-concept: > > | Delivery SMTP systems MAY reject ("bounce") such messages rather than > | deliver them. > > "Reject" is a very sound action from a sender's POV, at least the mail > didn't vanish in some black hole, and "the sender can make another plan", > as the framework draft put it. > > With a "bounce" (your DSN-definition, not the 2821-reject-alias) on the > other hand the first question of innocent bystanders hit by it will be > "why on earth did they accept it, if they can't deliver it ?" > > 210,000 Google hits for "misdirected bounce", probably all talking about > unsolicited DSNs, a "misdirected reject" would be quite a stunt with SMTP. > > A "cannot downgrade reject" is a bit like a "551 user not local". Do we > need a kind of "251 attempting downgrade" reply ? the code "2**" normally means success. "251 attempting downgrade" means success to downgrade or failure to UTF8SMTP? so "251 attempting downgrade" seems to have a little confused. Yao Jiankang CNNIC > > Frank > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 07 11:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUAz-0001Bs-AE; Tue, 07 Nov 2006 11:51:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUAx-0001BV-SV for ima@ietf.org; Tue, 07 Nov 2006 11:51:51 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhTzb-0007yH-M2 for ima@ietf.org; Tue, 07 Nov 2006 11:40:14 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68B892596C0 for ; Tue, 7 Nov 2006 17:37:13 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20511-05 for ; Tue, 7 Nov 2006 17:37:07 +0100 (CET) Received: from HTA-T43P-NO.corp.google.com (127host197.starwoodbroadband.com [12.105.242.197]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4013F2596C1 for ; Tue, 7 Nov 2006 17:37:03 +0100 (CET) Date: Tue, 07 Nov 2006 08:39:53 -0800 From: Harald Alvestrand To: ima@ietf.org Message-ID: <349EFD799F4B17954295416B@HTA-T43P-NO.corp.google.com> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [EAI] Status of issues, Framework document X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Here's the status of the issues so far, to the extent that I think I=20 understand where they stand. If someone feels that this status is erroneous, please speak up. Note that I have "resolution not clear" on #1393 and #1397. Others should=20 be OK. 1387 Framework 1.3 - i18mail user clarification Editorial, accepted 1388 Framework -3 - Missing MIME considerations Note that =E2=80=93headers needs to address MIME issues 1389 Framework 4.1 - term "bounce" vs "reject" Remove term "bounce" 1390 Framework 4.1 - "POP" Editorial, accepted 1391 Framework 5 - delivery to final delivery MTA Being wordsmithed 1392 Framework 6 - delete i18n section Accepted 1393 Framework 7 - missing local part abuses as label Resolution not clear 1394 Framework 10 - too long Wordsmithing, but no changes 1395 Framework 13 =E2=80=93 nits Editorial, accepted 1396 Framework 7.1 - title change IRI -> URI Accepted 1397 Framework 10 - UTF-8 Resolution not clear _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 07 12:59:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVEQ-0006u5-R9; Tue, 07 Nov 2006 12:59:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVEP-0006tz-AW for ima@ietf.org; Tue, 07 Nov 2006 12:59:29 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVEM-0005z7-W3 for ima@ietf.org; Tue, 07 Nov 2006 12:59:29 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GhVE4-0002C6-NX for ima@ietf.org; Tue, 07 Nov 2006 18:59:08 +0100 Received: from d254085.dialin.hansenet.de ([80.171.254.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Nov 2006 18:59:08 +0100 Received: from nobody by d254085.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Nov 2006 18:59:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Status of issues, Framework document Date: Tue, 07 Nov 2006 18:56:48 +0100 Organization: Lines: 33 Message-ID: <4550C8E0.7285@xyzzy.claranet.de> References: <349EFD799F4B17954295416B@HTA-T43P-NO.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254085.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > 1393 Framework 7 - missing local part abuses as label > Resolution not clear That apparently boiled down to "there are some interesting uses of local parts working for a proper subset of US-ASCII known as LDH, and these uses won't work with UTF-8 as is". Or in other words you can IMO mark 1393 as "no change/rejected" or similar. > 1397 Framework 10 - UTF-8 > Resolution not clear Starting my "special" browser for the critical ietf:ietf cases, because I don't recall what 1397 was... ...it's a special point also covered by 1394. Maybe the part... | and, potentially, some issues with UTF-8 canonicalization, | discussed in [RFC3629]. The latter is also part of the subject | of ongoing work discussed in [Net-Unicode]. ...could be replaced. For an unrelated draft I tried this: | well-known Unicode and UTF-8 security considerations are not | listed below. For an overview see [UTR36] and [RFC3629]. The most exciting part is to create a element for UTR #36. John has this in RFC 4690. The last date I've seen was August 2006. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 07 13:26:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVeo-0005TU-Jt; Tue, 07 Nov 2006 13:26:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVeo-0005TO-5Q for ima@ietf.org; Tue, 07 Nov 2006 13:26:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVem-0002Gi-OA for ima@ietf.org; Tue, 07 Nov 2006 13:26:46 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GhVee-0008NQ-7b for ima@ietf.org; Tue, 07 Nov 2006 19:26:36 +0100 Received: from d254085.dialin.hansenet.de ([80.171.254.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Nov 2006 19:26:36 +0100 Received: from nobody by d254085.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Nov 2006 19:26:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: 251 trying downgrade (was: [EAI] ISSUE: framework 4.1 - reject) Date: Tue, 07 Nov 2006 19:23:18 +0100 Organization: Lines: 33 Message-ID: <4550CF16.35F5@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no><45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no><6C50875B746DB0E507B47392@p3.JCK.COM><4536EC66.3A14@xyzzy.claranet.de><45386B14.C0D@xyzzy.claranet.de><4538B9A9.6101@xyzzy.claranet.de><4546AA9A.16B@xyzzy.claranet.de><45488896.64C8@xyzzy.claranet.de> <362611356.09095@cnnic.cn> <362905655.29383@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254085.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yao Jiankang wrote: > the code "2**" normally means success. "251 attempting downgrade" > means success to downgrade or failure to UTF8SMTP? > so "251 attempting downgrade" seems to have a little confused. Yes, I try to explain it better. Let's say user@there.example has a new address user@elsewhere.example, and the admin of there.example agrees to forward mails to the new address - if the admin doesn't want this he could still arrange a 551 reject. So when you send mail to the old address user@there.example one of the SMTP servers at there.example accepts it with a... 251 user not local; will forward to ...so far it's a success, queued for forwarding. That can take a while and fail, and for you as sender it might be faster / better to send further mails directly to user@elsewhere.example With downgrading it's a similar situation, for you as sender it might be better / faster if you send further mails directly to the alt-address in the traditional format (no utf8headers etc.), because whatever the downgrading attempts to do, it could cause havoc for your mails (destroyed DKIM signature or similar). With a 251 the server could indicate that it tries its best, but maybe you prefer to send your UTF-8 text as ZIP-attachement of traditional mail in this situation, because you're not really interested to find out what "some server trying its best" means. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 08 17:44:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghw9P-0000ZZ-KR; Wed, 08 Nov 2006 17:44:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghw9O-0000WI-BI for ima@ietf.org; Wed, 08 Nov 2006 17:44:06 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghw9L-0005ha-0N for ima@ietf.org; Wed, 08 Nov 2006 17:44:06 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E18AA2580E1 for ; Wed, 8 Nov 2006 23:41:07 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04668-09 for ; Wed, 8 Nov 2006 23:41:01 +0100 (CET) Received: from HTA-T43P-NO.corp.google.com (dhcp66-21.ietf67.org [130.129.66.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0498F2580D0 for ; Wed, 8 Nov 2006 23:40:59 +0100 (CET) Date: Wed, 08 Nov 2006 14:43:51 -0800 From: Harald Alvestrand To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [EAI] Agenda presentation uploaded to meeting materials page X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The agenda and discussion slides we will use on Thursday has now been uploaded to the meeting materials page: You will find the slides on this page: under the Applications Area, EAI. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 09 02:09:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi41r-0000Fg-7R; Thu, 09 Nov 2006 02:08:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi41p-0000BP-BO for ima@ietf.org; Thu, 09 Nov 2006 02:08:49 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi41k-0001ur-Fm for ima@ietf.org; Thu, 09 Nov 2006 02:08:49 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kA978eQf004228 for ; Thu, 9 Nov 2006 16:08:40 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 7546_20ecc56a_6fc1_11db_9226_0014221f2a2d; Thu, 09 Nov 2006 16:08:40 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40368) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 9 Nov 2006 16:08:12 +0900 Message-Id: <6.0.0.20.2.20061109143219.05d890b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 09 Nov 2006 14:43:06 +0900 To: Harald Alvestrand , ima@ietf.org From: Martin Duerst Subject: Implementations (was: [EAI] Agenda presentation uploaded...) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hello Harald, others, I have not found any item regarding implementations on the agenda. I know that implementations are not usually much discussed during a WG meeting, but in the minutes from Beijing, there was some helpful information about ongoing/planned implementations, and it would be great if there were such information this time, too. For everybody's information, I'm currently working with a student of mine on implementation in an MUA (Sylpheed, see http://sylpheed.sraoss.jp/en/). We should have some results in a month or two. We are very interested in getting an SMTP server implementation for testing (with an MUA only, things are kind of boring, to say the least). Also, if somebody is working on a POP or IMAP server, we would appreciate to know. With kind regards, Martin. At 07:43 06/11/09, Harald Alvestrand wrote: >The agenda and discussion slides we will use on Thursday has now been uploaded to the meeting materials page: > >You will find the slides on this page: > > > >under the Applications Area, EAI. > > Harald #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 09 02:09:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi41p-0000BI-2p; Thu, 09 Nov 2006 02:08:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi41o-0000BD-FQ for ima@ietf.org; Thu, 09 Nov 2006 02:08:48 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi41k-0001uq-Fl for ima@ietf.org; Thu, 09 Nov 2006 02:08:48 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kA978dxM004217 for ; Thu, 9 Nov 2006 16:08:39 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 565c_1fec4dca_6fc1_11db_9190_0014221fa3c9; Thu, 09 Nov 2006 16:08:38 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40368) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 9 Nov 2006 16:08:09 +0900 Message-Id: <6.0.0.20.2.20061109133047.05d8bb00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 09 Nov 2006 14:32:08 +0900 To: Harald Alvestrand , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] Agenda presentation uploaded to meeting materials page In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Larry Masinter , jwz@jwz.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hello Harald, others, At 07:43 06/11/09, Harald Alvestrand wrote: >The agenda and discussion slides we will use on Thursday has now been uploaded to the meeting materials page: > >You will find the slides on this page: > > > >under the Applications Area, EAI. Here is some additional material for your discussion discussion about the mailto: URI draft (currently http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-03.txt) It is a breakdown of the various things that (most probably) need to happen sooner or later, in order of priority, first as a short list (which you might want to put into a slide) and then again with some comments added. If I have misrepresented anybody's position, I'm appologizing in advance. Summary ------- 1) General fixes to the mailto: URI as it is, independent of internationalization. 2) Allowing non-ASCII characters where they are currently allowed in email (e.g. Subject: header field). 3) Internationalizing email addresses in mailto:. 3)a] Internationalizing the RHS (domain name part) 3)b] Internationalizing the LHS 4) Including the syntax for fallback addresses With Comments ------------- 1) General fixes to the mailto: URI as it is, independent of internationalization. Mostly proposed by Frank, Frank said that this should be done separate, before anything else. I'm ready to do that work, in combination with at least 2). 2) Allowing non-ASCII characters where they are currently allowed in email (e.g. Subject: header field). In my view, this is overdue, because it is an unnecessary limitation, and some implemenations already exist and others are looking for guidance. This is the main contribution of the draft. It uses UTF-8 and %-encoding to work well with IRIs. The fact that EAI also uses UTF-8 is a coincidence on the technical level (on a higher, architectural/best practices level, it is not a coincidence). John expressed two concerns: a) that there may be normalization,... issues that should be handled in an uniform manner before moving forward, and b) that 'internationalizing' mailto: in this way at the same time EAI is moving ahead with internationalizing the actual addresses may be confusing. With respect to a), including non-ASCII characters (as UTF-8 or in any of many other encodings) e.g. in the Subject field is already possible, and not restricted, and allowing this is mailto: doesn't seem to make the problem any worse (if it is bad indeed, which I don't think it is). With respect to b), I think the mailto: draft can be very clear on what it does and what it doesn't, and people who want to get themselves confused will always find a way to do so. I currently think that completing the draft with 1) and 2) and publishing it, as an individual submission, and later do another update, possibly as a work item of this WG or a followup WG (after completing the current items, as Ted was insisting), is what makes most sense. 3) Internationalizing email addresses in mailto:. This falls into two parts, RHS and LHS. This at first looks intimately related to the work of this WG, but actually, it can be defined in a way that is independent of the WG work. The trick is simply to say "Here is how you put a non-ASCII email address into a mailto URI; at any given time, there may be no (as currently), one (e.g. EAI), or more than one way to actually send something to such an address, but this specification doesn't address this." 3)a] Internationalizing the RHS (domain name part) Sending mails can already be implemented now, by converting the non-ASCII characters in the mailto: URI to xn--punycode in SMTP and the actual mail headers. With EAI, a better method should become available. 3)b] Internationalizing the LHS This currently doesn't work. This means that the spec will be around, but because there are no implementations, there will be no actual URIs that use this feature. It will be possible once EAI becomes available. The draft currently includes 3), but given that e.g. 3)b] at this point in time could not be implemented, and therefore the draft could not move to Draft Standard that way, it may not be appropriate to include this. Also, it would probably create more confusion than staying at 2). 4) Including the syntax for fallback addresses Concretely, something like mailto:KANJI@GREEK.org[fall@back.org] or mailto:KANJI@GREEK.org{fall@back.org} (or mailto:utf8@utf8, but '<' and '>' are not allowed in URIs!) would be added to the mailto: syntaxt. I have mentioned that this may need to be done in the current (-03) draft, but it is way to early, because the syntax isn't clear yet and implementations are not available yet, and it's not even clear whether this is really needed (something roughly like Contact: Internationalized old style may be more appropriate in many cases). Conclusion ---------- My own personal conclusion at the moment is to do 1) and 2) in a first step, as an individual submission (together with Larry and Jamie) and with help of whoever sees a need to contribute, and then do 3) (and possibly 4) at a later stage. I hope this will reasonably address all the concerns of everybody who has expressed (or otherwise has) a concern. But I'm looking forward to further WG input. I hope everybody is enjoying San Diego. It was great the last time around the IETF was there. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 09 11:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCOJ-0001uk-Kl; Thu, 09 Nov 2006 11:04:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCOJ-0001ua-1n for ima@ietf.org; Thu, 09 Nov 2006 11:04:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiCOE-0001UX-Ey for ima@ietf.org; Thu, 09 Nov 2006 11:04:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GiCO7-0006YZ-Ua for ima@ietf.org; Thu, 09 Nov 2006 17:04:23 +0100 Received: from d252050.dialin.hansenet.de ([80.171.252.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Nov 2006 17:04:23 +0100 Received: from nobody by d252050.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Nov 2006 17:04:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Agenda presentation uploaded to meeting materials page Date: Thu, 09 Nov 2006 17:01:36 +0100 Organization: Lines: 59 Message-ID: <455350E0.76A2@xyzzy.claranet.de> References: <6.0.0.20.2.20061109133047.05d8bb00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252050.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst wrote: > something like mailto:KANJI@GREEK.org[fall@back.org] > or mailto:KANJI@GREEK.org{fall@back.org} (or > mailto:utf8@utf8, but '<' and '>' are > not allowed in URIs!) That's interesting - I thought that [...] is also NOT allowed, excluding IPv6 (or IPvFuture) literals in the part of an And after two years and that message... ...I hoped that I finally understand RFC 3986. Based on that article anything claiming to be an URI must match the general syntax in RFC 3986. Trying that for mailto:KANJI@GREEK.org[fall@back.org] as URI (not IRI) the "mailto:" part should be a scheme. There's no query- or fragment-part, so the rest should be a hier-part. It doesn't start with "//", and so it must be a or similar, no . All path-constructs consist of zero or more segments separated by slashes, each segment consists of zero or more s. With a special case for relative URLs without scheme, where the first segment cannot contain a colon, that's in other words 1* excluding ":". Putting it all together - the colon-case is irrelevant after the trailing colon in "mailto:" - you can have s and slashes, and doesn't allow "[" and "]" like it doesn't allow "<" and ">". If that's wrong wrt URIs it could be very important for the EAI-work, because Kari and I discussed alternatives for the proposed "[" and "]" syntax, and I was confident that using angle brackets to delimit it wouldn't make it worse for your mailto:-work. > My own personal conclusion at the moment is to do 1) > and 2) in a first step, as an individual submission That sounds good, please propose a list to discuss some details. > then do 3) (and possibly 4) at a later stage. I hope > this will reasonably address all the concerns of > everybody who has expressed (or otherwise has) > a concern. But I'm looking forward to further WG input. The question above about square- vs. angle-brackets is about the potential output of EAI, it could affect the future 2368ter if angle-brackets are worse than square- brackets. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 09 12:40:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDsd-0000EU-KX; Thu, 09 Nov 2006 12:39:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDsb-0000DY-OO for ima@ietf.org; Thu, 09 Nov 2006 12:39:57 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiDsN-0004GJ-5C for ima@ietf.org; Thu, 09 Nov 2006 12:39:57 -0500 Received: (eyou send program); Fri, 10 Nov 2006 01:39:25 +0800 Message-ID: <363093965.07480@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [130.129.66.172]) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 10 Nov 2006 01:39:25 +0800 Message-ID: <455367D3.4040409@cnnic.cn> Date: Fri, 10 Nov 2006 01:39:31 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Duerst References: <363056151.18248@cnnic.cn> In-Reply-To: <363056151.18248@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ima@ietf.org Subject: [EAI] Re: Implementations X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear Martin, There is no time slot for implementation discussion for saving time to discuss the open issues. We just mentioned some implementations are ongoing by CDNC. ( www.cdnc.org) About that, you may contact Mr.Yao Jiankang, yaojk@cnnic.cn to know more. Regards! -- -- Xiaodong LEE [The best answer is doing] +86-10-58813020 mailto:lee@cnnic.cn http://www.lixiaodong.cn Martin Duerst wrote: > Hello Harald, others, > > I have not found any item regarding implementations on the agenda. > > I know that implementations are not usually much discussed during > a WG meeting, but in the minutes from Beijing, there was some helpful > information about ongoing/planned implementations, and it would > be great if there were such information this time, too. > > For everybody's information, I'm currently working with a student > of mine on implementation in an MUA (Sylpheed, see > http://sylpheed.sraoss.jp/en/). We should have some results in a > month or two. We are very interested in getting an SMTP server > implementation for testing (with an MUA only, things are > kind of boring, to say the least). Also, if somebody is working > on a POP or IMAP server, we would appreciate to know. > > With kind regards, Martin. > > At 07:43 06/11/09, Harald Alvestrand wrote: > >> The agenda and discussion slides we will use on Thursday has now been uploaded to the meeting materials page: >> >> You will find the slides on this page: >> >> >> >> under the Applications Area, EAI. >> >> Harald >> > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 09 15:22:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGOu-0007FH-DP; Thu, 09 Nov 2006 15:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGOt-0007EG-4D for ima@ietf.org; Thu, 09 Nov 2006 15:21:27 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGOp-0002Np-E1 for ima@ietf.org; Thu, 09 Nov 2006 15:21:27 -0500 Received: from usery920wt90xu (dhcp71-126.ietf67.org [130.129.71.126]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id kA9KLE5K012812; Fri, 10 Nov 2006 04:21:15 +0800 Message-Id: <200611092021.kA9KLE5K012812@twnic.net.tw> From: "Jeff" To: "'Martin Duerst'" , "'Harald Alvestrand'" , Subject: RE: Implementations (was: [EAI] Agenda presentation uploaded...) Date: Fri, 10 Nov 2006 04:21:26 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6.0.0.20.2.20061109143219.05d890b0@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccDzfeQIGi615/8SF2gna1f9QTfmAAZf9yA X-Spam-Status: NO, -194.297<=7 (0.6:FROM_DSL_OR_DHCP;5.1:MSGID_FROM_MTA_ID;) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org TWNIC had setup a EAI SMTP server for testbed. If anyone is interesting in join in testing, please sent a brief message with you IP address range to tech@twnic.net.tw. I could open relay for them. And also, we have a simple updated version of POP3 server (modified from Perl Net::Server::POP3). But it currently archived in somewhere, some server, I have to dig it out when I get back to my office. Regards, Jeff Yeh -TWNIC > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: Thursday, November 09, 2006 1:43 PM > To: Harald Alvestrand; ima@ietf.org > Subject: Implementations (was: [EAI] Agenda presentation uploaded...) > > Hello Harald, others, > > I have not found any item regarding implementations on the agenda. > > I know that implementations are not usually much discussed > during a WG meeting, but in the minutes from Beijing, there > was some helpful information about ongoing/planned > implementations, and it would be great if there were such > information this time, too. > > For everybody's information, I'm currently working with a > student of mine on implementation in an MUA (Sylpheed, see > http://sylpheed.sraoss.jp/en/). We should have some results > in a month or two. We are very interested in getting an SMTP > server implementation for testing (with an MUA only, things > are kind of boring, to say the least). Also, if somebody is > working on a POP or IMAP server, we would appreciate to know. > > With kind regards, Martin. > > At 07:43 06/11/09, Harald Alvestrand wrote: > >The agenda and discussion slides we will use on Thursday has > now been uploaded to the meeting materials page: > > > >You will find the slides on this page: > > > > eting_num= > >67> > > > >under the Applications Area, EAI. > > > > Harald > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 09 16:23:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHLv-0001LH-KS; Thu, 09 Nov 2006 16:22:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHLu-0001Jo-UC for ima@ietf.org; Thu, 09 Nov 2006 16:22:26 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHLt-0005Sl-Hs for ima@ietf.org; Thu, 09 Nov 2006 16:22:26 -0500 Received: from [130.129.69.28] (dhcp69-28.ietf67.org [130.129.69.28]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 Nov 2006 21:22:24 +0000 Message-ID: <45539C0D.3040402@isode.com> Date: Thu, 09 Nov 2006 13:22:21 -0800 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] WG LAST CALL: draft-ietf-eai-framework-02 References: <45339923.8030900@alvestrand.no> <45465A95.1090108@isode.com> <1F37E1194DB5C5DD7DFEB16C@p3.JCK.COM> In-Reply-To: <1F37E1194DB5C5DD7DFEB16C@p3.JCK.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >--On Monday, 30 October, 2006 20:03 +0000 Alexey Melnikov > wrote: > > >>Some minor comments: >> >> >4.1. SMTP Extension for Internationalized eMail Address >> [...] >> > Some general principles apply to this work. >> > >> > 1. Whatever encoding is used should apply to the whole >> > address and >> > be directly compatible with software used at the user >> > interface. >> >>Why? Can it be applied to LHS and RHS separately? >> >> >This was an attempt to explain, in short form, why it would not >be reasonable to, e.g., require that the local part be in UTF-8 >while the domain part was in punycode. If you can think of >better wording, or think it needs to be made more explicit, >please send text. > Is the following any better: Whatever encoding is used should be applied to both the left hand side and the right hand side of an address and be directly compatible with software used at the user interface. ? (or change "left hand side" to "local" and "right hand side" to "domain") _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 09 18:00:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiIsG-0008KP-Rc; Thu, 09 Nov 2006 17:59:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiIsF-0008KF-5q for ima@ietf.org; Thu, 09 Nov 2006 17:59:55 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiIsD-0001vb-Rl for ima@ietf.org; Thu, 09 Nov 2006 17:59:55 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GiIsD-000GJJ-5C; Thu, 09 Nov 2006 17:59:53 -0500 Date: Thu, 09 Nov 2006 17:59:51 -0500 From: John C Klensin To: Alexey Melnikov Subject: Re: [EAI] WG LAST CALL: draft-ietf-eai-framework-02 Message-ID: <80E898F6C8435C195C3F418B@as-s2n.ietf67.org> In-Reply-To: <45539C0D.3040402@isode.com> References: <45339923.8030900@alvestrand.no> <45465A95.1090108@isode.com> <1F37E1194DB5C5DD7DFEB16C@p3.JCK.COM> <45539C0D.3040402@isode.com> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yes. Done. john --On Thursday, November 09, 2006 13:22 -0800 Alexey Melnikov wrote: > John C Klensin wrote: > >> --On Monday, 30 October, 2006 20:03 +0000 Alexey Melnikov >> wrote: >> >> >>> Some minor comments: >>> >>> > 4.1. SMTP Extension for Internationalized eMail Address >>> [...] >>> > Some general principles apply to this work. >>> > >>> > 1. Whatever encoding is used should apply to the whole >>> > address and >>> > be directly compatible with software used at the user >>> > interface. >>> >>> Why? Can it be applied to LHS and RHS separately? >>> >>> >> This was an attempt to explain, in short form, why it would >> not be reasonable to, e.g., require that the local part be in >> UTF-8 while the domain part was in punycode. If you can >> think of better wording, or think it needs to be made more >> explicit, please send text. >> > Is the following any better: > > Whatever encoding is used should be applied to both the left > hand side and the right hand side of an address and be > directly compatible with software used at the user interface. > > ? > > (or change "left hand side" to "local" and "right hand side" > to "domain") > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 10 10:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYUE-00040u-E5; Fri, 10 Nov 2006 10:40:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYUC-0003xq-AG for ima@ietf.org; Fri, 10 Nov 2006 10:40:08 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYUB-00053c-35 for ima@ietf.org; Fri, 10 Nov 2006 10:40:08 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GiYUA-000N1s-CU for ima@ietf.org; Fri, 10 Nov 2006 10:40:06 -0500 Date: Fri, 10 Nov 2006 10:40:04 -0500 From: John C Klensin To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [EAI] draft-ietf-eai-framework-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Document is now in the posting queue. As Harald indicated in the WG meeting yesterday, please review to be sure that all issues in the tracker have been appropriately dealt with. In addition, please check to verify that none of the many editorial changes and clarifications have made things worse. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 11 04:28:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gip9G-0004wd-Tm; Sat, 11 Nov 2006 04:27:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gip9F-0004wR-In for ima@ietf.org; Sat, 11 Nov 2006 04:27:37 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gip9A-0001Ww-7l for ima@ietf.org; Sat, 11 Nov 2006 04:27:37 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gip90-0007Tn-MI for ima@ietf.org; Sat, 11 Nov 2006 10:27:22 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 10:27:22 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 10:27:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 11 Nov 2006 11:27:13 +0200 Lines: 20 Message-ID: <5d3b8qib9q.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [EAI] Question in http://www3.ietf.org/meetings/ietf-logs/eai/2006-11-09.html X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org [16:43:04] johnk: another proposal for the marker header: use MIME-Version: 2.0 [16:43:41] pete: worried about why we have this header [16:44:04] johnk: we've been here this before, so why not be here before with the old one [16:45:24] chris: will anyone actually implement this as other than MUST generate, MUST ignore? On my MUA MIME-Version header field is checked. If it is other than '1.0' (when comments are removed), then just metamail is called. Ie. 'Unkown mime version, I will call external program for this'. [16:46:00] harald: does anyone have a *use* for this marker? [16:47:02] does anyone recall why that header was added? MIME-Version: 2.0 may be usefull, if there is UTF-8 header fileds on MIME structure -- specially on other place than on top mail header. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 11 05:47:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiqO3-00034t-6q; Sat, 11 Nov 2006 05:46:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiqO2-00034o-N0 for ima@ietf.org; Sat, 11 Nov 2006 05:46:58 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiqO0-0003sA-Ci for ima@ietf.org; Sat, 11 Nov 2006 05:46:58 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GiqNk-0003U1-K4 for ima@ietf.org; Sat, 11 Nov 2006 11:46:40 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 11:46:40 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 11:46:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 11 Nov 2006 12:46:30 +0200 Lines: 24 Message-ID: <5dy7qigt15.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [EAI] Comment to http://www3.ietf.org/meetings/ietf-logs/eai/2006-11-09.html X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org [17:33:28] william: bounce is best of bad choices so far; drafts for each alternative? [17:34:18] harald: strong opinion in room that dropping header is bad [17:34:29] pete: dropping includes downgrade header? [17:34:39] harald: doesn't matter, strong against either way [17:34:39] So long as you get the Downgraded header, I think deleting the original and not bouncing is fine with me. [17:34:52] harald: bouncing has problems [17:35:04] harald: My suggestion was to let sender specify which header fields must be preserved (other headers my be encapsulated to Downgraded (or whatever) header fileds.) That sugestion is on draft-ietf-eai-utf8headers-02.txt: | The "required-fields" parameter is defined for "Header-Type" header- | field. Value of "required-fields" parameter is defined as following: | | required-fields-value = field-name [FWS] | *("," [FWS] field-name [FWS]) | ; the term is defined in RFC2822 / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 11 07:18:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Girnr-00072r-FX; Sat, 11 Nov 2006 07:17:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Girnq-00072m-3n for ima@ietf.org; Sat, 11 Nov 2006 07:17:42 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Girno-00040b-Je for ima@ietf.org; Sat, 11 Nov 2006 07:17:42 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Girnh-00012m-9x for ima@ietf.org; Sat, 11 Nov 2006 13:17:33 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 13:17:33 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 13:17:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 11 Nov 2006 14:17:23 +0200 Lines: 153 Message-ID: <5d1woanpnw.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Subject: [EAI] [gmane.ietf.announce] I-D ACTION:draft-hurtta-eai-encapsulation-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --=-=-= Now this draft seems to be on Internet-Drafts directories. This is perhaps already handled? Anyway John Klensin was strongly encouraging to me write this draft. This draft specified aone kind encapsulation. Of course there is also other kind encapsulations available. If email header field is put to Downgraded: -header fields and original header field is removed, that is also just encapsulation. Also on some cases encapsulation is required (downgrade is not available) or message must be bounced. This draft provides handling of two cases: - signed email messages - attaching utf8smtp email message to non-utf8smtp email message Of course there may be other usages. DSNes was discussed? / Kari Hurtta --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Newsgroups: gmane.ietf.announce Subject: I-D ACTION:draft-hurtta-eai-encapsulation-00.txt Date: Tue, 07 Nov 2006 18:50:01 -0500 Message-ID: Reply-To: internet-drafts@ietf.org Return-path: X-Mailman-Version: 2.1.5 Precedence: list List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org Xref: news.gmane.org gmane.ietf.announce:16211 Archived-At: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===-=-=" --===-=-= A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Encapsulation mechanism for Email Address Internationalization (EAI) Author(s) : K. Hurtta Filename : draft-hurtta-eai-encapsulation-00.txt Pages : 42 Date : 2006-11-7 The Email Address Internationalization (EAI) is implemented by allowing UTF-8 characters in SMTP envelope and mail headers. To deliver email which uses UTF-8 on email headers through EAI incompliant environment converting (i.e downgrading) or encapsulation mechanism is required. Some of UTF-8 email may sign email headers or email header fields. This document describes mechanism for encapsulation when converting can not be used because of signed email headers. Encapsulation may also used to forward EAI email through EAI incompliant environment that way that original EAI email can be recovered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hurtta-eai-encapsulation-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hurtta-eai-encapsulation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hurtta-eai-encapsulation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --===-=-= Content-Type: multipart/alternative; boundary="====-=-=" --====-=-= Content-Type: message/external-body; access-type=mail-server Content-Type: text/plain Content-ID: <2006-11-7151809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hurtta-eai-encapsulation-00.txt --====-=-= Content-Type: message/external-body; name=draft-hurtta-eai-encapsulation-00.txt; access-type=anon-ftp Content-Type: text/plain Content-ID: <2006-11-7151809.I-D@ietf.org> --====-=-=-- --===-=-= Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --===-=-=-- --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --=-=-=-- From ima-bounces@ietf.org Sat Nov 11 07:25:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Girv7-0002Zu-Cy; Sat, 11 Nov 2006 07:25:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Girv6-0002ZK-Lm for ima@ietf.org; Sat, 11 Nov 2006 07:25:12 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Girv5-0006F1-Cg for ima@ietf.org; Sat, 11 Nov 2006 07:25:12 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Giruw-0001sj-53 for ima@ietf.org; Sat, 11 Nov 2006 13:25:02 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 13:25:02 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 13:25:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] [gmane.ietf.announce] I-D ACTION:draft-hurtta-eai-encapsulation-00.txt Date: 11 Nov 2006 14:22:14 +0200 Lines: 35 Message-ID: <5dwt62mavd.fsf@Hurtta06k.keh.iki.fi> References: <5d1woanpnw.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > Now this draft seems to be on Internet-Drafts directories. > > This is perhaps already handled? > > Anyway John Klensin was strongly encouraging > to me write this draft. > > This draft specified aone kind encapsulation. Of course > there is also other kind encapsulations available. > > If email header field is put to Downgraded: -header fields > and original header field is removed, that is also just > encapsulation. > > Also on some cases encapsulation is required (downgrade is > not available) or message must be bounced. > > This draft provides handling of two cases: > - signed email messages > - attaching utf8smtp email message to non-utf8smtp > email message I forgotten one case: - It also provides tunneling between two isolated utf8smtp isslands via non-utf8smtp environment. > Of course there may be other usages. DSNes was discussed? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 11 07:51:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GisKW-0001Xd-Pb; Sat, 11 Nov 2006 07:51:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GisKW-0001XY-3s for ima@ietf.org; Sat, 11 Nov 2006 07:51:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GisKU-0007fv-MV for ima@ietf.org; Sat, 11 Nov 2006 07:51:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GisKO-0005hO-QF for ima@ietf.org; Sat, 11 Nov 2006 13:51:20 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 13:51:20 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 13:51:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: quoted-printable <-> base64 (Re: [EAI] [gmane.ietf.announce] I-D ACTION:draft-hurtta-eai-encapsulation-00.txt) Date: 11 Nov 2006 14:51:14 +0200 Lines: 51 Message-ID: <5dpsbum9j1.fsf@Hurtta06k.keh.iki.fi> References: <5d1woanpnw.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > Now this draft seems to be on Internet-Drafts directories. > > This is perhaps already handled? > > Anyway John Klensin was strongly encouraging > to me write this draft. > > This draft specified aone kind encapsulation. Of course > there is also other kind encapsulations available. Open issue is what to do when content-transfer-encoding is changed between non-identity encodings during transport. That means conversion quoted-printable <-> base64. If that conversion happens, it is impossible to return exactly same original email message. Of course reverse conversion is possible, but it is not possible to know exact quoted-printable or base64 encondig what was used. However this is also problem for S/MIME if it happens. draft-hurtta-eai-encapsulation-00 may however make it worse, because multipart/signed is often handled specially indication that "no conversions". That draft hidens multipart/signed (multipart/mixed is used instead on encapsulated message.) ( Conversions from identity (7bit, 8bit, binary) to quoted-printable or base64 are OK. ) RFC 2045 allows that kind conversions: | 6.5. Translating Encodings | | The quoted-printable and base64 encodings are designed so that | conversion between them is possible. The only issue that arises in | such a conversion is the handling of hard line breaks in quoted- | printable encoding output. When converting from quoted-printable to | base64 a hard line break in the quoted-printable form represents a | CRLF sequence in the canonical form of the data. It must therefore be | converted to a corresponding encoded CRLF in the base64 form of the | data. Similarly, a CRLF sequence in the canonical form of the data | obtained after base64 decoding must be converted to a quoted- | printable hard line break, but ONLY when converting text data. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 11 10:04:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiuOI-0005rL-NX; Sat, 11 Nov 2006 10:03:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiuOG-0005oA-AP for ima@ietf.org; Sat, 11 Nov 2006 10:03:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiuI2-00069q-2S for ima@ietf.org; Sat, 11 Nov 2006 09:57:05 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GiuHo-0002uF-S5 for ima@ietf.org; Sat, 11 Nov 2006 15:56:48 +0100 Received: from pd9fba981.dip0.t-ipconnect.de ([217.251.169.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 15:56:48 +0100 Received: from nobody by pd9fba981.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 15:56:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] [gmane.ietf.announce] I-D ACTION:draft-hurtta-eai-encapsulation-00.txt Date: Sat, 11 Nov 2006 15:55:46 +0100 Organization: Lines: 19 Message-ID: <4555E472.76A@xyzzy.claranet.de> References: <5d1woanpnw.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba981.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > Of course there may be other usages. DSNes was discussed? Whatever else happens, IMO we need text/utf8-header for the purposes of text/rfc822-headers (RFC 3462). It's one of those ugly "bounces-to" effects: Normally I'd think if somebody can send UTF8SMTP (s)he can also handle UTF8SMTP DSNs later. But the MAIL FROM mailbox address can be an ordinary mailbox, hopefully behind a downgrade relay. Do we need MUSTard somewhere that senders are supposed to know how to eat their own dogfood if it's rejected ? I-D ietf-eai-smptpext-02 says in 2.7.6 that DSNs are addressed in I-D.ietf-eai-dsn-00 later (?) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 11 13:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GixR5-0006eo-VY; Sat, 11 Nov 2006 13:18:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GixR4-0006ej-Fl for ima@ietf.org; Sat, 11 Nov 2006 13:18:34 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GixR2-0000g2-WF for ima@ietf.org; Sat, 11 Nov 2006 13:18:34 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GixQv-0007uG-VC for ima@ietf.org; Sat, 11 Nov 2006 19:18:25 +0100 Received: from pd9fba981.dip0.t-ipconnect.de ([217.251.169.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 19:18:25 +0100 Received: from nobody by pd9fba981.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 19:18:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-framework-03.txt Date: Sat, 11 Nov 2006 19:14:14 +0100 Organization: Lines: 98 Message-ID: <455612F6.139@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba981.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > Document is now in the posting queue. Here's a diff: http://tools.ietf.org/rfcdiff?url2=http%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-ietf-eai-framework-03.txt&difftype=--hwdiff > please check to verify that none of the many editorial > changes and clarifications have made things worse. 1) In 1.1 there's an "anchor1 placeholder" to the history of EAI, is that to a planned new section of the I-D ? Some historical background is often interesting to read, if that's what you have in mind. At the end of 1.2 a "do" was deleted, but I think you want "do not have" or "have no" (CTE). In 1.3 4th paragraph you have now 'an address is "non-ASCII", or a "UTF8SMTP" address'. In the 6th paragraph you define that the set of "UTF8SMTP" addresses is the union of the "all-ASCII" and the "non-ASCII" addresses. Based on that "UTF8SMTP" is not a synonym for "non-ASCII", but in the 4th paragraph it sounded like a synonym. Something's odd, maybe only a lack of caffeine on my side. Still in 1.3 8th paragraph you introduce the "i18mail user", should that now be "UTF8SMTP user" ? There are only three uses of "i18mail" in the draft, all in this paragraph. The added last sentence could be removed again if you change the two other occurences of "i18mail" to "UTF8SMTP". Do we need a definition of "mailing list" (10th paragraph) ? The new 11th paragraph (reject vs. NDN) is good. 3) In bullet 3 you added "conceptual process...called an MDA". Apparently you don't like that acronym. IMO you could get rid of it, it's not used or needed elsewhere in the draft. 4) In 4.1 point 1 "whatever encoding" (on both sides), are we sure about that ? Or could there be legit cases of an UTF-8 local part with an IDNA domain ? Point 2 issue 1389: it's okay. At the end of 4.1 there's still the old "_if_ the system implements IMAP it conforms to IMAP spec, ditto for POP.???" How about this: "if the system supports IMAP it has to conform to [EAI-imap], and if it supports POP to [EAI-pop]". And if it uses say squirrelmail they will upgrade this, too. That's issue #1390 (4.1 "POP") in Harald's list. In 4.3 "presumably using UTF-8" strike "presumably", UTF-8 is a decade beyond the stage when that was an open question. [[WP:AWW]] unless you think that UTF-7 or BOCU-1 are cute :-) 5) 5.1: s/rejected, or non-delivery/rejected, or a non-delivery/ 5.2: s/will be always be capable/will be always capable/ (?) s/emails or specifically/emails, or specifically/ s/If this done/If this is done/ That's a very interesting SHOULD in 5.2, and I like it. 6) 6.4, what caused the---strange---effect, an xml2rfc — ? Maybe use "an - ordinary - hyphen-minus". 6.6: s/Non-standard/Traditional/ (?) Otherwise I like 6.6. For 6.5 I'm not sure, delete it if you don't like 6.5, that's #1393 in Harald's list. 9) Maybe replace 1 of 2 [RFC 4690] by I-D.klensin-idnabis-issues, or better replace [Net-Unicode] by idnabis-issues. In the references that's listed as net-utf8-00 instead of ...-02 (?) 12) Kind of stupid, but there's a trick to get rid of the "work in progress" blurb if that's obviously not the case: Insert (instead of transclude) the complete element, and then remove "-Draft" in the seriesInfo="Internet-Draft", here for I-D.hoffman-imaa Nothing substantial, only minor editorial nits, ready to go. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 11 16:52:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj0lb-0002eW-7L; Sat, 11 Nov 2006 16:51:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj0lZ-0002a0-KX for ima@ietf.org; Sat, 11 Nov 2006 16:51:57 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj0lY-00057o-AZ for ima@ietf.org; Sat, 11 Nov 2006 16:51:57 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77E712596DB; Sat, 11 Nov 2006 22:48:54 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26077-08; Sat, 11 Nov 2006 22:48:47 +0100 (CET) Received: from [10.10.10.140] (adsl-66-122-107-58.dsl.snfc21.pacbell.net [66.122.107.58]) by eikenes.alvestrand.no (Postfix) with ESMTP id DDB7F2596D8; Sat, 11 Nov 2006 22:48:46 +0100 (CET) Date: Sat, 11 Nov 2006 13:51:45 -0800 From: Harald Alvestrand To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] [gmane.ietf.announce] I-D ACTION:draft-hurtta-eai-encapsulation-00.txt Message-ID: <1F352C8AFE1263159DEE50FE@[10.10.10.140]> In-Reply-To: <4555E472.76A@xyzzy.claranet.de> References: <5d1woanpnw.fsf@Hurtta06k.keh.iki.fi> <4555E472.76A@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 11. november 2006 15:55 +0100 Frank Ellermann wrote: > Kari Hurtta wrote: > >> Of course there may be other usages. DSNes was discussed? > > Whatever else happens, IMO we need text/utf8-header for the > purposes of text/rfc822-headers (RFC 3462). > > It's one of those ugly "bounces-to" effects: Normally I'd > think if somebody can send UTF8SMTP (s)he can also handle > UTF8SMTP DSNs later. But the MAIL FROM mailbox address can > be an ordinary mailbox, hopefully behind a downgrade relay. > > Do we need MUSTard somewhere that senders are supposed to > know how to eat their own dogfood if it's rejected ? I-D > ietf-eai-smptpext-02 says in 2.7.6 that DSNs are addressed > in I-D.ietf-eai-dsn-00 later (?) If rejected (at SMTP level), the sender is assumed to know what to do; after all, he sent the message. I don't think we can require that all MX records (or A if no MX) for the domain in the MAIL FROM address be to MTAs that handle the UTF8SMTP extension; that would be the requirement for saying that "senders must eat their own dogfood if a non-delivery report is returned". Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 11 18:22:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj2BI-0002N8-JV; Sat, 11 Nov 2006 18:22:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj2BH-0002MP-5w for ima@ietf.org; Sat, 11 Nov 2006 18:22:35 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj2BH-00050A-4K for ima@ietf.org; Sat, 11 Nov 2006 18:22:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gj2BF-0007Mk-Ok for ima@ietf.org; Sat, 11 Nov 2006 18:22:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gj2B7-0005jf-R2 for ima@ietf.org; Sun, 12 Nov 2006 00:22:25 +0100 Received: from pd9fba981.dip0.t-ipconnect.de ([217.251.169.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 00:22:25 +0100 Received: from nobody by pd9fba981.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 00:22:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] [gmane.ietf.announce] I-D ACTION:draft-hurtta-eai-encapsulation-00.txt Date: Sun, 12 Nov 2006 00:21:38 +0100 Organization: Lines: 14 Message-ID: <45565B02.4FBC@xyzzy.claranet.de> References: <5d1woanpnw.fsf@Hurtta06k.keh.iki.fi> <4555E472.76A@xyzzy.claranet.de> <1F352C8AFE1263159DEE50FE@[10.10.10.140]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba981.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > I don't think we can require that all MX records (or A if no MX) > for the domain in the MAIL FROM address be to MTAs that handle > the UTF8SMTP extension; that would be the requirement for saying > that "senders must eat their own dogfood if a non-delivery report > is returned". Yes, not REQUIRED, nobody's forced to accept / read NDNs. But a warning in the form of a SHOULD maybe, otherwise they won't get error reports, and could as well (or better) send MAIL FROM:<> Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 12 02:49:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjA4X-0004JV-OU; Sun, 12 Nov 2006 02:48:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjA4U-0004GV-1o for ima@ietf.org; Sun, 12 Nov 2006 02:48:06 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj9uz-0004vb-SD for ima@ietf.org; Sun, 12 Nov 2006 02:38:19 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gj9ur-0007MX-7J for ima@ietf.org; Sun, 12 Nov 2006 08:38:09 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 08:38:09 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 08:38:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: dogfood (Re: [EAI] [gmane.ietf.announce] I-D ACTION:draft-hurtta-eai-encapsulation-00.txt) Date: 12 Nov 2006 09:38:00 +0200 Lines: 145 Message-ID: <5du015t8rr.fsf_-_@Hurtta06k.keh.iki.fi> References: <5d1woanpnw.fsf@Hurtta06k.keh.iki.fi> <4555E472.76A@xyzzy.claranet.de> <1F352C8AFE1263159DEE50FE@[10.10.10.140]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand writes in gmane.ietf.ima: > --On 11. november 2006 15:55 +0100 Frank Ellermann > wrote: > > > Kari Hurtta wrote: > > > >> Of course there may be other usages. DSNes was discussed? > > > > Whatever else happens, IMO we need text/utf8-header for the > > purposes of text/rfc822-headers (RFC 3462). > > > > It's one of those ugly "bounces-to" effects: Normally I'd > > think if somebody can send UTF8SMTP (s)he can also handle > > UTF8SMTP DSNs later. But the MAIL FROM mailbox address can > > be an ordinary mailbox, hopefully behind a downgrade relay. > > > > Do we need MUSTard somewhere that senders are supposed to > > know how to eat their own dogfood if it's rejected ? I-D > > ietf-eai-smptpext-02 says in 2.7.6 that DSNs are addressed > > in I-D.ietf-eai-dsn-00 later (?) > > If rejected (at SMTP level), the sender is assumed to know what to do; > after all, he sent the message. > > I don't think we can require that all MX records (or A if no MX) for > the domain in the MAIL FROM address be to MTAs that handle the > UTF8SMTP extension; that would be the requirement for saying that > "senders must eat their own dogfood if a non-delivery report is > returned". > > Harald There is some nasty situations. I made following assumtions. 1) RET=FULL is asked by sender so full mail need to be returned on failure (just returning only header part on text/utf8-header is not option.) 2) Addresses gived on RCPT TO _and_ MAIL FROM point to some MX which do not announce UTF8SMTP. There may be other MXes which announce UTF8SMTP, but all MXes are not available on all points of delivery (for example tcp connectivity between some host/MX are limited by firewall or some host is down.) Ad is sender A is Ad's mailstore supporting UTF8SMTP Ao is Ad's outgoing mail relay supporting UTF8SMTP Ai is MX for domain of Ad which do not announce UTF8SMTP Ri is MX given for domain given on RCPT TO on picture +----------+ | | | Ai | +----------+ <-------------- | | | | +----------+ | | ^ | A | | | utf8smtp | +----------+ | | -------------> | | +----------+ | | | Ao | | utf8smtp | | | +----------+ | | v +----------+ | | | | | Ri | | | +----------+ 3) DSN format uses message/utf8 for returning original email. 4) When message leaves utf8smtp, embedded message/utf8 are downgraded to message/rfc822 with same rules which apply utf8smtp message downgrading. 5) Message uses header-type: UTF8 6) Ao detects that it can not downgrade message Now a) Ao generates DSN which incudes original messgae inside of message/utf8 because DSN includes message/utf8, it DSN itself must include Header-type: UTF8 RCPT TO for DSN is A then b) Ao detects that next MX for A (ie. Ai) do not announce UTF8SMTP then c) Ao tries downgrade DSN. - Downgrading DSN includes downgrading message inside of message/utf8 -> But that was not possible to downgrade message inside of message/utf8 (after all that was reason why DSN was generated) -> So next option is generate DSN because downgrade fails but now there is MAIL FROM:<> no DSN So with these assumptions end result is that sender will not get warning that downgrade of original mail fails. So some assumption must be changed. Which one? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 12 02:59:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjAFJ-0001KH-FK; Sun, 12 Nov 2006 02:59:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjAFI-0001K2-UH for ima@ietf.org; Sun, 12 Nov 2006 02:59:16 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjAFH-0004et-Gm for ima@ietf.org; Sun, 12 Nov 2006 02:59:16 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GjAFG-0000lh-08 for ima@ietf.org; Sun, 12 Nov 2006 08:59:14 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 08:59:13 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 08:59:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: DSN (Re: [EAI] [gmane.ietf.announce] I-D ACTION:draft-hurtta-eai-encapsulation-00.txt) Date: 12 Nov 2006 09:59:08 +0200 Lines: 78 Message-ID: <5dpsbtt7sj.fsf@Hurtta06k.keh.iki.fi> References: <5d1woanpnw.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > Now this draft seems to be on Internet-Drafts directories. > > This is perhaps already handled? > > Anyway John Klensin was strongly encouraging > to me write this draft. > > This draft specified aone kind encapsulation. Of course > there is also other kind encapsulations available. > > If email header field is put to Downgraded: -header fields > and original header field is removed, that is also just > encapsulation. > > Also on some cases encapsulation is required (downgrade is > not available) or message must be bounced. > > This draft provides handling of two cases: > - signed email messages > - attaching utf8smtp email message to non-utf8smtp > email message > > Of course there may be other usages. DSNes was discussed? On draft there is no mentioned usage on DSN notify. On this case it is 5.3. Attaching internationalized email message chapter which mostly apply. It is NOT 5.2. Downgrading of internationalized email message chapter. This 5.3. Attaching internationalized email message may perhaps need some additional text if it used on DSN. However that do not assume that attaching is done on MUA so on itselft it works. Chapter 5.3. Attaching internationalized email message seems not mention handling of error conditions as 5.2. Downgrading of internationalized email message does. Seems that I forgot add that text (anyway that must differentiate MUA and attaching message to DSN on MTA. ) Chapter 5.1.1. Encapsulation of recursive part defines output also on several cases where input is illegal, but mentions that these are error conditions. Handling of these error conditions are then defined on other chapters which refer to that chapter. Clearly on DSN case best handling is just produce output and otherwise ignore error condition. However using multipart/utf8-encapsulated; type=message; ... on DSN for attaching original message is not very good on situation when everyone supports UTF8SMTP. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 12 06:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjDMM-0008WU-C0; Sun, 12 Nov 2006 06:18:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjDML-0008WP-Q3 for ima@ietf.org; Sun, 12 Nov 2006 06:18:45 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjDMG-0007Dv-Fp for ima@ietf.org; Sun, 12 Nov 2006 06:18:45 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GjDLv-0007nJ-95 for ima@ietf.org; Sun, 12 Nov 2006 12:18:19 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 12:18:19 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 12:18:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 12 Nov 2006 13:18:05 +0200 Lines: 20 Message-ID: <5dmz6w29si.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [EAI] Random comment on http://www3.ietf.org/meetings/ietf-logs/eai/2006-11-09.html :-) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org [17:23:26] downgrading in the 8bit mime case similar [17:23:44] bouncing is problematic: blowback spam (aka joe jobs) [17:24:08] confidence in anti-spam required? [17:24:30] randy: do we really have another choice? [17:24:50] randy: proposals for better bounces exist MAIL FROM:<...> command on SMTP can be replaced with something else but I do not think that it task of that working group .... ( IE. Bounces are not sent, but instead retriaved by original sender of mail. However that kind changes are little too much for internet mail architecture.... ) / Kari Hurtta ( I guess that someone will then say "write draft", but I think that pain of misdirected bounces are not high enough compared with problems associated with change of architecture. ) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 12 09:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjGmD-0003Yl-9q; Sun, 12 Nov 2006 09:57:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjGmC-0003Yf-DF for ima@ietf.org; Sun, 12 Nov 2006 09:57:40 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjGmA-0005Oc-HG for ima@ietf.org; Sun, 12 Nov 2006 09:57:40 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GjGm1-0002O7-6S for ima@ietf.org; Sun, 12 Nov 2006 15:57:29 +0100 Received: from pd9fba965.dip0.t-ipconnect.de ([217.251.169.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 15:57:29 +0100 Received: from nobody by pd9fba965.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 15:57:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Random comment on http://www3.ietf.org/meetings/ietf-logs/eai/2006-11-09.html :-) Date: Sun, 12 Nov 2006 15:56:04 +0100 Organization: Lines: 29 Message-ID: <45573604.7216@xyzzy.claranet.de> References: <5dmz6w29si.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba965.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > I guess that someone will then say "write draft" Don't worry, 4408 is already published... > pain of misdirected bounces are not high enough > compared with problems associated with change of > architecture. ...it's unnecessary to change the 821-architecture with its literal reverse paths, only implementing it after that feature was killed is difficult. In I-D.crocker-email-arch-05 (5.1) it's a SHOULD. If nothing of 551, SPF, BATV is satisfying the pain could force us to replace SMTP by IM - if IM is good enough to replace SEND FROM maybe it can also handle MAIL FROM. I've no clue what bugs would expect us with xmpp, but it's designed to be TLS + UTF-8 ready. Wrt UTF8SMTP and its funny "UIGO" aspects, maybe we could address it at the MSA - the MSA could somehow verify that the reverse path can handle UTF8 DSNs, and otherwise reject the submission, a similar idea as in 4409 (6.1) "enforced submission rights". Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 13 02:18:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjW4C-0006MH-4N; Mon, 13 Nov 2006 02:17:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjW4A-0006M1-VT for ima@ietf.org; Mon, 13 Nov 2006 02:17:14 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjW49-00075Z-94 for ima@ietf.org; Mon, 13 Nov 2006 02:17:14 -0500 Received: (snipe 24306 invoked by uid 0); 13 Nov 2006 16:18:36 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.046730 secs); Received: from unknown (HELO ?192.168.10.206?) (Z???own@210.107.250.150) by unknown with SMTP; 13 Nov 2006 16:18:36 +0900 X-RCPTTO: nobody@xyzzy.claranet.de, ima@ietf.org Message-ID: <45581BEC.1020500@icu.ac.kr> Date: Mon, 13 Nov 2006 16:17:00 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-framework-03.txt References: <455612F6.139@xyzzy.claranet.de> In-Reply-To: <455612F6.139@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: > John C Klensin wrote: > >> Document is now in the posting queue. > > Here's a diff: > > http://tools.ietf.org/rfcdiff?url2=http%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-ietf-eai-framework-03.txt&difftype=--hwdiff > >> please check to verify that none of the many editorial >> changes and clarifications have made things worse. > > 1) > > In 1.1 there's an "anchor1 placeholder" to the history of > EAI, is that to a planned new section of the I-D ? Some > historical background is often interesting to read, if > that's what you have in mind. > > At the end of 1.2 a "do" was deleted, but I think you want > "do not have" or "have no" (CTE). > > In 1.3 4th paragraph you have now 'an address is "non-ASCII", > or a "UTF8SMTP" address'. In the 6th paragraph you define > that the set of "UTF8SMTP" addresses is the union of the > "all-ASCII" and the "non-ASCII" addresses. Based on that > "UTF8SMTP" is not a synonym for "non-ASCII", but in the 4th > paragraph it sounded like a synonym. Something's odd, maybe > only a lack of caffeine on my side. "Non-ASCII address" and "UTF8SMTP address" are not synonyms. Quite recently, most of "i18n-something" occurrences are replaced with "UTF8SMTP-something". During this process, this one seems to be replaced erroneously. > Still in 1.3 8th paragraph you introduce the "i18mail user", > should that now be "UTF8SMTP user" ? There are only three > uses of "i18mail" in the draft, all in this paragraph. The > added last sentence could be removed again if you change the > two other occurences of "i18mail" to "UTF8SMTP". > > Do we need a definition of "mailing list" (10th paragraph) ? Do we have a definition of it in other RFCs? > The new 11th paragraph (reject vs. NDN) is good. > > 3) > > In bullet 3 you added "conceptual process...called an MDA". > Apparently you don't like that acronym. IMO you could get > rid of it, it's not used or needed elsewhere in the draft. Original intent was (as far as I know) to clarify that some UTF8SMTP related jobs (e.g. down/up grading) can happen outside of SMTP process as shown in section 5. Since section 5 is self explanatory, we may remove this definition if it looks redundant. > > 4) > > In 4.1 point 1 "whatever encoding" (on both sides), are we > sure about that ? Or could there be legit cases of an UTF-8 > local part with an IDNA domain ? Point 2 issue 1389: it's > okay. OOPs. I am starting to confuse. ACE and UTF8 are encodings at different layers. For MTAs, IDNA domains are just in ASCII encoding that is also valid UTF8 encoding. > At the end of 4.1 there's still the old "_if_ the system > implements IMAP it conforms to IMAP spec, ditto for POP.???" > > How about this: "if the system supports IMAP it has to > conform to [EAI-imap], and if it supports POP to [EAI-pop]". > And if it uses say squirrelmail they will upgrade this, too. > That's issue #1390 (4.1 "POP") in Harald's list. > > In 4.3 "presumably using UTF-8" strike "presumably", UTF-8 > is a decade beyond the stage when that was an open question. > [[WP:AWW]] unless you think that UTF-7 or BOCU-1 are cute :-) > > 5) > > 5.1: s/rejected, or non-delivery/rejected, or a non-delivery/ > 5.2: s/will be always be capable/will be always capable/ (?) > s/emails or specifically/emails, or specifically/ > s/If this done/If this is done/ > That's a very interesting SHOULD in 5.2, and I like it. > > 6) > > 6.4, what caused the---strange---effect, an xml2rfc — ? > Maybe use "an - ordinary - hyphen-minus". Nothing strange. That is exactly how original text looks like. If you don't like it, hmmmmm... > > 6.6: s/Non-standard/Traditional/ (?) Otherwise I like 6.6. > For 6.5 I'm not sure, delete it if you don't like 6.5, > that's #1393 in Harald's list. > > 9) > > Maybe replace 1 of 2 [RFC 4690] by I-D.klensin-idnabis-issues, > or better replace [Net-Unicode] by idnabis-issues. In the > references that's listed as net-utf8-00 instead of ...-02 (?) > > 12) > > Kind of stupid, but there's a trick to get rid of the "work > in progress" blurb if that's obviously not the case: Insert > (instead of transclude) the complete element, > and then remove "-Draft" in the seriesInfo="Internet-Draft", > here for I-D.hoffman-imaa > > Nothing substantial, only minor editorial nits, ready to go. Thanks for careful review. > > Frank > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 13 03:19:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjX1W-0006oW-El; Mon, 13 Nov 2006 03:18:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjX1V-0006mz-9W for ima@ietf.org; Mon, 13 Nov 2006 03:18:33 -0500 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjX1R-00023C-Tp for ima@ietf.org; Mon, 13 Nov 2006 03:18:33 -0500 Received: from [10.201.0.182] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id kAD8HuvT021365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 00:18:00 -0800 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com kAD8HuvT021365 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1163405882; bh=vSAKdjwZE6JmFqRMgM1sOu5fJQg=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=ofuRLhIK4FmYgoFY huNh+niqqf+SqmoQjE4sauhht7dspgqPz0df26Tq/whLoQ8mIkZ10VukSZqweZyMhDQ xzlT5fUqdoQTFrWgfuLCeG5tlU+kJAqB/2aF6MYxqyQKTg3NSxCztKjgnRSk0nnnkAP SqHKZclexZS+s2oEVp1do= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com kAD8HuvT021365 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=a0g0R3vK9Vo0SQCRipqIvrL7nDJccWaT+FkyJTEIP+DJvCpCkb7Npw2u+xPgDlgq6 Px1kLejCaoPrU8jY5oPEN+l8zlFGm94IO+47ed+uJgKmNzLdcVTtRLal+w1yECw+2Hg Jqbf8mTQfhxdEjP+0DkL1yhNzOAb10VLhppAcsk= Date: Mon, 13 Nov 2006 01:17:54 -0700 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-framework-03.txt In-Reply-To: <455612F6.139@xyzzy.claranet.de> Message-ID: References: <455612F6.139@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 11 Nov 2006, Frank Ellermann wrote: > 6.4, what caused the---strange---effect, an xml2rfc — ? > Maybe use "an - ordinary - hyphen-minus". Ugh. If people find "---" as the plain ascii version of an em-dash to be ugly or distracting, then I would suggest rephrasing to avoid it. In this case, simply dropping the set-off phrase completely seems best: given the rest of the paragraph, it probably doesn't need to be explicitly called out that EAI-upgrade includes RFC 2047 decoding. I would much prefer that over using plain '-' where an em-dash is needed. Philip Guenther _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 13 08:21:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjbjF-0006rg-Gf; Mon, 13 Nov 2006 08:20:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjbjE-0006rY-Hs for ima@ietf.org; Mon, 13 Nov 2006 08:20:00 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjbjD-000111-5a for ima@ietf.org; Mon, 13 Nov 2006 08:20:00 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 13 Nov 2006 13:19:58 +0000 Message-ID: <455870F7.2050707@isode.com> Date: Mon, 13 Nov 2006 05:19:51 -0800 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: John C Klensin Subject: Re: [EAI] draft-ietf-eai-framework-03.txt References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > Document is now in the posting queue. > > As Harald indicated in the WG meeting yesterday, please review to be > sure that all issues in the tracker have been appropriately dealt > with. In addition, please check to verify that none of the many > editorial changes and clarifications have made things worse. >4.2. Transmission of Email Header Fields in UTF-8 Encoding > There are many places in MUAs or in user presentation in which email > addresses or domain names appear. Examples include the conventional > From, To, or Cc header fields; In-Reply-To fields that may contain > addresses or domain names; Message-ID fields that normally contain > domain names (but that may be a special case); and in message bodies. The In-Reply-To should be mentioned together with the Message-Id? Suggested replacement (also changed "fields" to "header fields"): >4.2. Transmission of Email Header Fields in UTF-8 Encoding > > There are many places in MUAs or in user presentation in which email > addresses or domain names appear. Examples include the conventional > From, To, or Cc header fields; Message-ID and In-Reply-To header fields that normally contain > domain names (but that may be a special case); and in message bodies. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 13 10:32:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjdmp-0002dR-9Q; Mon, 13 Nov 2006 10:31:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjdmn-0002dF-QX for ima@ietf.org; Mon, 13 Nov 2006 10:31:49 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjdmj-0001t4-JE for ima@ietf.org; Mon, 13 Nov 2006 10:31:49 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gjdlx-00021R-91 for ima@ietf.org; Mon, 13 Nov 2006 16:30:57 +0100 Received: from d252217.dialin.hansenet.de ([80.171.252.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 16:30:57 +0100 Received: from nobody by d252217.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 16:30:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-framework-03.txt Date: Mon, 13 Nov 2006 16:29:16 +0100 Organization: Lines: 19 Message-ID: <45588F4C.3BDB@xyzzy.claranet.de> References: <455612F6.139@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252217.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Philip Guenther wrote: > I would much prefer that over using plain '-' where an em-dash is needed. There simply is no — in text/plain US-ASCII, maybe you could emulate it with -- like this -- or similar. Let's see what xml2rfc 1.32pre2 does: | Something -- like this -- or similar. But--plaease not--this. Source: | Something — like this — or similar. | But—plaease not—this. With that you'd get a proper — in the HTML output of xml2rfc, and only two hyphens in the I-D and future RfC. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 13 10:59:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjeDS-0000O9-BI; Mon, 13 Nov 2006 10:59:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjeDQ-0000Nv-Rs for ima@ietf.org; Mon, 13 Nov 2006 10:59:20 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjeDP-00061A-IU for ima@ietf.org; Mon, 13 Nov 2006 10:59:20 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GjeDI-00005i-N4 for ima@ietf.org; Mon, 13 Nov 2006 16:59:13 +0100 Received: from d252217.dialin.hansenet.de ([80.171.252.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 16:59:12 +0100 Received: from nobody by d252217.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 16:59:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-framework-03.txt Date: Mon, 13 Nov 2006 16:57:31 +0100 Organization: Lines: 34 Message-ID: <455895EB.121F@xyzzy.claranet.de> References: <455612F6.139@xyzzy.claranet.de> <45581BEC.1020500@icu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252217.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yangwoo Ko wrote: >> Do we need a definition of "mailing list" (10th paragraph) ? > Do we have a definition of it in other RFCs? Yes, RFCs 1123 5.3.6(b) and 2821 3.10.2 define it wrt SMTP. = Nothing is wrong with the definition in section 1.3, but the = term "mailing list" is not needed anywhere in the document. >> In 4.1 point 1 "whatever encoding" (on both sides), are we >> sure about that ? Or could there be legit cases of an UTF-8 >> local part with an IDNA domain ? [...] > OOPs. I am starting to confuse. ACE and UTF8 are encodings > at different layers. For MTAs, IDNA domains are just in > ASCII encoding that is also valid UTF8 encoding. Here's an example (please pretend that my Latin-1 is UTF-8 :-) To: "F. M=F6ller" Cc: "G. M=FCller" Is the Cc: "illegal" in some way, because it didn't use "=F6ko" ? [aaa---bbb ccc---ddd] > If you don't like it, hmmmmm... See another article, xml2rfc would write aaa -- bbb ccc -- ddd Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 13 12:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjg1n-0001fX-Vh; Mon, 13 Nov 2006 12:55:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjg1m-0001fO-NW for ima@ietf.org; Mon, 13 Nov 2006 12:55:26 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjg1i-0005Sk-3e for ima@ietf.org; Mon, 13 Nov 2006 12:55:26 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew&man*ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.238) id 4558b183.75cd.c4 for ima@ietf.org; Mon, 13 Nov 2006 17:55:15 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kADHtDGM004675 for ; Mon, 13 Nov 2006 17:55:14 GMT Subject: Fwd: Re: [EAI] #1391: framework 5 - delivery to final delivery MTA References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4548AB10.3020704@alvestrand.no> <0BB299DFDCB48ABADA27F2B0@p3.JCK.COM> <454A0144.7050301@alvestrand.no> <454D1D77.4090004@alvestrand.no> Message-ID: To: "ima@ietf.org" From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Mon, 13 Nov 2006 17:55:12 -0000 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 04 Nov 2006 23:08:39 -0000, Harald Alvestrand wrote: > Charles Lindsey wrote: >> >> Exactly so. But the alias expansion cannot take place without looking >> at the , and as John frequently points out to us, MTAs that >> are not "final delivery MTA"s are not supposed to look inside the >> . >> >> This is not a technical problem - rather a possible confusion of >> terminology. But it is worse in the case of UTF8SMTP because "looking >> at the " may require a little upgrading first (but not of >> the rest of the message, because it may yet meet another non-UTF8SMTP >> MTA on its further travels). > Charles, > > PLEASE respect the decision of the WG to: > - abandon ATOMIC > - require use of ALT-ADDR for downgrading > Sure, I have accepted that. I had just not spotted that all possibility of needing to upgrade a had finally evaporated. But there is still a problem even if the is not involved in upgrading. Earlier in this thread, you said: If it is part of alias expansion (no change to envelope sender), the MTA is not final. If it is part of mailing list expansion (change to envelope sender), the MTA is final. So consider the case where a message is forwarded through a series of MTAs (by alias expansion using .forward files/whatever) before it finally catches up with the final recipient. Various 'ordinary' MTAs too, any of which might need to 'downgrade' from UTF8SMTP. MSA->MTA->MTA->aliasingMTA->MTA->aliasingMTA->MTA->finalMTA->MDA So according to your definition, the ones marked 'aliasing MTA' are not 'final' - just the very last one. Hence there can only be one "final" one in the chain. But that is not what John's latest text in draft-03 says: [[anchor3: WGLC, Framework 5, Issue #1391]] However, the term "final delivery MTA" is used in this document in a fashion equivalent to the term "delivery system" or "final delivery system" of RFC 2821. This is the SMTP server that controls the format of, and is permitted to inspect and interpret, local-part addresses. It receives messages from the network for delivery to mailboxes or other local processing, rather than relaying. From the perspective of the network, any local delivery arrangements such as saving to a message store, handoff to specific message delivery programs or agents, and mechanisms for retrieving messages are all "behind" the final delivery MTA and hence not part of the SMTP transport or delivery process. For it states explicitly that only the "final delivery MTA" is "is permitted to inspect and interpret, local-part addresses". But clearly the ones that do the intermediate aliasing also need to "inspect and interpret" the . So the wording is still inconsistent. It might be fixed in one of thwo ways. My preference would be to consider each aliasingMTAs as "final", and then to mention "forwarding" or "aliasing" as one of the things that might come under "local delivery". -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 13 16:58:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjjoj-0006AL-IN; Mon, 13 Nov 2006 16:58:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjjoh-0006AB-H0 for ima@ietf.org; Mon, 13 Nov 2006 16:58:11 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjjof-0007Gs-4H for ima@ietf.org; Mon, 13 Nov 2006 16:58:11 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gjjoe-0008ge-Cy; Mon, 13 Nov 2006 16:58:08 -0500 Date: Mon, 13 Nov 2006 16:58:07 -0500 From: John C Klensin To: Alexey Melnikov Subject: Re: [EAI] draft-ietf-eai-framework-03.txt Message-ID: <2C87D9670D7A98D725DCC448@p3.JCK.COM> In-Reply-To: <455870F7.2050707@isode.com> References: <455870F7.2050707@isode.com> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 13 November, 2006 05:19 -0800 Alexey Melnikov wrote: > John C Klensin wrote: > >> Document is now in the posting queue. >> >> As Harald indicated in the WG meeting yesterday, please >> review to be sure that all issues in the tracker have been >> appropriately dealt with. In addition, please check to >> verify that none of the many editorial changes and >> clarifications have made things worse. > > >4.2. Transmission of Email Header Fields in UTF-8 Encoding > >> There are many places in MUAs or in user presentation in >> which email addresses or domain names appear. Examples >> include the conventional From, To, or Cc header fields; >> In-Reply-To fields that may contain addresses or domain >> names; Message-ID fields that normally contain domain names >> (but that may be a special case); and in message bodies. > > The In-Reply-To should be mentioned together with the > Message-Id? > Suggested replacement (also changed "fields" to "header > fields"): > >> 4.2. Transmission of Email Header Fields in UTF-8 Encoding >> >> There are many places in MUAs or in user presentation in >> which email addresses or domain names appear. Examples >> include the conventional From, To, or Cc header fields; >> Message-ID and In-Reply-To header fields that normally >> contain domain names (but that may be a special case); and >> in message bodies. First, everyone, please remember that "for example" or "examples include" is intended to convey "this is not a comprehensive list". Always putting "header" in front of fields is ok, but has not been our conventional usage. If we do it, someone (presumably the co-chairs) need to remember to advise the RFC Editor to not change what may seem to them to be uncomfortable language. Second, and more important, the previous version was more like the above than the current one. Someone complained about it because (they said) In-Reply-To fields may actually contain addresses, not just domain names. So, I'm happy to make this change if others agree, but I don't want to keep cycling on this text. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 13 17:04:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjjv7-0001b2-19; Mon, 13 Nov 2006 17:04:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjjv5-0001ax-Ad for ima@ietf.org; Mon, 13 Nov 2006 17:04:47 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjjv3-0008AV-W8 for ima@ietf.org; Mon, 13 Nov 2006 17:04:47 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gjjuy-0008mI-Vi; Mon, 13 Nov 2006 17:04:41 -0500 Date: Mon, 13 Nov 2006 17:04:40 -0500 From: John C Klensin To: Philip Guenther , Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-framework-03.txt Message-ID: In-Reply-To: References: <455612F6.139@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 13 November, 2006 01:17 -0700 Philip Guenther wrote: > On Sat, 11 Nov 2006, Frank Ellermann wrote: >> 6.4, what caused the---strange---effect, an xml2rfc — ? >> Maybe use "an - ordinary - hyphen-minus". > > Ugh. If people find "---" as the plain ascii version of an > em-dash to be ugly or distracting, then I would suggest > rephrasing to avoid it. In this case, simply dropping the > set-off phrase completely seems best: given the rest of the > paragraph, it probably doesn't need to be explicitly called > out that EAI-upgrade includes RFC 2047 decoding. I would much > prefer that over using plain '-' where an em-dash is needed. (1) FWIW, the _very_ standard typographic convention for an em-dash is "--", not "---" and certainly not "-". There is controversy among style manuals whether it should be typed as foo--bar or as foo -- bar The source now (just corrected) uses the latter consistently. XML2RFC will do whatever it does. (2) Also FWIW, there is no "—" construction in the XML text. The "---" actually appeared, presumably as the result of a typographical error, or too-broad find-and-replace operation, sometime. It has been fixed. (2) Trying to fine-tune this is a waste of time: the RFC Editor will apply whatever conventions they are using when the document gets to them. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 13 17:07:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjjxk-0002WT-Q6; Mon, 13 Nov 2006 17:07:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjjxj-0002WN-FK for ima@ietf.org; Mon, 13 Nov 2006 17:07:31 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjjxi-0008TG-4H for ima@ietf.org; Mon, 13 Nov 2006 17:07:31 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gjjxh-0008od-Ll; Mon, 13 Nov 2006 17:07:29 -0500 Date: Mon, 13 Nov 2006 17:07:28 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] draft-ietf-eai-framework-03.txt Message-ID: <0AB9E511FCDF038C03D40ABA@p3.JCK.COM> In-Reply-To: <455895EB.121F@xyzzy.claranet.de> References: <455612F6.139@xyzzy.claranet.de> <45581BEC.1020500@icu.ac.kr> <455895EB.121F@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 13 November, 2006 16:57 +0100 Frank Ellermann wrote: > Yangwoo Ko wrote: >=20 >>> Do we need a definition of "mailing list" (10th paragraph) ? >> Do we have a definition of it in other RFCs? >=20 > Yes, RFCs 1123 5.3.6(b) and 2821 3.10.2 define it wrt SMTP. =20 >=20 > Nothing is wrong with the definition in section 1.3, but the=20 > term "mailing list" is not needed anywhere in the document. Someone told me/us to put it in. If there is consensus, we can remove it, but we are getting down rather far into the nits = here. >>> In 4.1 point 1 "whatever encoding" (on both sides), are we >>> sure about that ? Or could there be legit cases of an UTF-8 >>> local part with an IDNA domain ? > [...] >> OOPs. I am starting to confuse. ACE and UTF8 are encodings >> at different layers. For MTAs, IDNA domains are just in >> ASCII encoding that is also valid UTF8 encoding. >=20 > Here's an example (please pretend that my Latin-1 is UTF-8 :-) >=20 > To: "F. M=C3=B6ller" > Cc: "G. M=C3=BCller" >=20 > Is the Cc: "illegal" in some way, because it didn't use = "=C3=B6ko" > ? No. It is not. I might be silly, but there is nothing illegal or invalid about it. It is also impossible to prohibit, which has been said many times. If someone really believes this is worth fixing, suggest text (and get a new issue number from Harald). > [aaa---bbb ccc---ddd] >... Dealt with; see other note. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 14 13:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2v1-0007eb-Lp; Tue, 14 Nov 2006 13:21:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2v0-0007WI-A3 for ima@ietf.org; Tue, 14 Nov 2006 13:21:58 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk2uz-0004FN-0i for ima@ietf.org; Tue, 14 Nov 2006 13:21:58 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gk2ud-0007Kw-OJ for ima@ietf.org; Tue, 14 Nov 2006 19:21:35 +0100 Received: from d255019.dialin.hansenet.de ([80.171.255.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Nov 2006 19:21:35 +0100 Received: from nobody by d255019.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Nov 2006 19:21:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-framework-03.txt Date: Tue, 14 Nov 2006 19:19:54 +0100 Organization: Lines: 37 Message-ID: <455A08CA.2AC0@xyzzy.claranet.de> References: <455612F6.139@xyzzy.claranet.de> <45581BEC.1020500@icu.ac.kr> <455895EB.121F@xyzzy.claranet.de> <0AB9E511FCDF038C03D40ABA@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255019.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > we are getting down rather far into the nits here. Yes, ignore what you don't need, I just read it top down using a fine comb for anything attracting my attention - from serial comma over typos and unused definitions and mdash oddities up to one remotely substantial question: >> To: "F. M=FCller" >> Cc: "G. M=F6ller" >> Is the Cc: "illegal" in some way, because it didn't use "=F6ko" ? = > No. It is not. I might be silly, but there is nothing illegal > or invalid about it. Good... > It is also impossible to prohibit =2E..better. > which has been said many times. I missed that, and the "whatever encoding" distracted me, like the "presumably" in another paragraph. (Just checking BCP 18 again - the ultimatum for worldwide UTF-8 runs out in about 41 years... ;-) Maybe say "can and reasonably should be applied to both" LHS + RHS, instead of only "should be applied to both". A bit more verbose, but IMO clearer. The short form could tempt readers to hallucinate an uppercase SHOULD. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 14 21:44:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkAkl-0007pl-23; Tue, 14 Nov 2006 21:43:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkAki-0007i9-Fm for ima@ietf.org; Tue, 14 Nov 2006 21:43:52 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkAkh-0002XK-5L for ima@ietf.org; Tue, 14 Nov 2006 21:43:52 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E68832596CD; Wed, 15 Nov 2006 03:40:50 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32044-02; Wed, 15 Nov 2006 03:40:46 +0100 (CET) Received: from [172.19.7.130] (adsl-66-122-107-58.dsl.snfc21.pacbell.net [66.122.107.58]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51D402596CB; Wed, 15 Nov 2006 03:40:45 +0100 (CET) Date: Tue, 14 Nov 2006 18:43:42 -0800 From: Harald Alvestrand To: John C Klensin , Frank Ellermann , ima@ietf.org Subject: Re: [EAI] draft-ietf-eai-framework-03.txt Message-ID: In-Reply-To: <0AB9E511FCDF038C03D40ABA@p3.JCK.COM> References: <455612F6.139@xyzzy.claranet.de> <45581BEC.1020500@icu.ac.kr> <455895EB.121F@xyzzy.claranet.de> <0AB9E511FCDF038C03D40ABA@p3.JCK.COM> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 13. november 2006 17:07 -0500 John C Klensin wrote: > > > --On Monday, 13 November, 2006 16:57 +0100 Frank Ellermann > wrote: > >> Yangwoo Ko wrote: >> >>>> Do we need a definition of "mailing list" (10th paragraph) ? >>> Do we have a definition of it in other RFCs? >> >> Yes, RFCs 1123 5.3.6(b) and 2821 3.10.2 define it wrt SMTP. >> >> Nothing is wrong with the definition in section 1.3, but the >> term "mailing list" is not needed anywhere in the document. > > Someone told me/us to put it in. If there is consensus, we can > remove it, but we are getting down rather far into the nits here. I believe it came in when we decided to fold the terminology section from the scenarios doc into the framework doc; the scenarios doc does need the term. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 22 23:07:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn5rH-0001jB-B5; Wed, 22 Nov 2006 23:06:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn5rG-0001iT-Dd for ima@ietf.org; Wed, 22 Nov 2006 23:06:42 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn5pZ-0006rm-Ti for ima@ietf.org; Wed, 22 Nov 2006 23:04:59 -0500 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by twnic.net.tw (8.13.8/8.13.8) with SMTP id kAN44rnS001246; Thu, 23 Nov 2006 12:04:54 +0800 Message-ID: <040501c70eb4$ae5ed0a0$c7d348d3@aabbeell> From: "abel" To: , "Kari Hurtta" References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi> Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: Thu, 23 Nov 2006 12:05:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by twnic.net.tw id kAN44rnS001246 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I read the sendmail source about sendmail/header.c for this issue the chompheader() function will modify the Header value about the mail address An EAI mail send headers are (such as To) : To: "=E8=A8=B1=E4=B9=83=E6=96=87(e)" <=E8=A8=B1=E4=B9=83=E6=96=87@=E9=83=B5= =E4=BB=B6.twnic.tw>, "=E6=B5=8B=E8=AF=95(e)" <=E6=B5=8B=E8=AF=95@test1.qmail.asrc.cn> They become : To: "\"=E8=A8=B1=E4=B9=83=E6=96=87(e)\" <=E8=A8=B1=E4=B9=83=E6=96=87@=E9=83= =B5=E4=BB=B6.twnic.tw", "\"=E6=B5=8B=E8=AF=95(e)\" <=E6=B5=8B=E8=AF=95@test1.qmail.asrc.c= n" If EAI use '[' ']' then without this issue , even if "" transmited. I think "> would have some side effects on MTAs or IRI. Abel ----- Original Message -----=20 From: "Kari Hurtta" To: Sent: Friday, November 03, 2006 10:49 PM Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again > Kari Hurtta writes in gmane.ietf.ima: > > <...> > > Possible other possibilities: > > > > 1) > > > > angle-addr =3D [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-addr= ess] > > > > alt-address =3D [CFWS] "[" addr-spec "]" [CFWS] > > > > > > this was suggested by someone other, but that do not look much better= if > > [ ] are used. > > > > 2) > > > > angle-addr =3D [CFWS] "<" utf8-addr-spec [alt-address] ">" [C= FWS] > > > > alt-address =3D [CFWS] ',' addr-spec [CFWS] > > > > 3) > > > > angle-addr =3D [CFWS] "<" utf8-addr-spec [alt-address] ">" [C= FWS] > > > > alt-address =3D [CFWS] ';' addr-spec [CFWS] > > > > 4) > > > > angle-addr =3D [CFWS] "<" utf8-addr-spec [alt-address] ">" [C= FWS] > > > > alt-address =3D [CFWS] "<" addr-spec ">" [CFWS] > > > > perhaps that is not so bad as it looks? > > ( this alternative is best so far? ) > > > > > 5) > > > > angle-addr =3D [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-addr= ess] > > > > alt-address =3D [CFWS] "<" addr-spec ">" [CFWS] > > 6) > angle-addr =3D [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-addr= ess] > alt-address =3D addr-spec [CFWS] > > > 7) > > angle-addr =3D [CFWS] "<" utf8-addr-spec [alt-address] ">" [C= FWS] > alt-address =3D [CFWS] ':' [CFWS] addr-spec [CFWS] > > Perhaps not good. > > > > > > Note that this all possibilities avoid characters used on atext. > > specials =3D "(" / ")" / ; Special characters used in > "<" / ">" / ; other parts of the syntax > "[" / "]" / > ":" / ";" / > "@" / "\" / > "," / "." / > DQUOTE > > > There is not a lot of characters (if unicode characters > 127 > are not used.) > > > / Kari Hurtta > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 01:23:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn7z8-00058E-1l; Thu, 23 Nov 2006 01:22:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn7z7-000589-48 for ima@ietf.org; Thu, 23 Nov 2006 01:22:57 -0500 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn7z5-0005QA-Jy for ima@ietf.org; Thu, 23 Nov 2006 01:22:57 -0500 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20061107) with ESMTP id kAN6MmwS031036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Nov 2006 08:22:48 +0200 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id kAN6Mmac008687 ; Thu, 23 Nov 2006 08:22:48 +0200 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id kAN6Ml2D025688 ; Thu, 23 Nov 2006 08:22:47 +0200 Received: by siilo.fmi.fi id kAN6MlpT025685; Thu, 23 Nov 2006 08:22:47 +0200 Message-Id: <200611230622.kAN6MlpT025685@siilo.fmi.fi> Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again In-Reply-To: <040501c70eb4$ae5ed0a0$c7d348d3@aabbeell> To: abel Date: Thu, 23 Nov 2006 08:22:47 +0200 (EET) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123e (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20061123/22596/01 X-Filter: smtp1gate: ID 22593/01, 1 parts scanned for known viruses X-Filter: torkku: ID 4204/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 22593/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> abel [ Charset UTF-8 unsupported, converting... ] > I read the sendmail source about sendmail/header.c for this issue > the chompheader() function will modify the Header value about the mail > address > > An EAI mail send headers are (such as To) : > > To: "???(e)" >, > "??(e)" > > > They become : > > To: "\"???(e)\" , > "\"??(e)\" > > If EAI use '[' ']' then without this issue , even if " [ald-address]>" transmited. > I think "> would have some side effects on MTAs or IRI. > > Abel Yes, that means that sendmail needs modify sendmail/header.c before it can announce UTF8SMTP Of course that it is expected that any parser do not handle that extended syntax (where there is fallback address), if it do not support UTF8SMTP Problem is that extended syntax must dot leak outside of UTF8SMTP environment. On SMTP this is easy. On case where mails are readed from local spool (/var/mail/{user} for example) by MUA, is difficult. > ----- Original Message ----- > From: "Kari Hurtta" > To: > Sent: Friday, November 03, 2006 10:49 PM > Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again > > > > Kari Hurtta writes in gmane.ietf.ima: > > > > <...> > > > Possible other possibilities: > > > > > > 1) > > > > > > angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] > > > > > > alt-address = [CFWS] "[" addr-spec "]" [CFWS] > > > > > > > > > this was suggested by someone other, but that do not look much better if > > > [ ] are used. > > > > > > 2) > > > > > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > > > > > alt-address = [CFWS] ',' addr-spec [CFWS] > > > > > > 3) > > > > > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > > > > > alt-address = [CFWS] ';' addr-spec [CFWS] > > > > > > 4) > > > > > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > > > > > alt-address = [CFWS] "<" addr-spec ">" [CFWS] > > > > > > perhaps that is not so bad as it looks? > > > > ( this alternative is best so far? ) > > > > > > > > 5) > > > > > > angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] > > > > > > alt-address = [CFWS] "<" addr-spec ">" [CFWS] > > > > 6) > > angle-addr = [CFWS] "<" utf8-addr-spec ">" [CFWS] [alt-address] > > alt-address = addr-spec [CFWS] > > > > > > 7) > > > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > alt-address = [CFWS] ':' [CFWS] addr-spec [CFWS] > > > > Perhaps not good. > > > > > > > > > > Note that this all possibilities avoid characters used on atext. > > > > specials = "(" / ")" / ; Special characters used in > > "<" / ">" / ; other parts of the syntax > > "[" / "]" / > > ":" / ";" / > > "@" / "\" / > > "," / "." / > > DQUOTE > > > > > > There is not a lot of characters (if unicode characters > 127 > > are not used.) / Kari Hurtta > > _______________________________________________ > > IMA mailing list > > IMA@ietf.org > > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 01:48:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn8Nf-0007AW-Ql; Thu, 23 Nov 2006 01:48:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn8Nf-0007AF-Hb for ima@ietf.org; Thu, 23 Nov 2006 01:48:19 -0500 Received: from smtp2gate.fmi.fi ([193.166.223.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn8Nb-0005ac-UQ for ima@ietf.org; Thu, 23 Nov 2006 01:48:19 -0500 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp2gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20061107) with ESMTP id kAN6mExL004646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 23 Nov 2006 08:48:14 +0200 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id kAN6mEUa008989 for ; Thu, 23 Nov 2006 08:48:14 +0200 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id kAN6mD3o027660 ; Thu, 23 Nov 2006 08:48:13 +0200 Received: by siilo.fmi.fi id kAN6mDpB027657; Thu, 23 Nov 2006 08:48:13 +0200 Message-Id: <200611230648.kAN6mDpB027657@siilo.fmi.fi> Subject: UTF8SMTP escape on local mail (Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again) In-Reply-To: <200611230622.kAN6MlpT025685@siilo.fmi.fi> To: ima@ietf.org Date: Thu, 23 Nov 2006 08:48:13 +0200 (EET) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123e (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp2gate: 3 received headers rewritten with id 20061123/19046/01 X-Filter: smtp2gate: ID 3561/01, 1 parts scanned for known viruses X-Filter: torkku: ID 4222/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp2gate: ID 3561/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> Kari Hurtta > >>> abel > Yes, that means that sendmail needs modify sendmail/header.c > before it can announce UTF8SMTP > > Of course that it is expected that any parser do not handle that > extended syntax (where there is fallback address), if it do not support UTF8SMTP > > Problem is that extended syntax must dot leak outside of UTF8SMTP environment. > On SMTP this is easy. > > On case where mails are readed from local spool (/var/mail/{user} for example) > by MUA, is difficult. Perhaps most logical solution is use /var/mail/{user}.utf8 for UTF8SMTP messages and /var/mail/{user} for traditional messages however that is not on scope of IETF specifications ? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 03:51:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAIL-0005hJ-K9; Thu, 23 Nov 2006 03:50:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAIL-0005h2-3e for ima@ietf.org; Thu, 23 Nov 2006 03:50:57 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GnAIF-0006Gg-FP for ima@ietf.org; Thu, 23 Nov 2006 03:50:57 -0500 Received: (snipe 13574 invoked by uid 0); 23 Nov 2006 17:52:16 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.025528 secs); Received: from unknown (HELO ?192.168.10.145?) (Z???own@210.107.249.23) by unknown with SMTP; 23 Nov 2006 17:52:16 +0900 X-RCPTTO: hurtta+ietf@siilo.fmi.fi, ima@ietf.org, yangwooko@gmail.com Message-ID: <456560E4.2050903@icu.ac.kr> Date: Thu, 23 Nov 2006 17:50:44 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: UTF8SMTP escape on local mail (Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again) References: <200611230648.kAN6mDpB027657@siilo.fmi.fi> In-Reply-To: <200611230648.kAN6mDpB027657@siilo.fmi.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: >>>> Kari Hurtta >>>>> abel >> Yes, that means that sendmail needs modify sendmail/header.c >> before it can announce UTF8SMTP >> >> Of course that it is expected that any parser do not handle that >> extended syntax (where there is fallback address), if it do not support UTF8SMTP >> >> Problem is that extended syntax must dot leak outside of UTF8SMTP environment. >> On SMTP this is easy. >> >> On case where mails are readed from local spool (/var/mail/{user} for example) >> by MUA, is difficult. > > Perhaps most logical solution is use > /var/mail/{user}.utf8 for UTF8SMTP messages > and /var/mail/{user} for traditional messages > > > however that is not on scope of IETF specifications ? I cannot but agree with you that we need a way to differentiate them because stored message is not protected by ESMTP. Differentiation is made possible based on information found either in mail message itself (e.g. header) or out side of it (e.g. as shown in your example). If we choose to go with the former, it will be within the scope of IETF. Otherwise, it is as you said. > > / Kari Hurtta > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 04:15:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAfe-000132-1s; Thu, 23 Nov 2006 04:15:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAfc-00012v-Iv for ima@ietf.org; Thu, 23 Nov 2006 04:15:00 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnAfY-0001Zu-Sf for ima@ietf.org; Thu, 23 Nov 2006 04:15:00 -0500 Received: from [211.72.211.94] (pc094.twnic.net.tw [211.72.211.94]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id kAN9EoCx016002; Thu, 23 Nov 2006 17:14:55 +0800 Message-ID: <45656946.70706@twnic.net.tw> Date: Thu, 23 Nov 2006 17:26:30 +0800 From: Jeff User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again References: <200611230622.kAN6MlpT025685@siilo.fmi.fi> In-Reply-To: <200611230622.kAN6MlpT025685@siilo.fmi.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Kari Hurtta , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >> I read the sendmail source about sendmail/header.c for this issue >> the chompheader() function will modify the Header value about the mail >> address >> >> An EAI mail send headers are (such as To) : >> >> To: "???(e)" >, >> "??(e)" > >> >> They become : >> >> To: "\"???(e)\" , >> "\"??(e)\" >> >> If EAI use '[' ']' then without this issue , even if "> [ald-address]>" transmited. >> I think "> would have some side effects on MTAs or IRI. >> >> Abel > > Yes, that means that sendmail needs modify sendmail/header.c > before it can announce UTF8SMTP > > Of course that it is expected that any parser do not handle that > extended syntax (where there is fallback address), if it do not support UTF8SMTP > > Problem is that extended syntax must dot leak outside of UTF8SMTP environment. > On SMTP this is easy. > > On case where mails are readed from local spool (/var/mail/{user} for example) > by MUA, is difficult. > I think Abel is trying to say that the cost on updating parser to fit > syntax is more complicate then . Since '<' and '>' are VERY special token in email address representation. I believe not only Sendmail had this problem, the other mail server also does. If I'm mail software vendor who trying to provide EAI feature, it is better for me update as few code as possible. Not un-solvable but deployment concern I think. Jeff Yeh -TWNIC _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 08:43:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnEqr-0001Tv-MJ; Thu, 23 Nov 2006 08:42:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnEqp-0001T7-Rg for ima@ietf.org; Thu, 23 Nov 2006 08:42:51 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnEqo-0004k6-DV for ima@ietf.org; Thu, 23 Nov 2006 08:42:51 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9BB072596BD; Thu, 23 Nov 2006 14:39:37 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25178-02; Thu, 23 Nov 2006 14:39:32 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 073732596BB; Thu, 23 Nov 2006 14:39:31 +0100 (CET) Message-ID: <4565A54D.3070403@alvestrand.no> Date: Thu, 23 Nov 2006 05:42:37 -0800 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Jeff Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again References: <200611230622.kAN6MlpT025685@siilo.fmi.fi> <45656946.70706@twnic.net.tw> In-Reply-To: <45656946.70706@twnic.net.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Kari Hurtta , ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Jeff wrote: > > >>> I read the sendmail source about sendmail/header.c for this issue >>> the chompheader() function will modify the Header value about the mail >>> address >>> >>> An EAI mail send headers are (such as To) : >>> >>> To: "???(e)" >, >>> "??(e)" > >>> >>> They become : >>> >>> To: "\"???(e)\" , >>> "\"??(e)\" >>> >>> If EAI use '[' ']' then without this issue , even if ">> [ald-address]>" transmited. >>> I think "> would have some side effects on MTAs or IRI. >>> >>> Abel >> >> Yes, that means that sendmail needs modify sendmail/header.c before >> it can announce UTF8SMTP >> >> Of course that it is expected that any parser do not handle that >> extended syntax (where there is fallback address), if it do not >> support UTF8SMTP >> >> Problem is that extended syntax must dot leak outside of UTF8SMTP >> environment. >> On SMTP this is easy. >> >> On case where mails are readed from local spool (/var/mail/{user} for >> example) >> by MUA, is difficult. >> > > > I think Abel is trying to say that the cost on updating parser to fit > > syntax is more complicate then . Since > '<' and '>' are VERY special token in email address representation. I > believe not only Sendmail had this problem, the other mail server also > does. If I'm mail software vendor who trying to provide EAI feature, > it is better for me update as few code as possible. > Not un-solvable but deployment concern I think. Personal opinion: It is a Good Thing that things break as soon as possible if these formats leak. The worst possible situation is where things leak, and stuff goes on working in an "almost reasonable" way that is just broken enough to cause problems. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 09:24:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnFV0-0006Ws-VU; Thu, 23 Nov 2006 09:24:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnFUz-0006Wi-I5 for ima@ietf.org; Thu, 23 Nov 2006 09:24:21 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnFUu-0004Zd-7r for ima@ietf.org; Thu, 23 Nov 2006 09:24:21 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GnFUq-0001q5-DT for ima@ietf.org; Thu, 23 Nov 2006 15:24:12 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 15:24:12 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 15:24:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: 23 Nov 2006 16:23:59 +0200 Lines: 52 Message-ID: <5dpsbetf5s.fsf@Hurtta06k.keh.iki.fi> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi> <040501c70eb4$ae5ed0a0$c7d348d3@aabbeell> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "abel" writes in gmane.ietf.ima: > I read the sendmail source about sendmail/header.c for this issue > the chompheader() function will modify the Header value about the mail > address > > An EAI mail send headers are (such as To) : > > To: "許乃文(e)" <許乃文@郵件.twnic.tw>, > "测试(e)" <测试@test1.qmail.asrc.cn> > > They become : > > To: "\"許乃文(e)\" <許乃文@郵件.twnic.tw", > "\"测试(e)\" <测试@test1.qmail.asrc.cn" > > If EAI use '[' ']' then without this issue , even if " [ald-address]>" transmited. > I think "> would have some side effects on MTAs or IRI. > > Abel Independent on what separators are used for alt-address crackaddr() on sendmail/headers.c breaks also. It works as following: 1) Header address value phrase
is rewritten to phrase <$g> 2) phrase
passed to rulsets 3) result is assigned to $g and phrase <$g> is evaluted That is routine which does address rewriting. For handling alt-address pass 1) need to be probally to be phrase
> is rewritten to phrase < ${g_int} <$g>> and so on. Issue is same if [ ] is used for separator of alt-address on here. Breakage of [] may be more hidden but it is on here. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 09:33:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnFeI-00089B-UD; Thu, 23 Nov 2006 09:33:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnFeI-000894-6H for ima@ietf.org; Thu, 23 Nov 2006 09:33:58 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnFeF-0005iB-IX for ima@ietf.org; Thu, 23 Nov 2006 09:33:56 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GnFeA-00044F-98 for ima@ietf.org; Thu, 23 Nov 2006 15:33:50 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 15:33:50 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 15:33:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: 23 Nov 2006 16:33:44 +0200 Lines: 44 Message-ID: <5dlkm2tepj.fsf@Hurtta06k.keh.iki.fi> References: <200611230622.kAN6MlpT025685@siilo.fmi.fi> <45656946.70706@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Jeff writes in gmane.ietf.ima: > >> I read the sendmail source about sendmail/header.c for this issue > >> the chompheader() function will modify the Header value about the mail > >> address > >> > >> An EAI mail send headers are (such as To) : > >> > >> To: "???(e)" >, > >> "??(e)" > > >> > >> They become : > >> > >> To: "\"???(e)\" , > >> "\"??(e)\" > >> > >> If EAI use '[' ']' then without this issue , even if " >> [ald-address]>" transmited. > >> I think "> would have some side effects on MTAs or IRI. > >> > >> Abel > > Yes, that means that sendmail needs modify sendmail/header.c before > > it can announce UTF8SMTP > > Of course that it is expected that any parser do not handle that > > extended syntax (where there is fallback address), if it do not support UTF8SMTP > > Problem is that extended syntax must dot leak outside of UTF8SMTP > > environment. > > On SMTP this is easy. > > On case where mails are readed from local spool (/var/mail/{user} > > for example) > > by MUA, is difficult. > > > > > I think Abel is trying to say that the cost on updating parser to fit > > syntax is more complicate then . Since There is cost on [ ] also because syntax inside of [ ] is unstructured on RFC 2822. In other words [ ] works like " " (sendmail do not parse [ ] as quoted, but some others may do. At least my MUA seems treate [ ] as one syntactic unit. Compare syntax of 'domain-literal' and 'quoted-string' on RFC 2822. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 10:10:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGCz-0002os-CM; Thu, 23 Nov 2006 10:09:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGCx-0002om-If for ima@ietf.org; Thu, 23 Nov 2006 10:09:47 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnGCw-00038C-79 for ima@ietf.org; Thu, 23 Nov 2006 10:09:47 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GnGCp-000ClO-DY; Thu, 23 Nov 2006 10:09:39 -0500 Date: Thu, 23 Nov 2006 10:09:38 -0500 From: John C Klensin To: Yangwoo Ko , Kari Hurtta Subject: Re: UTF8SMTP escape on local mail (Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again) Message-ID: In-Reply-To: <456560E4.2050903@icu.ac.kr> References: <200611230648.kAN6mDpB027657@siilo.fmi.fi> <456560E4.2050903@icu.ac.kr> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 23 November, 2006 17:50 +0900 Yangwoo Ko wrote: > > Kari Hurtta wrote: >>>>> Kari Hurtta >>>>>> abel >>> Yes, that means that sendmail needs modify sendmail/header.c >>> before it can announce UTF8SMTP >... >>> On case where mails are readed from local spool >>> (/var/mail/{user} for example) by MUA, is difficult. >> >> Perhaps most logical solution is use >> /var/mail/{user}.utf8 for UTF8SMTP >> messages and /var/mail/{user} for >> traditional messages >> >> >> however that is not on scope of IETF specifications ? > > I cannot but agree with you that we need a way to > differentiate them > because stored message is not protected by ESMTP. > > Differentiation is made possible based on information found > either > in mail message itself (e.g. header) or out side of it (e.g. > as shown > in your example). If we choose to go with the former, it will > be > within the scope of IETF. Otherwise, it is as you said. I think not. In order to manage mail, delivery systems and message store interfaces regularly add headers and other supplemental information that are not specified in the standards. Things like local-store expiration dates, indications about whether particular messages have been downloaded via POP3 and when, etc., are particularly common. The standards cover message formats on the wire; once something is delivered and goes into the message store, the message store management systems are free to invent supplemental information and identify it in any way desired (by storage location, otherwise out of band, or in-band) that suits their purposes. And none of that is traditionally within IETF scope. regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 10:23:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGQJ-0006dD-BH; Thu, 23 Nov 2006 10:23:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGQI-0006d8-G8 for ima@ietf.org; Thu, 23 Nov 2006 10:23:34 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnGQH-0005ld-1V for ima@ietf.org; Thu, 23 Nov 2006 10:23:34 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GnGQ6-00070y-Qe for ima@ietf.org; Thu, 23 Nov 2006 16:23:23 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 16:23:22 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 16:23:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: UTF8SMTP escape on local mail (Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again) Date: 23 Nov 2006 17:22:51 +0200 Lines: 72 Message-ID: <5dhcwqtcfo.fsf@Hurtta06k.keh.iki.fi> References: <200611230648.kAN6mDpB027657@siilo.fmi.fi> <456560E4.2050903@icu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yangwoo Ko writes in gmane.ietf.ima: > Kari Hurtta wrote: > >>>> Kari Hurtta > >>>>> abel > >> Yes, that means that sendmail needs modify sendmail/header.c before > >> it can announce UTF8SMTP > >> > >> Of course that it is expected that any parser do not handle that > >> extended syntax (where there is fallback address), if it do not support UTF8SMTP > >> > >> Problem is that extended syntax must dot leak outside of UTF8SMTP environment. > >> On SMTP this is easy. > >> > >> On case where mails are readed from local spool (/var/mail/{user} for example) > >> by MUA, is difficult. > > Perhaps most logical solution is use > > /var/mail/{user}.utf8 for UTF8SMTP messages > > and /var/mail/{user} for traditional messages > > however that is not on scope of IETF specifications ? > > I cannot but agree with you that we need a way to differentiate them > because stored message is not protected by ESMTP. > > Differentiation is made possible based on information found either > in mail message itself (e.g. header) or out side of it (e.g. as shown > in your example). If we choose to go with the former, it will be > within the scope of IETF. Otherwise, it is as you said. Differiantion is not ennough IMHO. Header field on mail message itself is not recognized by MUAs which are unaware of UTF8SMTP / Kari Hurtta PS. There is RFC1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information RFC1508 Generic Security Service Application Program Interface RFC1509 Generic Security Service API : C-bindings RFC1823 The LDAP Application Program Interface RFC1961 GSS-API Authentication Method for SOCKS Version 5 ... RFC2133 Basic Socket Interface Extensions for IPv6 RFC2292 Advanced Sockets API for IPv6 RFC2553 Basic Socket Interface Extensions for IPv6 RFC3493 Basic Socket Interface Extensions for IPv6 RFC3542 Advanced Sockets Application Program Interface (API) for IPv6 RFC4584 Extension to Sockets API for Mobile IPv6 which either do not look like scope of IETF. So it is not so clear what is on scope... :-) > > _______________________________________________ > > IMA mailing list > > IMA@ietf.org > > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 10:31:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGXf-0004iv-Mw; Thu, 23 Nov 2006 10:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGXe-0004in-Ms for ima@ietf.org; Thu, 23 Nov 2006 10:31:10 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnGXd-00076w-3M for ima@ietf.org; Thu, 23 Nov 2006 10:31:10 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3*clerew*man*ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 4565bebb.170d3.123 for ima@ietf.org; Thu, 23 Nov 2006 15:31:07 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kANFV5sD016769 for ; Thu, 23 Nov 2006 15:31:06 GMT To: IMA Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi> <040501c70eb4$ae5ed0a0$c7d348d3@aabbeell> Message-ID: Date: Thu, 23 Nov 2006 15:31:04 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <040501c70eb4$ae5ed0a0$c7d348d3@aabbeell> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 23 Nov 2006 04:05:56 -0000, abel wrote: > I read the sendmail source about sendmail/header.c for this issue > the chompheader() function will modify the Header value about the mail > address But sendmail is known to be the most difficult existing MTA to convert to UTF8SMTP, because it is not yet 8bit-clean for its headers. > > An EAI mail send headers are (such as To) : > > To: "許乃文(e)" <許乃文@郵件.twnic.tw>, > "测试(e)" <测试@test1.qmail.asrc.cn> > > They become : > > To: "\"許乃文(e)\" <許乃文@郵件.twnic.tw", > "\"测试(e)\" <测试@test1.qmail.asrc.cn" But, oddly enough, that has produced a To header that would cause the email to be sent to the right place. And also returned to the right place if it works for Reply-To. A fortunate accident maybe, but don't dismiss it entirely. Of course, a non-UTF8SMTP MTA should never have been allowed to see that header in the first place, but accidents happen :-( . -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 10:41:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGhc-000886-I0; Thu, 23 Nov 2006 10:41:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGhb-00087x-6J for ima@ietf.org; Thu, 23 Nov 2006 10:41:27 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnGhZ-0000ik-O5 for ima@ietf.org; Thu, 23 Nov 2006 10:41:27 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GnGhV-000286-Tk for ima@ietf.org; Thu, 23 Nov 2006 16:41:21 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 16:41:21 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 16:41:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: [OT] Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: 23 Nov 2006 17:41:04 +0200 Lines: 60 Message-ID: <5dd57etblb.fsf_-_@Hurtta06k.keh.iki.fi> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi> <040501c70eb4$ae5ed0a0$c7d348d3@aabbeell> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Thu, 23 Nov 2006 04:05:56 -0000, abel wrote: > > > I read the sendmail source about sendmail/header.c for this issue > > the chompheader() function will modify the Header value about the mail > > address > > But sendmail is known to be the most difficult existing MTA to convert > to UTF8SMTP, because it is not yet 8bit-clean for its headers. > > > > An EAI mail send headers are (such as To) : > > > > To: "許ä¹æ–‡(e)" <許ä¹æ–‡@éµä»¶.twnic.tw>, > > "测试(e)" <测试@test1.qmail.asrc.cn> > > > > They become : > > > > To: "\"許ä¹æ–‡(e)\" <許ä¹æ–‡@éµä»¶.twnic.tw", > > "\"测试(e)\" <测试@test1.qmail.asrc.cn" > > But, oddly enough, that has produced a To header that would cause the > email to be sent to the right place. And also returned to the right > place if it works for Reply-To. A fortunate accident maybe, but don't > dismiss it entirely. "\"許ä¹æ–‡(e)\" <許ä¹æ–‡@éµä»¶.twnic.tw" becomes "\"許ä¹æ–‡(e)\" <許ä¹æ–‡@éµä»¶.twnic.tw"<$g> on crackaddr() on sendmail/headers.c, I think And rulesets translate "\"許ä¹æ–‡(e)\" <許ä¹æ–‡@éµä»¶.twnic.tw" to abelyang@twnic.net.tw i think so it comes $g = abelyang@twnic.net.tw :-) > Of course, a non-UTF8SMTP MTA should never have been allowed to see > that header in the first place, but accidents happen :-( . > > -- > Charles H. Lindsey ---------At Home, doing my own thing------------------------ > Tel: +44 161 436 6131  >    Web: http://www.cs.man.ac.uk/~chl > Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. > PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 23 13:28:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnJIu-0006NC-IC; Thu, 23 Nov 2006 13:28:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnJIt-0006N7-Md for ima@ietf.org; Thu, 23 Nov 2006 13:28:07 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnJIs-0005Gz-Da for ima@ietf.org; Thu, 23 Nov 2006 13:28:07 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GnJIR-0004Mt-7x for ima@ietf.org; Thu, 23 Nov 2006 19:27:39 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 19:27:39 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Nov 2006 19:27:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: 23 Nov 2006 20:27:22 +0200 Lines: 20 Message-ID: <5dfyca10j9.fsf@Hurtta06k.keh.iki.fi> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi> <040501c70eb4$ae5ed0a0$c7d348d3@aabbeell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Thu, 23 Nov 2006 04:05:56 -0000, abel wrote: > > > I read the sendmail source about sendmail/header.c for this issue > > the chompheader() function will modify the Header value about the mail > > address > > But sendmail is known to be the most difficult existing MTA to convert > to UTF8SMTP, because it is not yet 8bit-clean for its headers. That parts is already done. On 8.14 there is: | Header field values are now 8 bit clean. Notes: | - header field names are still restricted to 7 bit. | - RFC 2822 allows only 7 bit (US-ASCII) characters in | headers. (quote is from release notes of sendmail 8.14.0.Beta1) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 24 06:36:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnZLg-00068m-H0; Fri, 24 Nov 2006 06:36:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnZLg-00068h-1l for ima@ietf.org; Fri, 24 Nov 2006 06:36:04 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnZLe-0005IQ-KW for ima@ietf.org; Fri, 24 Nov 2006 06:36:04 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3$clerew#man*ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 4566d91c.1096.1a7 for ima@ietf.org; Fri, 24 Nov 2006 11:35:56 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kAOBZsoD020955 for ; Fri, 24 Nov 2006 11:35:55 GMT To: IMA Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi> <040501c70eb4$ae5ed0a0$c7d348d3@aabbeell> <5dfyca10j9.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Fri, 24 Nov 2006 11:35:53 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dfyca10j9.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 23 Nov 2006 18:27:22 -0000, Kari Hurtta wrote: > "Charles Lindsey" writes in gmane.ietf.ima: >> But sendmail is known to be the most difficult existing MTA to convert >> to UTF8SMTP, because it is not yet 8bit-clean for its headers. > > That parts is already done. On 8.14 there is: > | Header field values are now 8 bit clean. Notes: > | - header field names are still restricted to 7 bit. > | - RFC 2822 allows only 7 bit (US-ASCII) characters in > | headers. > > (quote is from release notes of sendmail 8.14.0.Beta1) OK, that is good news, but it is still only a beta. But it does mean that sendmail.cf could, in principle, be hacked to accept alt-addresses whether with <...> or [...] (the hack wouldn't be a pretty sight, but sendmail hacks never are :-( ). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 26 23:08:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoXmQ-00064b-DZ; Sun, 26 Nov 2006 23:07:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoXmO-00062U-SJ for ima@ietf.org; Sun, 26 Nov 2006 23:07:40 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoXmN-00021A-75 for ima@ietf.org; Sun, 26 Nov 2006 23:07:40 -0500 Received: from aabbeell (abel_pc.twnic.net.tw [211.72.211.199] (may be forged)) by twnic.net.tw (8.13.8/8.13.8) with SMTP id kAR46T8A015286; Mon, 27 Nov 2006 12:06:29 +0800 Message-ID: <002201c711d9$93054500$c7d348d3@aabbeell> From: "abel" To: "Charles Lindsey" References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi><5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi><040501c70eb4$ae5ed0a0$c7d348d3@aabbeell><5dfyca10j9.fsf@Hurtta06k.keh.iki.fi> Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: Mon, 27 Nov 2006 12:07:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > > That parts is already done. On 8.14 there is: > > | Header field values are now 8 bit clean. Notes: > > | - header field names are still restricted to 7 bit. > > | - RFC 2822 allows only 7 bit (US-ASCII) characters in > > | headers. > > > > (quote is from release notes of sendmail 8.14.0.Beta1) > > OK, that is good news, but it is still only a beta. But it does mean that > sendmail.cf could, in principle, be hacked to accept alt-addresses whether > with <...> or [...] (the hack wouldn't be a pretty sight, but sendmail > hacks never are :-( ). This is a good news, but on the other we do not know how the MTA is ! Because too often use in "<>", I think we have the > or the "" For the MTA will run a number of conflicts, But I personally feel that the "[]" the problem should be smaller than "<>" for eai ALT-ADDRESS identifiy, But the problem may be more obvious IRI, mailto:joe@example.com?cc=bob@example.com&body=hello to be: mailto:joe@example.com?cc=bob@example.com<...>&body=hello or: mailto:joe@example.com[ALT-ADDRESS]?cc=bob@example.com[....]&body=hello I think this is part "<>" of the impact is greater than the "[]".This is what we need to consider and attention. Abel _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 27 00:13:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoYoA-00086b-1T; Mon, 27 Nov 2006 00:13:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoYo7-00085Y-UQ for ima@ietf.org; Mon, 27 Nov 2006 00:13:31 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoYo3-0004bx-H7 for ima@ietf.org; Mon, 27 Nov 2006 00:13:31 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GoYo2-0002qc-Cn for ima@ietf.org; Mon, 27 Nov 2006 06:13:26 +0100 Received: from pd9fba917.dip0.t-ipconnect.de ([217.251.169.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Nov 2006 06:13:26 +0100 Received: from nobody by pd9fba917.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Nov 2006 06:13:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: Mon, 27 Nov 2006 06:12:32 +0100 Organization: Lines: 19 Message-ID: <456A73C0.44E3@xyzzy.claranet.de> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi><5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi><040501c70eb4$ae5ed0a0$c7d348d3@aabbeell><5dfyca10j9.fsf@Hurtta06k.keh.iki.fi> <002201c711d9$93054500$c7d348d3@aabbeell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba917.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org abel wrote: [mailto-IRI] > mailto:joe@example.com?cc=bob@example.com<...>&body=hello > or: > mailto:joe@example.com[ALT-ADDRESS]?cc=bob@example.com[....]&body=hello > I think this is part "<>" of the impact is greater than the "[]". With URLs it's clear, both <> and [] have to be percent-encoded. For IRIs 3987 doesn't say anything special about [], I'd guess that [] still have to be percent-encoded. For <> 3987 has an obscure MAY, also for some other characters like space. This MAY in RFC 3987 is a mystery for me, so far I hope that Martin silently removes it when 3987 goes to DS, removing options is allowed. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 27 02:08:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goab4-0004PU-63; Mon, 27 Nov 2006 02:08:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goab2-0004PD-Ns for ima@ietf.org; Mon, 27 Nov 2006 02:08:08 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goaax-0000Tp-Ky for ima@ietf.org; Mon, 27 Nov 2006 02:08:08 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kAR77xop021969 for ; Mon, 27 Nov 2006 16:08:00 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5f69_03d17790_7de6_11db_891f_0014221f2a2d; Mon, 27 Nov 2006 16:07:59 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54113) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 27 Nov 2006 16:07:23 +0900 Message-Id: <6.0.0.20.2.20061127154230.0a6be080@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 27 Nov 2006 16:03:10 +0900 To: Frank Ellermann , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again In-Reply-To: <456A73C0.44E3@xyzzy.claranet.de> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi> <040501c70eb4$ae5ed0a0$c7d348d3@aabbeell> <5dfyca10j9.fsf@Hurtta06k.keh.iki.fi> <002201c711d9$93054500$c7d348d3@aabbeell> <456A73C0.44E3@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 14:12 06/11/27, Frank Ellermann wrote: >abel wrote: > > [mailto-IRI] >> mailto:joe@example.com?cc=bob@example.com<...>&body=hello >> or: >> mailto:joe@example.com[ALT-ADDRESS]?cc=bob@example.com[....]&body=hello > >> I think this is part "<>" of the impact is greater than the "[]". > >With URLs it's clear, both <> and [] have to be percent-encoded. > >For IRIs 3987 doesn't say anything special about [], I'd guess that >[] still have to be percent-encoded. Yes. >For <> 3987 has an obscure MAY, >also for some other characters like space. This MAY in RFC 3987 is >a mystery for me, so far I hope that Martin silently removes it when >3987 goes to DS, removing options is allowed. The historical background is that at one time, a draft of the IRI spec allowed printable ASCII not allowed in URIs. The reason for this was mainly XPointer, which is awkward to write without that provision. Later discussions moved IRI towards having exactly the same syntax for ASCII as URIs. Quite some specs in the XML area use something that's essentially the same as an IRI, but need this MAY. I can immagine wording it more narrowly, but at the moment, I don't expect it to disappear. But it shouldn't be used for new protocol elements. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 27 11:53:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojjV-0001Gx-6Y; Mon, 27 Nov 2006 11:53:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojjU-0001Gs-B2 for ima@ietf.org; Mon, 27 Nov 2006 11:53:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GojjM-0007ze-Uv for ima@ietf.org; Mon, 27 Nov 2006 11:53:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gojid-00051s-Lp for ima@ietf.org; Mon, 27 Nov 2006 17:52:36 +0100 Received: from d255034.dialin.hansenet.de ([80.171.255.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Nov 2006 17:52:35 +0100 Received: from nobody by d255034.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Nov 2006 17:52:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Date: Mon, 27 Nov 2006 17:51:43 +0100 Organization: Lines: 20 Message-ID: <456B179F.7BFD@xyzzy.claranet.de> References: <5d7iyft5tp.fsf@Hurtta06k.keh.iki.fi> <5dbqnoa8lk.fsf@Hurtta06k.keh.iki.fi> <040501c70eb4$ae5ed0a0$c7d348d3@aabbeell> <5dfyca10j9.fsf@Hurtta06k.keh.iki.fi> <002201c711d9$93054500$c7d348d3@aabbeell> <456A73C0.44E3@xyzzy.claranet.de> <6.0.0.20.2.20061127154230.0a6be080@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255034.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst wrote: [3987 3.1 "IRIs MAY also deal with the printable characters in US-ASCII that are not allowed in URIs"] > The historical background is that at one time, a draft of the IRI spec > allowed printable ASCII not allowed in URIs. The reason for this was > mainly XPointer, which is awkward to write without that provision. > Later discussions moved IRI towards having exactly the same syntax > for ASCII as URIs. Quite some specs in the XML area use something > that's essentially the same as an IRI, but need this MAY. I can > immagine wording it more narrowly, but at the moment, I don't expect > it to disappear. But it shouldn't be used for new protocol elements. Thanks for info. I hope that "shouldn't be used for new protocols" also includes the future mailto-2368ter, unless you desperately need it for an alt-address construct. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 28 21:45:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpFRZ-0007kS-G7; Tue, 28 Nov 2006 21:45:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpFRX-0007Y0-Hm for ima@ietf.org; Tue, 28 Nov 2006 21:45:03 -0500 Received: from eai2.twnic.tw ([211.72.210.251] helo=log.twnic.net.tw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpFRV-0004h6-RG for ima@ietf.org; Tue, 28 Nov 2006 21:45:03 -0500 Received: (from smmsp@localhost) by log.twnic.net.tw (8.13.6/8.13.6) id kAT2j0F2030942 Wed, 29 Nov 2006 10:45:00 +0800 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by eai2.twnic.tw (envelope-sender ) MIMEDefang with ESMTP id kAT2iRtY030928 Wed, 29 Nov 2006 10:45:00 +0800 (CST) Message-ID: <04d201c71360$712c1110$c7d348d3@aabbeell> From: "abel" To: Date: Wed, 29 Nov 2006 10:45:33 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [EAI] Local-Part auto converting ? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1797833714==" Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --===============1797833714== Content-Type: multipart/alternative; boundary="----=_NextPart_000_04CF_01C713A3.7F431C10" This is a multi-part message in MIME format. ------=_NextPart_000_04CF_01C713A3.7F431C10 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Doese EAI discuss "local-part" converting algorithm? In Downgrade draft said: Trace headers: Received: headers MUST NOT be target of downgrading because they do not contain Non-ASCII mail addresses. =20 In utf8header draft said: Internationalized domain names in Received fields must be transmitted in punycode form. "For" fields containing internationalized addresses are prohibited =20 In smtpext draft said: Internationalized domain names in Received fields MUST be transmitted in the punycode form. =20 >From the above we know that, Trace Field should be puny code , But in=20 general, trace field general will be part of the envelope information. If the original mail is eai-aware and pickup UTF8=20 information, whether it is really necessary to puny code ? Why not UTF8 in EAI to EAI mail ? We can see that "Trace Field" should be sent in ASCII from above. But in general, trace fields are the SMTP routing path information. Is it really necessary to convert them to ASCII when both SMTP client/server side support EAI? Another question is that if we have to convert EAI address =3D> ASCII address without ALT-ADDRESS, we will need a converting algorithm to do that. I'm afraid this is not covered by current discussion. Abel ------=_NextPart_000_04CF_01C713A3.7F431C10 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Doese EAI discuss "local-part" converting=20 algorithm?
 
In Downgrade draft said:
Trace headers:  = Received:=20 headers MUST NOT be target of downgrading
because they do not contain = Non-ASCII mail addresses.
 
 
In utf8header draft said:
Internationalized = domain names in=20 Received fields must be transmitted
in punycode form.  "For" = fields=20 containing internationalized
addresses are prohibited
  =
 
In smtpext draft said:
Internationalized domain = names in=20 Received fields MUST be transmitted
in the punycode = form.
 
From=20 the above we know that, Trace Field should be puny code , But in =
general,=20 trace field general will be part of the envelope
information. If the = original=20 mail is eai-aware and pickup UTF8
information, whether it is really=20 necessary to puny code ?
Why not UTF8 in EAI to EAI mail ?
We can = see that=20 "Trace Field" should be sent in ASCII from above. But in
general, = trace=20 fields are the SMTP routing path information. Is it
really necessary = to=20 convert them to ASCII when both SMTP client/server
side support=20 EAI?
 
Another question is that if we have to convert EAI = address=20 =3D> ASCII
address without ALT-ADDRESS, we will need a converting = algorithm=20 to do
that. I'm afraid this is not covered by current=20 discussion.
 
 
Abel
 
 
 
------=_NextPart_000_04CF_01C713A3.7F431C10-- --===============1797833714== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============1797833714==-- From ima-bounces@ietf.org Tue Nov 28 22:58:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpGab-00007L-3l; Tue, 28 Nov 2006 22:58:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpGaa-0008SH-6J for ima@ietf.org; Tue, 28 Nov 2006 22:58:28 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpGaU-0000DZ-HT for ima@ietf.org; Tue, 28 Nov 2006 22:58:28 -0500 Received: (snipe 28676 invoked by uid 0); 29 Nov 2006 12:59:49 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.019427 secs); Received: from unknown (HELO ?192.168.10.145?) (Z???own@210.107.249.23) by unknown with SMTP; 29 Nov 2006 12:59:49 +0900 X-RCPTTO: yn--q5v@xn--5nqv22n.twnic.tw, ima@ietf.org, yangwooko@gmail.com Message-ID: <456D0558.6010604@icu.ac.kr> Date: Wed, 29 Nov 2006 12:58:16 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: abel Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell> In-Reply-To: <04d201c71360$712c1110$c7d348d3@aabbeell> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org abel wrote: > Doese EAI discuss "local-part" converting algorithm? > > In Downgrade draft said: > Trace headers: Received: headers MUST NOT be target of downgrading > because they do not contain Non-ASCII mail addresses. > > > In utf8header draft said: > Internationalized domain names in Received fields must be transmitted > in punycode form. "For" fields containing internationalized > addresses are prohibited > > > In smtpext draft said: > Internationalized domain names in Received fields MUST be transmitted > in the punycode form. > > >From the above we know that, Trace Field should be puny code , But in > general, trace field general will be part of the envelope > information. If the original mail is eai-aware and pickup UTF8 > information, whether it is really necessary to puny code ? > Why not UTF8 in EAI to EAI mail ? > We can see that "Trace Field" should be sent in ASCII from above. But in > general, trace fields are the SMTP routing path information. Is it > really necessary to convert them to ASCII when both SMTP client/server > side support EAI? > > Another question is that if we have to convert EAI address => ASCII > address without ALT-ADDRESS, we will need a converting algorithm to do > that. I'm afraid this is not covered by current discussion. > Idea of autonomic converting (without user involvement) was rejected at the EAI WG preparation phase. Use of ATOMIC was removed from documents at IETF 66 EAI WG meeting. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 28 23:30:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpH5N-0001xZ-DO; Tue, 28 Nov 2006 23:30:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpH5M-0001xL-PG for ima@ietf.org; Tue, 28 Nov 2006 23:30:16 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpH5L-0006BR-4h for ima@ietf.org; Tue, 28 Nov 2006 23:30:16 -0500 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by twnic.net.tw (8.13.8/8.13.8) with SMTP id kAT4U81R008093; Wed, 29 Nov 2006 12:30:08 +0800 Message-ID: <057501c7136f$35401c00$c7d348d3@aabbeell> From: "abel" To: "Yangwoo Ko" References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> Subject: Re: [EAI] Local-Part auto converting ? Date: Wed, 29 Nov 2006 12:31:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org So, if a non-EAI-aware MTA sent mail to EAI-aware server , the RCPT address is ASCII (no ALT-ADDRESS), then EAI server must use MAPPING TABLE to map this ASCII address to a UTF8 address ? Can't use autonomic convert ? > > Another question is that if we have to convert EAI address => ASCII > > address without ALT-ADDRESS, we will need a converting algorithm to do > > that. I'm afraid this is not covered by current discussion. > > > Idea of autonomic converting (without user involvement) was rejected > at the EAI WG preparation phase. > > Use of ATOMIC was removed from documents at IETF 66 EAI WG > meeting. > So, if a non-EAI-aware MTA sent mail to EAI-aware server , the RCPT address is ASCII , does EAI server must use MAPPING TABLE to map this ASCII address to a UTF8 address ? Can't use autonomic convert ? Abel _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 00:28:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpHzf-0008Em-Mt; Wed, 29 Nov 2006 00:28:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpHzd-00089f-Sv for ima@ietf.org; Wed, 29 Nov 2006 00:28:26 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpHzc-0006Jj-96 for ima@ietf.org; Wed, 29 Nov 2006 00:28:25 -0500 Received: (snipe 20053 invoked by uid 0); 29 Nov 2006 14:29:51 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.023675 secs); Received: from unknown (HELO ?192.168.10.145?) (Z???own@210.107.249.23) by unknown with SMTP; 29 Nov 2006 14:29:51 +0900 X-RCPTTO: abelyang@twnic.net.tw, ima@ietf.org, yangwooko@gmail.com Message-ID: <456D1A72.9000700@icu.ac.kr> Date: Wed, 29 Nov 2006 14:28:18 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: abel Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> In-Reply-To: <057501c7136f$35401c00$c7d348d3@aabbeell> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org There is no in-transit upgrade defined in the current set of documents. I don't see a reasonable way to do this without breaking the model of envelope/message separation. If an MTA has an access to an (imaginary) directory that provides very persistent, reliable, and unique mapping between addresses, it can do the upgrade. Do you happen to mean this one? As far as I understand from discussions so far in this group, information loss during the downgrade is inevitable. That is one of reasons why we call it "down"-"grade" rather than translation or others. Regards abel wrote: > So, if a non-EAI-aware MTA sent mail to EAI-aware server , the RCPT address > is ASCII (no ALT-ADDRESS), > then EAI server must use MAPPING TABLE to map this ASCII address to a UTF8 > address ? > Can't use autonomic convert ? > >>> Another question is that if we have to convert EAI address => ASCII >>> address without ALT-ADDRESS, we will need a converting algorithm to do >>> that. I'm afraid this is not covered by current discussion. >>> >> Idea of autonomic converting (without user involvement) was rejected >> at the EAI WG preparation phase. >> >> Use of ATOMIC was removed from documents at IETF 66 EAI WG >> meeting. >> > > So, if a non-EAI-aware MTA sent mail to EAI-aware server , the RCPT address > is ASCII , > does EAI server must use MAPPING TABLE to map this ASCII address to a UTF8 > address ? > Can't use autonomic convert ? > > Abel > > > > > > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 01:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJLi-000721-PF; Wed, 29 Nov 2006 01:55:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJLc-0006zH-FN for ima@ietf.org; Wed, 29 Nov 2006 01:55:12 -0500 Received: from eai2.twnic.tw ([211.72.210.251] helo=log.twnic.net.tw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpJK7-0008FJ-Ex for ima@ietf.org; Wed, 29 Nov 2006 01:53:41 -0500 Received: (from smmsp@localhost) by log.twnic.net.tw (8.13.6/8.13.6) id kAT6rPU3001154; Wed, 29 Nov 2006 14:53:25 +0800 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by eai2.twnic.tw (envelope-sender ) MIMEDefang with ESMTP id kAT6qp8O001010; Wed, 29 Nov 2006 14:53:25 +0800 (CST) Message-ID: <05c501c71383$253ee1b0$c7d348d3@aabbeell> From: "abel" To: "Yangwoo Ko" References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> Subject: Re: [EAI] Local-Part auto converting ? Date: Wed, 29 Nov 2006 14:53:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807>> There is no in-transit upgrade defined in the current set of> documents. I don't see a reasonable way to do this without> breaking the model of envelope/message separation.>> If an MTA has an access to an (imaginary) directory that> provides very persistent, reliable, and unique mapping> between addresses, it can do the upgrade. Do you happen> to mean this one? X-Spam-Score: 3.8 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > > There is no in-transit upgrade defined in the current set of > documents. I don't see a reasonable way to do this without > breaking the model of envelope/message separation. > > If an MTA has an access to an (imaginary) directory that > provides very persistent, reliable, and unique mapping > between addresses, it can do the upgrade. Do you happen > to mean this one? Yes, that's my one of points But another issue is when i got a UTF8 address without ALD-ADDRESS, How do i sent message via non-EAI server to this UTF8 address ? Without ALD-ADDRESS,I think the UTF8 address converts algorithm is in need, I don't wanna my server have two sets of accounts or a big account mapping tables. Another doubt that why trace field have to puny code , why not UTF8 in an pure EAI mail ? Trace Fileds include "Return-Path" and 'for' clause of Received, in usual, Return-Path is envelope from,'for' is envelope to , if those address (from/to) convert to puny code, Return-Path will double bounce potentially, 'for' of puny code is hard to trace message. Abel _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 02:08:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJYg-0006X9-OB; Wed, 29 Nov 2006 02:08:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJYf-0006Wu-3S for ima@ietf.org; Wed, 29 Nov 2006 02:08:41 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpJYc-0002zP-Gv for ima@ietf.org; Wed, 29 Nov 2006 02:08:41 -0500 Received: (snipe 14044 invoked by uid 0); 29 Nov 2006 16:10:02 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.024224 secs); Received: from unknown (HELO ?192.168.10.145?) (Z???own@210.107.249.23) by unknown with SMTP; 29 Nov 2006 16:10:02 +0900 X-RCPTTO: yn--q5v@xn--5nqv22n.twnic.tw, ima@ietf.org, yangwooko@gmail.com Message-ID: <456D31EC.6010607@icu.ac.kr> Date: Wed, 29 Nov 2006 16:08:28 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: abel Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> In-Reply-To: <05c501c71383$253ee1b0$c7d348d3@aabbeell> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org abel wrote: > >> There is no in-transit upgrade defined in the current set of >> documents. I don't see a reasonable way to do this without >> breaking the model of envelope/message separation. >> >> If an MTA has an access to an (imaginary) directory that >> provides very persistent, reliable, and unique mapping >> between addresses, it can do the upgrade. Do you happen >> to mean this one? > Yes, that's my one of points > > But another issue is when i got a UTF8 address without ALD-ADDRESS, > How do i sent message via non-EAI server to this UTF8 address ? In that case, the mail should be rejected or NDN is generated and returned. > Without ALD-ADDRESS,I think the UTF8 address converts algorithm is in need, > I don't wanna my server have two sets of accounts or a big account mapping > tables. > > Another doubt that why trace field have to puny code , why not UTF8 in an > pure EAI mail ? > Trace Fileds include "Return-Path" and 'for' clause of Received, in usual, > Return-Path is envelope > from,'for' is envelope to , if those address (from/to) convert to puny code, > Return-Path will double > bounce potentially, 'for' of puny code is hard to trace message. If "Trace-Fields" include non ASCII, they should be target of downgrade. In other words, an MTA should be allowed to modify (or changing UTF-8 address to all ASCII address) existing Trace-Fields added by previous hop MTAs. This is NOT allowed as far as I know. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 02:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJpj-00022j-CQ; Wed, 29 Nov 2006 02:26:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJph-0001yB-Q9 for ima@ietf.org; Wed, 29 Nov 2006 02:26:17 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpJpe-0005Wh-BD for ima@ietf.org; Wed, 29 Nov 2006 02:26:17 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GpJpL-0007FU-BM for ima@ietf.org; Wed, 29 Nov 2006 08:25:55 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 08:25:55 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 08:25:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Local-Part auto converting ? Date: 29 Nov 2006 09:28:35 +0200 Lines: 42 Message-ID: <5dejrmvhi4.fsf@leija.fmi.fi> References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "abel" writes in gmane.ietf.ima: > > > > There is no in-transit upgrade defined in the current set of > > documents. I don't see a reasonable way to do this without > > breaking the model of envelope/message separation. > > > > If an MTA has an access to an (imaginary) directory that > > provides very persistent, reliable, and unique mapping > > between addresses, it can do the upgrade. Do you happen > > to mean this one? > Yes, that's my one of points > > But another issue is when i got a UTF8 address without ALD-ADDRESS, > How do i sent message via non-EAI server to this UTF8 address ? > Without ALD-ADDRESS,I think the UTF8 address converts algorithm is in need, > I don't wanna my server have two sets of accounts or a big account mapping > tables. > > Another doubt that why trace field have to puny code , why not UTF8 in an > pure EAI mail ? > Trace Fileds include "Return-Path" and 'for' clause of Received, in usual, > Return-Path is envelope > from,'for' is envelope to , if those address (from/to) convert to puny code, > Return-Path will double > bounce potentially, 'for' of puny code is hard to trace message. > > Abel As far I understanstand 'for' do not allow non-ascii address. If mail is sent to UTF8 envelope recipient, 'for' is not generated. In general 'for' is not generateted also, if mail have several envelope recipients. And on syntax of Received: -header field there is no place for envelope sender. Return-Path header field is generated when mail is disposed to mailbox. It is not on mail which is on transit. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 02:45:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpK8Q-0000f3-Qa; Wed, 29 Nov 2006 02:45:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpK8P-0000ey-VK for ima@ietf.org; Wed, 29 Nov 2006 02:45:37 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpK8L-0007m0-6k for ima@ietf.org; Wed, 29 Nov 2006 02:45:37 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GpK84-0003KB-4h for ima@ietf.org; Wed, 29 Nov 2006 08:45:16 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 08:45:16 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 08:45:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Local-Part auto converting ? Date: 29 Nov 2006 09:47:46 +0200 Lines: 39 Message-ID: <5d8xhuu21p.fsf@leija.fmi.fi> References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "abel" writes in gmane.ietf.ima: > > > > There is no in-transit upgrade defined in the current set of > > documents. I don't see a reasonable way to do this without > > breaking the model of envelope/message separation. > > > > If an MTA has an access to an (imaginary) directory that > > provides very persistent, reliable, and unique mapping > > between addresses, it can do the upgrade. Do you happen > > to mean this one? > Yes, that's my one of points > > But another issue is when i got a UTF8 address without ALD-ADDRESS, > How do i sent message via non-EAI server to this UTF8 address ? > Without ALD-ADDRESS,I think the UTF8 address converts algorithm is in need, > I don't wanna my server have two sets of accounts or a big account mapping > tables. My understanding is following: If envelope recipient address is UTF8 address, it is assumed that mail do not hit to non-EAI server (or some kind private tunneling mechanism is arranged). If envelope sender address is UTF8 address, mail is either bounced or server provieds some fancy gatewing service (I wrote about these some time ago). If address on header field is UTF8, header field is encapsulated. After that mail may miss some address header fields. ( If only domain part of address is UTF8, it can be converted to punycode form. But subject talk about Local-Part, so I assume that UTF8 address on question means address with UTF8 local part.) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 03:13:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKZO-0002YS-RX; Wed, 29 Nov 2006 03:13:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKZN-0002XD-UY for ima@ietf.org; Wed, 29 Nov 2006 03:13:29 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpKZL-0003oB-8f for ima@ietf.org; Wed, 29 Nov 2006 03:13:29 -0500 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by twnic.net.tw (8.13.8/8.13.8) with SMTP id kAT8DOCt015778; Wed, 29 Nov 2006 16:13:25 +0800 Message-ID: <062701c7138e$663aecd0$c7d348d3@aabbeell> From: "abel" To: , "Kari Hurtta" References: <04d201c71360$712c1110$c7d348d3@aabbeell><456D0558.6010604@icu.ac.kr><057501c7136f$35401c00$c7d348d3@aabbeell><456D1A72.9000700@icu.ac.kr><05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> Subject: Re: [EAI] Local-Part auto converting ? Date: Wed, 29 Nov 2006 16:14:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > As far I understanstand 'for' do not allow non-ascii address. Agree. if one recipient and local-part is UTF8, 'for' need to auto convert local-part, to follow this converting algorithm , it should be used in MAIL/RCPT without ALT-ADDRESS. I think we need a default if MUA has no ALT-ADDRESS. > If mail is sent to UTF8 envelope recipient, 'for' is not generated. > In general 'for' is not generateted also, if mail have several envelope recipients. > > And on syntax of Received: -header field there is no place for envelope sender. > > > Return-Path header field is generated when mail is disposed to mailbox. > It is not on mail which is on transit. if it's a catch-all server, how to bounce mail with a ASCII 'Return-Path' to UTF8 address ? > > > / Kari Hurtta > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 03:33:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKsu-0005qH-Hz; Wed, 29 Nov 2006 03:33:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKst-0005qA-3j for ima@ietf.org; Wed, 29 Nov 2006 03:33:39 -0500 Received: from eai2.twnic.tw ([211.72.210.251] helo=log.twnic.net.tw) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpKsq-0008Mp-C3 for ima@ietf.org; Wed, 29 Nov 2006 03:33:39 -0500 Received: (from smmsp@localhost) by log.twnic.net.tw (8.13.6/8.13.6) id kAT8XYjd007255; Wed, 29 Nov 2006 16:33:34 +0800 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by eai2.twnic.tw (envelope-sender ) MIMEDefang with ESMTP id kAT8WxLp007115; Wed, 29 Nov 2006 16:33:34 +0800 (CST) Message-ID: <064801c71391$21b9aa30$c7d348d3@aabbeell> From: "abel" To: , "Kari Hurtta" References: <04d201c71360$712c1110$c7d348d3@aabbeell><456D0558.6010604@icu.ac.kr><057501c7136f$35401c00$c7d348d3@aabbeell><456D1A72.9000700@icu.ac.kr><05c501c71383$253ee1b0$c7d348d3@aabbeell> <5d8xhuu21p.fsf@leija.fmi.fi> Subject: Re: [EAI] Local-Part auto converting ? Date: Wed, 29 Nov 2006 16:34:05 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807----- Original Message ----- Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by log.twnic.net.tw id kAT8XYjd007255 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org ----- Original Message -----=20 From: "Kari Hurtta" To: Sent: Wednesday, November 29, 2006 3:47 PM Subject: Re: [EAI] Local-Part auto converting ? > "abel" writes in gmane.ietf.ima: > > > > > > > There is no in-transit upgrade defined in the current set of > > > documents. I don't see a reasonable way to do this without > > > breaking the model of envelope/message separation. > > > > > > If an MTA has an access to an (imaginary) directory that > > > provides very persistent, reliable, and unique mapping > > > between addresses, it can do the upgrade. Do you happen > > > to mean this one? > > Yes, that's my one of points > > > > But another issue is when i got a UTF8 address without ALD-ADDRESS, > > How do i sent message via non-EAI server to this UTF8 address ? > > Without ALD-ADDRESS,I think the UTF8 address converts algorithm is in need, > > I don't wanna my server have two sets of accounts or a big account mapping > > tables. > > My understanding is following: > > If envelope recipient address is UTF8 address, it is assumed that mail = do not > hit to non-EAI server (or some kind private tunneling mechanism is arranged). Hmm,I think it's possible to hit to non-EAI server. Such as yn--q5v@xn--5nqv22n.twnic.tw =3D =E6=A5=8A@=E9=83=B5=E4=BB=B6.twnic.tw , but i can't subscribe with the UTF8 address, So I using yn--PunyCode@Domain-Part , that will auto convert (upgrade ) to '=E6=A5=8A' (Yang) mailbox. Cause my= testbed is eai island. If we don't have auto convert method , in feature ,that will affect our promotion on EAI mail. > > If envelope sender address is UTF8 address, mail is either bounced or > server provieds some fancy gatewing service (I wrote about these some t= ime ago). May you describe ideas about "fancy gatewing service " ? Abel _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 03:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKxP-0002rn-Ug; Wed, 29 Nov 2006 03:38:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKxP-0002r7-0Y for ima@ietf.org; Wed, 29 Nov 2006 03:38:19 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpKxN-0000lB-Mf for ima@ietf.org; Wed, 29 Nov 2006 03:38:18 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 786112580CF; Wed, 29 Nov 2006 09:35:06 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31581-03; Wed, 29 Nov 2006 09:34:56 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BF17F2580EE; Wed, 29 Nov 2006 09:34:56 +0100 (CET) Message-ID: <456D46EE.6060108@alvestrand.no> Date: Wed, 29 Nov 2006 09:38:06 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: abel Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> In-Reply-To: <057501c7136f$35401c00$c7d348d3@aabbeell> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org abel wrote: > So, if a non-EAI-aware MTA sent mail to EAI-aware server , the RCPT address > is ASCII (no ALT-ADDRESS), > then EAI server must use MAPPING TABLE to map this ASCII address to a UTF8 > address ? > Can't use autonomic convert ? > > >>> Another question is that if we have to convert EAI address => ASCII >>> address without ALT-ADDRESS, we will need a converting algorithm to do >>> that. I'm afraid this is not covered by current discussion. >>> >>> >> Idea of autonomic converting (without user involvement) was rejected >> at the EAI WG preparation phase. >> >> Use of ATOMIC was removed from documents at IETF 66 EAI WG >> meeting. >> >> > > So, if a non-EAI-aware MTA sent mail to EAI-aware server , the RCPT address > is ASCII , > does EAI server must use MAPPING TABLE to map this ASCII address to a UTF8 > address ? > Can't use autonomic convert ? > That's a local decision; a server can use whatever mapping table it wants for its own users, including one produced by an algorithm such as Punycode. But it cannot assume that any other server does the same thing. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 03:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpL9r-0008F0-8x; Wed, 29 Nov 2006 03:51:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpL9q-0008Em-8l for ima@ietf.org; Wed, 29 Nov 2006 03:51:10 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpL9l-0003Vc-Ce for ima@ietf.org; Wed, 29 Nov 2006 03:51:10 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B7372580EE; Wed, 29 Nov 2006 09:47:54 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31581-10; Wed, 29 Nov 2006 09:47:49 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 305992580CF; Wed, 29 Nov 2006 09:47:49 +0100 (CET) Message-ID: <456D49F3.4030309@alvestrand.no> Date: Wed, 29 Nov 2006 09:50:59 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: abel Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell><456D0558.6010604@icu.ac.kr><057501c7136f$35401c00$c7d348d3@aabbeell><456D1A72.9000700@icu.ac.kr><05c501c71383$253ee1b0$c7d348d3@aabbeell> <5d8xhuu21p.fsf@leija.fmi.fi> <064801c71391$21b9aa30$c7d348d3@aabbeell> In-Reply-To: <064801c71391$21b9aa30$c7d348d3@aabbeell> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org abel wrote: > arranged). > Hmm,I think it's possible to hit to non-EAI server. Such as > yn--q5v@xn--5nqv22n.twnic.tw =3D =E6=A5=8A@=E9=83=B5=E4=BB=B6.twnic.tw = , > but i can't subscribe with the UTF8 address, So I using > yn--PunyCode@Domain-Part , > that will auto convert (upgrade ) to '=E6=A5=8A' (Yang) mailbox. Cause = my testbed > is eai island. > If we don't have auto convert method , in feature ,that will affect our= > promotion on EAI mail. I don't understand this scenario. Let's see if I can flesh it out in deta= il. If you want to subscribe to a mailing list that supports UTF8SMTP, you=20 can enter the subscription request: - Through a Web form. No problem - the web supports UTF-8. - Through a "subscribe" request where the address is in the body of the=20 message. No problem - mail bodies support UTF-8. - Through a "subscribe" request where the address in the "from:" field=20 of the message is subscribed. In the last case, you have two cases: - You send from inside your "EAI island". No problem. - You send from outside your "EAI island", so your message doesn't have=20 UTF-8 in the From: field. You then have three possibilities, I think: - Mail from the mailing list is delivered to your ASCII address. No=20 technical problem. - You prevail upon your sysadmin to enable UTF8SMTP locally, so that=20 you're part of the "EAI island". - The mailing list has access to some database that maps your ASCII=20 address to an UTF-8 address. One possible form of database is a table that says "twnic.tw uses=20 punycode for its localparts" - presumably because the twnic.tw=20 administrator has told the mailing list administrator that this is the ca= se. But if your mailing list service gets a message from=20 yn--q5v@stupid.domain.name (which you haven't seen before), there is no=20 information in the table allowing you to interpret the localpart. Is this the scenario you see as problematic? Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 07:18:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpOOE-0007xh-FH; Wed, 29 Nov 2006 07:18:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpOOD-0007v5-Q1 for ima@ietf.org; Wed, 29 Nov 2006 07:18:13 -0500 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpOO9-0003VJ-VM for ima@ietf.org; Wed, 29 Nov 2006 07:18:13 -0500 Received: from virkku.fmi.fi (virkku.fmi.fi [193.166.211.54]) (envelope-from hurtta@siilo.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20061107) with ESMTP id kATCI7Ud023374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Nov 2006 14:18:07 +0200 Received: from siilo.fmi.fi by virkku.fmi.fi with ESMTP id kATCI7lK027566 ; Wed, 29 Nov 2006 14:18:07 +0200 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id kATCI642005905 ; Wed, 29 Nov 2006 14:18:06 +0200 Received: by siilo.fmi.fi id kATCI6aM005902; Wed, 29 Nov 2006 14:18:06 +0200 Message-Id: <200611291218.kATCI6aM005902@siilo.fmi.fi> Subject: Re: [EAI] Local-Part auto converting ? In-Reply-To: <064801c71391$21b9aa30$c7d348d3@aabbeell> To: abel Date: Wed, 29 Nov 2006 14:18:06 +0200 (EET) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123e (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20061129/17128/01 X-Filter: smtp1gate: ID 17127/01, 1 parts scanned for known viruses X-Filter: virkku: ID 9247/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 17127/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Kari Hurtta , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> abel [ Charset UTF-8 unsupported, converting... ] > > If envelope sender address is UTF8 address, mail is either bounced or > > server provieds some fancy gatewing service (I wrote about these some time > ago). > May you describe ideas about "fancy gatewing service " ? >From archive http://article.gmane.org/gmane.ietf.ima/548 for example. > > Abel / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 10:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpR1M-0007Kc-BB; Wed, 29 Nov 2006 10:06:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpR1L-0007KL-JD for ima@ietf.org; Wed, 29 Nov 2006 10:06:47 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpR1H-0004CK-Vh for ima@ietf.org; Wed, 29 Nov 2006 10:06:47 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GpR0W-0005F4-MN for ima@ietf.org; Wed, 29 Nov 2006 16:05:57 +0100 Received: from d253181.dialin.hansenet.de ([80.171.253.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 16:05:56 +0100 Received: from nobody by d253181.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 16:05:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Local-Part auto converting ? Date: Wed, 29 Nov 2006 16:02:55 +0100 Organization: Lines: 38 Message-ID: <456DA11F.4DD4@xyzzy.claranet.de> References: <04d201c71360$712c1110$c7d348d3@aabbeell><456D0558.6010604@icu.ac.kr><057501c7136f$35401c00$c7d348d3@aabbeell><456D1A72.9000700@icu.ac.kr><05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253181.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org abel wrote: > I think we need a default if MUA has no ALT-ADDRESS. If I got that right your proposal is about a... RCPT TO: ...without alt-address, relayed by a server wishing to add a "for" clause in its timestamp line. For the right hand side the spec. apparently says that it should use xn--whatever.domain.example In other words the relay can't be completey stupid, it has to know how to generate a punycode form of a given UTF-8 domain. That's okay, it has to figure out what UTF-8.domain.example is, for that it has to use DNS, and so it will also know how to handle punycode. For the left hand side (local part) it could use some ad hoc notation in its "for" clause, percent-encoded or similar, but a default would be better. It's not required to be a "real" ASCII address, but we better make sure that it's a sytactically invalid local part - if it's invalid it can't be (ab)used as "real" address. Something like... for (hh:hh:hh:hh)@xn--whatever.domain.example ...could do the trick, "(", ":", and ")" aren't allowed in dot-atom-text. Is that in essence your proposal for a "for"-clause ? Ignoring the syntactical details, if "(" and ")" is a bad idea we could find something else. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 10:22:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRGD-0003Cl-Tr; Wed, 29 Nov 2006 10:22:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRG7-0002lm-M0 for ima@ietf.org; Wed, 29 Nov 2006 10:22:03 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRDg-0006Tf-E7 for ima@ietf.org; Wed, 29 Nov 2006 10:19:33 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GpRDd-000GaJ-Tt; Wed, 29 Nov 2006 10:19:30 -0500 Date: Wed, 29 Nov 2006 10:19:29 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Local-Part auto converting ? Message-ID: <629FC2492D208D2D363DFB44@p3.JCK.COM> In-Reply-To: <456DA11F.4DD4@xyzzy.claranet.de> References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 29 November, 2006 16:02 +0100 Frank Ellermann wrote: > abel wrote: > >> I think we need a default if MUA has no ALT-ADDRESS. > > If I got that right your proposal is about a... > > RCPT TO: > > ...without alt-address, relayed by a server wishing to > add a "for" clause in its timestamp line. > > For the right hand side the spec. apparently says that > it should use xn--whatever.domain.example > > In other words the relay can't be completey stupid, it > has to know how to generate a punycode form of a given > UTF-8 domain. That's okay, it has to figure out what > UTF-8.domain.example is, for that it has to use DNS, > and so it will also know how to handle punycode. > > For the left hand side (local part) it could use some > ad hoc notation in its "for" clause, percent-encoded or > similar, but a default would be better. It's not > required to be a "real" ASCII address, but we better > make sure that it's a sytactically invalid local part - > if it's invalid it can't be (ab)used as "real" address. > > Something like... > > for (hh:hh:hh:hh)@xn--whatever.domain.example > > ...could do the trick, "(", ":", and ")" aren't allowed > in dot-atom-text. Is that in essence your proposal for > a "for"-clause ? Ignoring the syntactical details, if > "(" and ")" is a bad idea we could find something else. Of course, "(...)" is a comment. So the example above is equivalent, in every way, to for (bogus-nonsense)@xn--whatever.domain.example That takes us back to where I thought we were several weeks ago, i.e., simply dropping "for" clauses on downgrade, just as they are dropped (or not included in the first place) in all sorts of other cases, such as multiple-recipient messages. One could, of course say that, instead of dropping the "for" clause in this case, one MAY transform it into "(for undowngradable-utf8-string@" punycode-domain ")" But I have been unable to understand why we are having this discussion again, so perhaps I'm still missing something. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 10:22:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRGE-0003Fk-Fe; Wed, 29 Nov 2006 10:22:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRG8-0002pi-Kk for ima@ietf.org; Wed, 29 Nov 2006 10:22:04 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpRD0-0006Ky-8Z for ima@ietf.org; Wed, 29 Nov 2006 10:18:51 -0500 Received: (snipe 28406 invoked by uid 0); 30 Nov 2006 00:20:18 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.035562 secs); Received: from unknown (HELO ?192.168.10.145?) (Z?h?own@210.107.249.23) by unknown with SMTP; 30 Nov 2006 00:20:17 +0900 X-RCPTTO: nobody@xyzzy.claranet.de, ima@ietf.org, yangwooko@gmail.com Message-ID: <456DA4D3.80502@icu.ac.kr> Date: Thu, 30 Nov 2006 00:18:43 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell><456D0558.6010604@icu.ac.kr><057501c7136f$35401c00$c7d348d3@aabbeell><456D1A72.9000700@icu.ac.kr><05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> In-Reply-To: <456DA11F.4DD4@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: > abel wrote: > >> I think we need a default if MUA has no ALT-ADDRESS. > > If I got that right your proposal is about a... > > RCPT TO: > > ..without alt-address, relayed by a server wishing to > add a "for" clause in its timestamp line. > > For the right hand side the spec. apparently says that > it should use xn--whatever.domain.example > > In other words the relay can't be completey stupid, it > has to know how to generate a punycode form of a given > UTF-8 domain. That's okay, it has to figure out what > UTF-8.domain.example is, for that it has to use DNS, > and so it will also know how to handle punycode. > > For the left hand side (local part) it could use some > ad hoc notation in its "for" clause, percent-encoded or > similar, but a default would be better. It's not > required to be a "real" ASCII address, but we better > make sure that it's a sytactically invalid local part - > if it's invalid it can't be (ab)used as "real" address. > > Something like... > > for (hh:hh:hh:hh)@xn--whatever.domain.example > > ..could do the trick, "(", ":", and ")" aren't allowed > in dot-atom-text. Is that in essence your proposal for > a "for"-clause ? Ignoring the syntactical details, if > "(" and ")" is a bad idea we could find something else. If we decided to "encode" local part, I want it be applied to the other side (i.e. domain part) so that the whole address can be consistently processed. For example, with one encoding to whole address, we just need to copy and paste the "encoded" address to a converter to see what it originally was. Then, how about applying puny code to local part? Well, my gut feeling is against it. Because puny code is expected to be used for domain names. > > Frank > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 10:41:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRZC-0005QH-Um; Wed, 29 Nov 2006 10:41:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRZC-0005Q0-04 for ima@ietf.org; Wed, 29 Nov 2006 10:41:46 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpRZA-0003Nu-Br for ima@ietf.org; Wed, 29 Nov 2006 10:41:45 -0500 Received: (snipe 7504 invoked by uid 0); 30 Nov 2006 00:43:16 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.030252 secs); Received: from unknown (HELO ?192.168.10.145?) (Z???own@210.107.249.23) by unknown with SMTP; 30 Nov 2006 00:43:16 +0900 X-RCPTTO: klensin@jck.com, ima@ietf.org, yangwooko@gmail.com Message-ID: <456DAA36.7090800@icu.ac.kr> Date: Thu, 30 Nov 2006 00:41:42 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> In-Reply-To: <629FC2492D208D2D363DFB44@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > > > --On Wednesday, 29 November, 2006 16:02 +0100 Frank Ellermann > wrote: > >> abel wrote: >> >>> I think we need a default if MUA has no ALT-ADDRESS. >> If I got that right your proposal is about a... >> >> RCPT TO: >> >> ...without alt-address, relayed by a server wishing to >> add a "for" clause in its timestamp line. >> >> For the right hand side the spec. apparently says that >> it should use xn--whatever.domain.example >> >> In other words the relay can't be completey stupid, it >> has to know how to generate a punycode form of a given >> UTF-8 domain. That's okay, it has to figure out what >> UTF-8.domain.example is, for that it has to use DNS, >> and so it will also know how to handle punycode. >> >> For the left hand side (local part) it could use some >> ad hoc notation in its "for" clause, percent-encoded or >> similar, but a default would be better. It's not >> required to be a "real" ASCII address, but we better >> make sure that it's a sytactically invalid local part - >> if it's invalid it can't be (ab)used as "real" address. >> >> Something like... >> >> for (hh:hh:hh:hh)@xn--whatever.domain.example >> >> ...could do the trick, "(", ":", and ")" aren't allowed >> in dot-atom-text. Is that in essence your proposal for >> a "for"-clause ? Ignoring the syntactical details, if >> "(" and ")" is a bad idea we could find something else. > > Of course, "(...)" is a comment. So the example above is > equivalent, in every way, to > for (bogus-nonsense)@xn--whatever.domain.example > > That takes us back to where I thought we were several weeks ago, > i.e., simply dropping "for" clauses on downgrade, just as they > are dropped (or not included in the first place) in all sorts of > other cases, such as multiple-recipient messages. One could, > of course say that, instead of dropping the "for" clause in this > case, one MAY transform it into > "(for undowngradable-utf8-string@" punycode-domain ")" > > But I have been unable to understand why we are having this > discussion again, so perhaps I'm still missing something. I had the same question. I found that there are several cases where "for" clauses are not generated. (Multiple recipients, Bcc, and others) [[ Email Tutorial Session Then, what is "for" for? What are typical examples of automated processing of "for" clauses? Or, is it a MUST/SHOULD in some RFC? ]] > > john > > > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 10:42:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRZw-0005jk-Rp; Wed, 29 Nov 2006 10:42:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRZv-0005jY-KD for ima@ietf.org; Wed, 29 Nov 2006 10:42:31 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRZt-0003WU-8L for ima@ietf.org; Wed, 29 Nov 2006 10:42:31 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GpRZK-0004A5-Uk for ima@ietf.org; Wed, 29 Nov 2006 16:41:54 +0100 Received: from d253181.dialin.hansenet.de ([80.171.253.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 16:41:54 +0100 Received: from nobody by d253181.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 16:41:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Local-Part auto converting ? Date: Wed, 29 Nov 2006 16:40:45 +0100 Organization: Lines: 36 Message-ID: <456DA9FD.6FD8@xyzzy.claranet.de> References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253181.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > I have been unable to understand why we are having this > discussion again, so perhaps I'm still missing something. No, it's me, I didn't know that it's a design decision if a "for" clause can't work in UTF8SMTP without alt-address. Checking the drafts, smtpext-02 says in 2.7.2: | Addresses in "for" clauses need further examination and | might be treated differently depending on [EAI-utf8header]. Maybe it should say: "'for'-clauses cannot be used without alt-address, if the local part is UTF-8" (or similar). Yangwoo Ko wrote in a parallell message: > If we decided to "encode" local part, I want it be > applied to the other side (i.e. domain part) so that > the whole address can be consistently processed. > For example, with one encoding to whole address, > we just need to copy and paste the "encoded" address to > a converter to see what it originally was. > Then, how about applying puny code to local part? > Well, my gut feeling is against it. Because puny > code is expected to be used for domain names. ACK, it MUST NOT be similar to any possible address if it's no "real" address, the spammers would try to abuse it without checking the details of RFC 2821 or 2822. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 11:00:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRqx-0003Hj-Uj; Wed, 29 Nov 2006 11:00:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRqw-0003HY-ED for ima@ietf.org; Wed, 29 Nov 2006 11:00:06 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRqZ-0006HF-Sp for ima@ietf.org; Wed, 29 Nov 2006 11:00:06 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GpRqK-00081U-OK for ima@ietf.org; Wed, 29 Nov 2006 16:59:28 +0100 Received: from d253181.dialin.hansenet.de ([80.171.253.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 16:59:28 +0100 Received: from nobody by d253181.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 16:59:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Local-Part auto converting ? Date: Wed, 29 Nov 2006 16:58:16 +0100 Organization: Lines: 30 Message-ID: <456DAE18.43A0@xyzzy.claranet.de> References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253181.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yangwoo Ko wrote: > Then, what is "for" for? What are typical examples > of automated processing of "for" clauses? Header analysis if something doesn't work - if I get a non-delivery report "foo@bar.example - no such user" and never sent a mail to foo@bar, an earlier "for"- clause can help to identify what's it about: Received: from one by two for foo@bar.example ... Received: from me by one for user@foo.example ... Apparently user@foo forwards his mail at one to the address foo@bar, and I'd know if I really tried to send a mail to user@foo. It's a similar situation if the mail arrives at foo@bar with To: user@foo, and this user forgot that he still has a forwarding arrangement at server one. > is it a MUST/SHOULD in some RFC? No. In the worst case it's a SHOULD NOT for the privacy reasons stated in the 251-section. I'm too lazy to check this. It's only for forensics. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 11:06:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRwh-00050b-R7; Wed, 29 Nov 2006 11:06:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRwh-00050P-8Z for ima@ietf.org; Wed, 29 Nov 2006 11:06:03 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRwf-0007RE-V7 for ima@ietf.org; Wed, 29 Nov 2006 11:06:03 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A52292596BB; Wed, 29 Nov 2006 17:02:50 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10053-07; Wed, 29 Nov 2006 17:02:36 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A26D2596B7; Wed, 29 Nov 2006 17:02:36 +0100 (CET) Message-ID: <456DAFDA.40101@alvestrand.no> Date: Wed, 29 Nov 2006 17:05:46 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Yangwoo Ko Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> In-Reply-To: <456DAA36.7090800@icu.ac.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yangwoo Ko wrote: > > I had the same question. I found that there are several > cases where "for" clauses are not generated. (Multiple > recipients, Bcc, and others) > > [[ Email Tutorial Session > > Then, what is "for" for? What are typical examples of > automated processing of "for" clauses? Or, is it a > MUST/SHOULD in some RFC? ]] We thought it was a good idea 20 years ago. It's sometimes useful in debugging alias files, or figuring out which particular obscure mailing list I've forgotten to unsubscribe from. Neither of the statements above means that it's a good idea today. And AFAIK, it's not a MUST/SHOULD in any RFC. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 11:16:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpS6x-0007mq-UU; Wed, 29 Nov 2006 11:16:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpS6w-0007mK-Am for ima@ietf.org; Wed, 29 Nov 2006 11:16:38 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpS6u-0001Eb-SY for ima@ietf.org; Wed, 29 Nov 2006 11:16:38 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GpS6u-000H7E-3i; Wed, 29 Nov 2006 11:16:36 -0500 Date: Wed, 29 Nov 2006 11:16:35 -0500 From: John C Klensin To: Yangwoo Ko Subject: Re: [EAI] Local-Part auto converting ? Message-ID: <863855462E91E54F5B8CAB68@p3.JCK.COM> In-Reply-To: <456DAA36.7090800@icu.ac.kr> References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 30 November, 2006 00:41 +0900 Yangwoo Ko wrote: > I had the same question. I found that there are several > cases where "for" clauses are not generated. (Multiple > recipients, Bcc, and others) > > [[ Email Tutorial Session > > Then, what is "for" for? What are typical examples of > automated processing of "for" clauses? Or, is it a > MUST/SHOULD in some RFC? ]] Automated processing of anything that appears in a "Received:" header field is essentially prohibited by the standards. Those fields are generally only intended for tracing and debugging. The prohibition is sometimes violated in practice, but production implementations that violate it have learned to be _very_ careful to expect, and not fail or do something stupid because of, unexpected syntax, odd constructions, unusable information, and so on. I don't remember the whole history and may not have ever known, but "for" seemed to be a good idea in a different time. I can remember a few reasons, such as tracking address changes across gateway-type boundaries. At least in theory, the right place to track address changes due to forwarding is in "Resent-" fields, so information in "for", if present, would be redundant and, conversely, if "for" is needed to straighten out forwarding issues, one is already in trouble. Over the years, the recommendations about their use have become more and more restricted. That process accelerated when it was pointed out that they could accidentally breach the security of private information, with the ever-fragile "blind-copy" concept being one of the worst cases. What we are left with, in essence, is that one may include a "for" clause in a single-recipient message in which the recipient address also appears in the "To:" or "Cc:" header. But their use in all other cases is strongly discouraged. I believe that there are several MTAs implementers out there that have decided that the complexity of evaluating the conditions under which "for" is safe are complex enough relative to its value to simply never produce it. The standard permits that interpretation, so one can _never_ count on the "for" clause being present. So, again getting back to where I thought we were weeks ago, I believe that: * Any "for" clause that contains UTF-8 material should be discarded on downgrade. * Instead of discarding it, one might plausibly turn the entire clause into a comment. Of course, one could devise syntax for use within the comment that explicitly identifies the encoding(s) being used, an option that does not exist with "for". In the absence of some compelling argument about the importance of "for", one compelling enough to override the trend toward reduction of its use, I think anything beyond the above just makes the protocol more complicated without adding significant value. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 12:46:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpTV8-0003Ke-Sj; Wed, 29 Nov 2006 12:45:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpTV7-0003Jd-B8 for ima@ietf.org; Wed, 29 Nov 2006 12:45:41 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpTV2-0006Nt-20 for ima@ietf.org; Wed, 29 Nov 2006 12:45:41 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GpTUL-0003WM-Vq for ima@ietf.org; Wed, 29 Nov 2006 18:44:55 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 18:44:53 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 18:44:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Local-Part auto converting ? Date: 29 Nov 2006 19:44:18 +0200 Lines: 20 Message-ID: <5dd576rvv1.fsf@Hurtta06k.keh.iki.fi> References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "abel" writes gmane.ietf.ima: > > Return-Path header field is generated when mail is disposed to mailbox. > > It is not on mail which is on transit. > if it's a catch-all server, how to bounce mail with a ASCII 'Return-Path' > to UTF8 address ? I think that I'm lost. I do not see how your question makes sense as comment to may text about Return-Path header field. Bounces uses <> as envelope sender address. Please do not confuse Return-path header field, which is added when mail is written to mailbox, with envelope sender address which is carried with MAIL FROM command on SMTP. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 15:23:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVxH-0000Z4-4n; Wed, 29 Nov 2006 15:22:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVxG-0000Yr-7O for ima@ietf.org; Wed, 29 Nov 2006 15:22:54 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpVx9-0005ke-HF for ima@ietf.org; Wed, 29 Nov 2006 15:22:54 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3$clerew$man#ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 456dec15.127c2.23a for ima@ietf.org; Wed, 29 Nov 2006 20:22:45 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kATKMfm9022546 for ; Wed, 29 Nov 2006 20:22:42 GMT To: IMA Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> Message-ID: Date: Wed, 29 Nov 2006 20:22:40 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <629FC2492D208D2D363DFB44@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 29 Nov 2006 15:19:29 -0000, John C Klensin wrote: > > That takes us back to where I thought we were several weeks ago, > i.e., simply dropping "for" clauses on downgrade, just as they > are dropped (or not included in the first place) in all sorts of > other cases, such as multiple-recipient messages. One could, > of course say that, instead of dropping the "for" clause in this > case, one MAY transform it into > "(for undowngradable-utf8-string@" punycode-domain ")" My recollection was that we decided not to include a 'for' at all in a Received header for any UTF8SMTP mail. That way nobody could be embarassed at having to modify the Received header. There was a suggestion from Chris Newman to put the equivalent of a 'for' in a comment (though that would imply that one could downgrade comments in Received headers). Of course, if you have an alt-address, you can always use that, even if you are still hopeful of delivery to the utf8-address. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 15:28:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpW2q-0002ZQ-6c; Wed, 29 Nov 2006 15:28:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpW2p-0002ZL-8n for ima@ietf.org; Wed, 29 Nov 2006 15:28:39 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpW2n-0007So-MA for ima@ietf.org; Wed, 29 Nov 2006 15:28:39 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3#clerew^man&ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 456ded74.b668.22f for ima@ietf.org; Wed, 29 Nov 2006 20:28:36 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kATKSZaE022909 for ; Wed, 29 Nov 2006 20:28:36 GMT To: IMA Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> <456DAFDA.40101@alvestrand.no> Message-ID: Date: Wed, 29 Nov 2006 20:28:35 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <456DAFDA.40101@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 29 Nov 2006 16:05:46 -0000, Harald Alvestrand wrote: > It's sometimes useful in debugging alias files, or figuring out which > particular obscure mailing list I've forgotten to unsubscribe from. > > Neither of the statements above means that it's a good idea today. Personally, I find it useful quite often. I receive some (possibly spam) whose To: and From: headers make no sense to me. So I look at the Received headers to see why it came to me. That way the 'for' field will at least tell me why it came to me, and whether I got it as chl@clerew.man.ac.uk, or as daemon@clerew.ac.uk, or as committee@usenet.org.uk or various other possibilities -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 16:03:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWaE-0004aK-5T; Wed, 29 Nov 2006 16:03:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWaC-0004aF-Jb for ima@ietf.org; Wed, 29 Nov 2006 16:03:08 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWaB-00050O-66 for ima@ietf.org; Wed, 29 Nov 2006 16:03:08 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GpWYZ-0004kb-PC for ima@ietf.org; Wed, 29 Nov 2006 22:01:27 +0100 Received: from d253181.dialin.hansenet.de ([80.171.253.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 22:01:27 +0100 Received: from nobody by d253181.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 22:01:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: OT: Resent-* (was: [EAI] Local-Part auto converting ?) Date: Wed, 29 Nov 2006 22:00:28 +0100 Organization: Lines: 45 Message-ID: <456DF4EC.2BD6@xyzzy.claranet.de> References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> <863855462E91E54F5B8CAB68@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253181.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > At least in theory, the right place to track address changes > due to forwarding is in "Resent-" fields, That's an interesting statement. I'm not sure about the theory in STD 11, and you're probably not talking about RFC 4406. In RFC 2822 the MUSTard theory is apparently different: | Resent fields are strictly informational. They MUST NOT be | used in the normal processing of replies or other such automatic | actions on messages. | | Note: Reintroducing a message into the transport system and using | resent fields is a different operation from "forwarding". | "Forwarding" has two meanings: One sense of forwarding is that a mail | reading program can be told by a user to forward a copy of a message | to another person, making the forwarded message the body of the new | message. A forwarded message in this sense does not appear to have | come from the original sender, but is an entirely new message from | the forwarder of the message. On the other hand, forwarding is also | used to mean when a mail transport program gets a message and | forwards it on to a different destination for final delivery. | Resent header fields are not intended for use with either type of | forwarding. Resent-* is a big mess, also in 4409 8.1 or (probably) in DKIM SSP, and of course in SenderID after the second SenderID-appeal. > conversely, if "for" is needed to straighten out forwarding > issues, one is already in trouble. Anything remotely related to 1123 5.3.6(a) means trouble. > In the absence of some compelling argument about the importance > of "for", one compelling enough to override the trend toward > reduction of its use, I think anything beyond the above just > makes the protocol more complicated without adding significant > value. If that's clearly documented in one of the next "smtpext" drafts it's okay. SMTP has worse problems than this. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 17:24:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXqp-0004jT-BH; Wed, 29 Nov 2006 17:24:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXqo-0004jL-9b for ima@ietf.org; Wed, 29 Nov 2006 17:24:22 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpXql-0006x9-UZ for ima@ietf.org; Wed, 29 Nov 2006 17:24:22 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GpXql-000JvV-5Y; Wed, 29 Nov 2006 17:24:19 -0500 Date: Wed, 29 Nov 2006 17:24:18 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: OT: Resent-* (was: [EAI] Local-Part auto converting ?) Message-ID: <3D538DE8C508C8778A0E2DEF@p3.JCK.COM> In-Reply-To: <456DF4EC.2BD6@xyzzy.claranet.de> References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> <863855462E91E54F5B8CAB68@p3.JCK.COM> <456DF4EC.2BD6@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 29 November, 2006 22:00 +0100 Frank Ellermann wrote: >... > Resent-* is a big mess, also in 4409 8.1 or (probably) in DKIM > SSP, and of course in SenderID after the second > SenderID-appeal. I do not disagree with this. But "Received: ...for" isn't the place to try to fix it. >> conversely, if "for" is needed to straighten out forwarding >> issues, one is already in trouble. > > Anything remotely related to 1123 5.3.6(a) means trouble. No comment in the context of this WG. >> In the absence of some compelling argument about the >> importance of "for", one compelling enough to override the >> trend toward reduction of its use, I think anything beyond >> the above just makes the protocol more complicated without >> adding significant value. > > If that's clearly documented in one of the next "smtpext" > drafts it's okay. SMTP has worse problems than this. I agree that it should be clearly documented. The WG needs to figure out whether to prohibit UTF-8 in "for" clauses entirely, or to require discarding "for" clauses containing UTF-8 material on downgrading. In the first case, the relevant text would go in the "smtpext" draft. In the second, it might well go in the "downgrade" document. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 17:37:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpY3H-0006WY-IY; Wed, 29 Nov 2006 17:37:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpY3G-0006WR-9P for ima@ietf.org; Wed, 29 Nov 2006 17:37:14 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpY3D-0008LS-Ti for ima@ietf.org; Wed, 29 Nov 2006 17:37:14 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id kATMbBei027898; Wed, 29 Nov 2006 14:37:11 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id kATMbAIJ027894; Wed, 29 Nov 2006 14:37:10 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 29 Nov 2006 14:37:10 -0800 (PST) From: "william(at)elan.net" To: John C Klensin Subject: Re: OT: Resent-* (was: [EAI] Local-Part auto converting ?) In-Reply-To: <3D538DE8C508C8778A0E2DEF@p3.JCK.COM> Message-ID: References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> <863855462E91E54F5B8CAB68@p3.JCK.COM> <456DF4EC.2BD6@xyzzy.claranet.de> <3D538DE8C508C8778A0E2DEF@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 29 Nov 2006, John C Klensin wrote: > --On Wednesday, 29 November, 2006 22:00 +0100 Frank Ellermann > wrote: > >> ... >> Resent-* is a big mess, also in 4409 8.1 or (probably) in DKIM >> SSP, and of course in SenderID after the second >> SenderID-appeal. > > I do not disagree with this. But "Received: ...for" isn't the > place to try to fix it. Sometime ago I proposed new trace header field for this purpose: http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-01.txt (also http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-01.html) You're welcome to send me comments about it and I'll get for -02 version sometime next year (I've been working on it as well as well as few other drafts although rather slowly). I note also that for example Gmail is using sever X- fields for this purpose, for example, in particular I see the following in between the Received header fields for email that goes though my gmail account: Received: ... X-Forwarded-To: william@elan.net X-Forwarded-For: leibzon@gmail.com william@elan.net Delivered-To: leibzon@gmail.com Received: ... -- William Leibzon Elan Networks william@elan.net _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 17:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpY6x-0006tc-RG; Wed, 29 Nov 2006 17:41:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpY6x-0006tX-2U for ima@ietf.org; Wed, 29 Nov 2006 17:41:03 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpY6v-0000Ug-I3 for ima@ietf.org; Wed, 29 Nov 2006 17:41:03 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GpY6u-000K4d-7m; Wed, 29 Nov 2006 17:41:00 -0500 Date: Wed, 29 Nov 2006 17:40:59 -0500 From: John C Klensin To: "william(at)elan.net" Subject: Re: OT: Resent-* (was: [EAI] Local-Part auto converting ?) Message-ID: In-Reply-To: References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> <863855462E91E54F5B8CAB68@p3.JCK.COM> <456DF4EC.2BD6@xyzzy.claranet.de> <3D538DE8C508C8778A0E2DEF@p3.JCK.COM> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 29 November, 2006 14:37 -0800 "william(at)elan.net" wrote: > > On Wed, 29 Nov 2006, John C Klensin wrote: > >> --On Wednesday, 29 November, 2006 22:00 +0100 Frank Ellermann >> wrote: >> >>> ... >>> Resent-* is a big mess, also in 4409 8.1 or (probably) in >>> DKIM SSP, and of course in SenderID after the second >>> SenderID-appeal. >> >> I do not disagree with this. But "Received: ...for" isn't the >> place to try to fix it. > > Sometime ago I proposed new trace header field for this > purpose: > > http://www.elan.net/~william/emailsecurity/draft-leibzon-email > redirection-traceheaders-01.txt > (also > http://www.elan.net/~william/emailsecurity/draft-leibzon-email > redirection-traceheaders-01.html) > > You're welcome to send me comments about it and I'll get for > -02 version > sometime next year (I've been working on it as well as well as > few other > drafts although rather slowly). Just make sure you direct comments on it, and initiate discussion on it, on the SMTP list, not here. This WG really cannot start improving/fixing basic SMTP characteristics or we will never get our work finished. > I note also that for example Gmail is using sever X- fields > for this purpose, for example, in particular I see the > following in between the Received header fields for email that > goes though my gmail account: > > Received: ... > X-Forwarded-To: william@elan.net > X-Forwarded-For: leibzon@gmail.com william@elan.net > Delivered-To: leibzon@gmail.com > Received: ... Not original, and, unless time-stamped, etc., will cause their own set of problems. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 20:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpbAf-00085X-GV; Wed, 29 Nov 2006 20:57:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpbAe-00085R-RB for ima@ietf.org; Wed, 29 Nov 2006 20:57:04 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpbAa-0000Ox-VB for ima@ietf.org; Wed, 29 Nov 2006 20:57:04 -0500 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by twnic.net.tw (8.13.8/8.13.8) with SMTP id kAU1uvSL016828; Thu, 30 Nov 2006 09:56:58 +0800 Message-ID: <07a501c71422$f9c26a20$c7d348d3@aabbeell> From: "abel" To: , "Kari Hurtta" References: <04d201c71360$712c1110$c7d348d3@aabbeell><456D0558.6010604@icu.ac.kr><057501c7136f$35401c00$c7d348d3@aabbeell><456D1A72.9000700@icu.ac.kr><05c501c71383$253ee1b0$c7d348d3@aabbeell><5dejrmvhi4.fsf@leija.fmi.fi><062701c7138e$663aecd0$c7d348d3@aabbeell> <5dd576rvv1.fsf@Hurtta06k.keh.iki.fi> Subject: Re: [EAI] Local-Part auto converting ? Date: Thu, 30 Nov 2006 09:58:03 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > Bounces uses <> as envelope sender address. > > > Please do not confuse Return-path header field, which is added when mail > is written to mailbox, with envelope sender address which is carried > with MAIL FROM command on SMTP. Thanks for your comment, I greatly admire your contribution to sendmail. But according to the draft, it seems, "Return-Path" as well as puny code (Ascii), does it confuse ? Abel _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 29 23:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpdp9-0006ur-Pr; Wed, 29 Nov 2006 23:47:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpdp8-0006ul-6X for ima@ietf.org; Wed, 29 Nov 2006 23:47:02 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpdp6-00010F-St for ima@ietf.org; Wed, 29 Nov 2006 23:47:02 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gpdot-00083H-Sd for ima@ietf.org; Thu, 30 Nov 2006 05:46:47 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Nov 2006 05:46:47 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Nov 2006 05:46:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Local-Part auto converting ? Date: 30 Nov 2006 06:46:37 +0200 Lines: 39 Message-ID: <5dr6vlilsi.fsf@Hurtta06k.keh.iki.fi> References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <5dd576rvv1.fsf@Hurtta06k.keh.iki.fi> <07a501c71422$f9c26a20$c7d348d3@aabbeell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "abel" writes in gmane.ietf.ima: > > Bounces uses <> as envelope sender address. > > > > > > Please do not confuse Return-path header field, which is added when mail > > is written to mailbox, with envelope sender address which is carried > > with MAIL FROM command on SMTP. > > Thanks for your comment, I greatly admire your contribution to sendmail. But I still did not understand question. | "abel" writes gmane.ietf.ima: | | > > Return-Path header field is generated when mail is disposed to mailbox. | > > It is not on mail which is on transit. | > if it's a catch-all server, how to bounce mail with a ASCII 'Return-Path' | > to UTF8 address ? | | I think that I'm lost. What is a scenarion ? I'm still lost. > But according to the draft, it seems, "Return-Path" as well as puny code > (Ascii), > does it confuse ? http://article.gmane.org/gmane.ietf.ima/733 I think that it was intention that Return-Path: header field can store enevelope sender address from MAIL FROM when mail is stored to mailbox. Even when it is UTF-8. > Abel / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 01:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpfjp-0007vs-A7; Thu, 30 Nov 2006 01:49:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpfjo-0007vX-8D for ima@ietf.org; Thu, 30 Nov 2006 01:49:40 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpfjl-0002zl-IP for ima@ietf.org; Thu, 30 Nov 2006 01:49:40 -0500 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by twnic.net.tw (8.13.8/8.13.8) with SMTP id kAU6nZEv032209; Thu, 30 Nov 2006 14:49:35 +0800 Message-ID: <096601c7144b$da86d280$c7d348d3@aabbeell> From: "abel" To: , "Kari Hurtta" References: <04d201c7136012c1110@aabbeell><456D0558.6010604@icu.ac.kr><057501c7136f5401c00@aabbeell><456D1A72.9000700@icu.ac.kr><05c501c7138353ee1b0@aabbeell><5dejrmvhi4.fsf@leija.fmi.fi><062701c7138e63aecd0@aabbeell><5dd576rvv1.fsf@Hurtta06k.keh.iki.fi><07a501c71422@aabbeell> <5dr6vlilsi.fsf@Hurtta06k.keh.iki.fi> Subject: Re: [EAI] Local-Part auto converting ? Date: Thu, 30 Nov 2006 14:50:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > > > Please do not confuse Return-path header field, which is added when mail > > > is written to mailbox, with envelope sender address which is carried > > > with MAIL FROM command on SMTP. > > > > Thanks for your comment, I greatly admire your contribution to sendmail. > > But I still did not understand question. > > | "abel" writes gmane.ietf.ima: > | > | > > Return-Path header field is generated when mail is disposed to mailbox. > | > > It is not on mail which is on transit. > | > if it's a catch-all server, how to bounce mail with a ASCII 'Return-Path' > | > to UTF8 address ? > | > | I think that I'm lost. > > What is a scenarion ? I'm still lost. > > > > > But according to the draft, it seems, "Return-Path" as well as puny code > > (Ascii), > > does it confuse ? > > http://article.gmane.org/gmane.ietf.ima/733 > > I think that it was intention that Return-Path: header field can store > enevelope sender address from MAIL FROM when mail is stored to mailbox. > Even when it is UTF-8. Sorry Kari, I didn't explain my question clearly, as I know the Trace Fields include "Return-Path" and "Received". but the drafts talk about Trace Fields section in "Received" only, so I wonder that the "Return-Path" produce rule, Your comment is articulate , Whether it is UTF8 or ASCII,the envelope from equals "Return-Path" header value. Abel _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 02:47:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpgdB-0006Bi-AD; Thu, 30 Nov 2006 02:46:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpgdA-0006BW-65 for ima@ietf.org; Thu, 30 Nov 2006 02:46:52 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpgd8-00064c-HH for ima@ietf.org; Thu, 30 Nov 2006 02:46:52 -0500 Received: from [211.72.211.94] (pc094.twnic.net.tw [211.72.211.94]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id kAU7klva002673; Thu, 30 Nov 2006 15:46:47 +0800 Message-ID: <456E8F28.5070702@twnic.net.tw> Date: Thu, 30 Nov 2006 15:58:32 +0800 From: Jeff Yeh User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: abel Subject: Re: [EAI] Local-Part auto converting ? References: <04d201c7136012c1110@aabbeell><456D0558.6010604@icu.ac.kr><057501c7136f5401c00@aabbeell><456D1A72.9000700@icu.ac.kr><05c501c7138353ee1b0@aabbeell><5dejrmvhi4.fsf@leija.fmi.fi><062701c7138e63aecd0@aabbeell><5dd576rvv1.fsf@Hurtta06k.keh.iki.fi><07a501c71422@aabbeell> <5dr6vlilsi.fsf@Hurtta06k.keh.iki.fi> <096601c7144b$da86d280$c7d348d3@aabbeell> In-Reply-To: <096601c7144b$da86d280$c7d348d3@aabbeell> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I think Abel is trying to say that "Return-Path" is also part of trace field. As discussed in earlier post, all trace field must put in ASCII. For "Received" can skip "for" to bypass the UTF8->ASCII convertion. However, the "Return-Path" still need a converting algorithm. Under the circumstance of "MAIL FROM is UTF8 without ALT ADDRESS". Jeff Yeh -TWNIC > > Sorry Kari, I didn't explain my question clearly, as I know the Trace > Fields include "Return-Path" and "Received". > but the drafts talk about Trace Fields section in "Received" only, so I > wonder that the "Return-Path" produce rule, > Your comment is articulate , Whether it is UTF8 or ASCII,the envelope from > equals "Return-Path" header value. > > Abel > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 03:05:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpgvK-0005ta-3D; Thu, 30 Nov 2006 03:05:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpgvI-0005r1-M8 for ima@ietf.org; Thu, 30 Nov 2006 03:05:36 -0500 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpgvH-00020m-78 for ima@ietf.org; Thu, 30 Nov 2006 03:05:36 -0500 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20061107) with ESMTP id kAU85VOg028310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Nov 2006 10:05:31 +0200 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id kAU85U9h002837 ; Thu, 30 Nov 2006 10:05:30 +0200 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id kAU85TdV020259 ; Thu, 30 Nov 2006 10:05:29 +0200 Received: by siilo.fmi.fi id kAU85T0J020256; Thu, 30 Nov 2006 10:05:29 +0200 Message-Id: <200611300805.kAU85T0J020256@siilo.fmi.fi> Subject: Re: [EAI] Local-Part auto converting ? In-Reply-To: <456E8F28.5070702@twnic.net.tw> To: Jeff Yeh Date: Thu, 30 Nov 2006 10:05:29 +0200 (EET) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123e (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20061130/21392/01 X-Filter: smtp1gate: ID 21391/01, 1 parts scanned for known viruses X-Filter: torkku: ID 2208/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 21391/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Kari Hurtta , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> Jeff Yeh > I think Abel is trying to say that "Return-Path" is also part of trace > field. As discussed in earlier post, all trace field must put in ASCII. > For "Received" can skip "for" to bypass the UTF8->ASCII convertion. > However, the "Return-Path" still need a converting algorithm. Under the > circumstance of "MAIL FROM is UTF8 without ALT ADDRESS". > > Jeff Yeh > -TWNIC Idea was that Received: -header field must not be altered on transit. Therefore ASCII only. On other hand Return-Path: -header field do not exist when mail is on transit. So Return-Path: -header field is different. On previous discussion answer was when I asked that, that Return-Path: -header field should be allowed to store UTF-8. Return-Path header field may be usefull for MUA. That header field is issue for IMAP and POP downgrade. On SMTP it is supposed to be non existant. > > > > Sorry Kari, I didn't explain my question clearly, as I know the Trace > > Fields include "Return-Path" and "Received". > > but the drafts talk about Trace Fields section in "Received" only, so I > > wonder that the "Return-Path" produce rule, > > Your comment is articulate , Whether it is UTF8 or ASCII,the envelope from > > equals "Return-Path" header value. > > > > Abel OK. Your comment about bounce confused me, because bounce do not use Return-path -header filed (there is no any header field on mail which is on transit.) > > > > _______________________________________________ > > IMA mailing list > > IMA@ietf.org > > https://www1.ietf.org/mailman/listinfo/ima / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 07:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GplCT-0007hU-5l; Thu, 30 Nov 2006 07:39:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GplCR-0007hP-Jo for ima@ietf.org; Thu, 30 Nov 2006 07:39:35 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GplCM-0005dy-07 for ima@ietf.org; Thu, 30 Nov 2006 07:39:35 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3$clerew#man^ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.238) id 456ed0f6.3a87.68 for ima@ietf.org; Thu, 30 Nov 2006 12:39:18 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kAUCdGUD011459 for ; Thu, 30 Nov 2006 12:39:17 GMT Date: Thu, 30 Nov 2006 12:39:16 -0000 To: IMA Subject: Re: OT: Resent-* (was: [EAI] Local-Part auto converting ?) References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> <863855462E91E54F5B8CAB68@p3.JCK.COM> <456DF4EC.2BD6@xyzzy.claranet.de> <3D538DE8C508C8778A0E2DEF@p3.JCK.COM> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 29 Nov 2006 22:37:10 -0000, william(at)elan.net wrote: > Sometime ago I proposed new trace header field for this purpose: > http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-01.txt It seems interesting, though a bit over complicated. However, my immediate reaction is that your Original-* headers bear some slight similarity to our Downgraded header, the main diffewrence being that our downgraded approach applied to your Original-* idea would result in something like: Original-Header: Sender: "W. Rabbit" Just a thought. The point of our Downgraded: header, of course, is that you are allowed to use RFC 2047 encoding inside it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 09:21:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpmmC-0003Wt-CI; Thu, 30 Nov 2006 09:20:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpmm9-0003W6-W3 for ima@ietf.org; Thu, 30 Nov 2006 09:20:33 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpmkI-0003uY-0N for ima@ietf.org; Thu, 30 Nov 2006 09:18:42 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GpmkD-0000GW-Dj; Thu, 30 Nov 2006 09:18:33 -0500 Date: Thu, 30 Nov 2006 09:18:32 -0500 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] Local-Part auto converting ? Message-ID: <9B0FF6AA6492B6E243B45373@p3.JCK.COM> In-Reply-To: References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> <456DAFDA.40101@alvestrand.no> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 29 November, 2006 20:28 +0000 Charles Lindsey wrote: > On Wed, 29 Nov 2006 16:05:46 -0000, Harald > Alvestrand wrote: > >> It's sometimes useful in debugging alias files, or figuring >> out which particular obscure mailing list I've forgotten to >> unsubscribe from. >> >> Neither of the statements above means that it's a good idea >> today. > > Personally, I find it useful quite often. I receive some > (possibly spam)whose To: and From: headers make no sense to > me. So I look at the Receivedheaders to see why it came to me. > That way the 'for' field will at leasttell me why it came to > me, and whether I got it as chl@clerew.man.ac.uk,or as > daemon@clerew.ac.uk, or as committee@usenet.org.uk or various > otherpossibilities Of course, if there is more than one member of "committee@usenet.org.uk", anything that supplies a "for" with an individual address in it is violating the specs. Find a mail system/supplier who will give you access to the forward-pointing and backward-pointing envelope addresses. It will give you just about the same information, _much_ more reliably. But it is irrelevant here. How useful the feature is or isn't to you is a base SMTP issue, not an EAI one. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 11:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpp6N-0000Jr-DE; Thu, 30 Nov 2006 11:49:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpp6M-0000J8-2y for ima@ietf.org; Thu, 30 Nov 2006 11:49:34 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpp6K-0006c9-Gp for ima@ietf.org; Thu, 30 Nov 2006 11:49:34 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kAUGnOLR030663 for ; Fri, 1 Dec 2006 01:49:24 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kAUGnOKD030660 for ima@ietf.org; Fri, 1 Dec 2006 01:49:24 +0900 Date: Fri, 1 Dec 2006 01:49:24 +0900 From: Soobok Lee To: ima@ietf.org Message-ID: <20061130164924.GA24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [EAI] i18n of localpart versus i18n of email RFC standards X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi, All After looking into EAI drafts, I find this WG had been focusing on 18n(utf8-ization) of all Email related RFC standards, rather than defining ACE-encoding standard for non-ascii localpart. I can guess and accept the reason behind the former approach, but i still believe the latter approach has some merits and even co-exist with the cureent EAI framework. 1. The framework document does not exclude the use of proprietary (home-made) localpart ACE encoding per host basis, but this WG has no nameprep-like stringprep profile draft for localpart ACE encoding yet. Do It Yourself policy ? :-) If we need and call it "localprep", it'll be almost the exact copy of nameprep RFC with addition of expanded delimiters set and email-specific security considerations and suggestion of x?-- prefix. This encoding clearly has some limitations and may not be "MUST USE" for every host, but will help fast adoption of EAI for some parties, especially for major email portals who can accept the limitations. the nameprep with more delimiters(,=/_ etc) would be enough for most asian and european email users. So, I suggest we have a draft for a stringprep profile for localpart encoding in this WG. 2. current framework document has cautions about use of unauthenticated binding between Non-ASCII and alt-address, so more draft work is required to fight against alt-address spoofing attacks. Old JET members had a brief talk about this alt-address spoofing issue recently and i hope we could post a summary and suggestion here. Best Regards, Soobok Lee _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 17:09:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpu5T-0004v0-BW; Thu, 30 Nov 2006 17:08:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpu5R-0004un-Ok for ima@ietf.org; Thu, 30 Nov 2006 17:08:57 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpu5Q-0000G8-8V for ima@ietf.org; Thu, 30 Nov 2006 17:08:57 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 014BD2596C1; Thu, 30 Nov 2006 23:05:44 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03579-01; Thu, 30 Nov 2006 23:05:25 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A7C32596C2; Thu, 30 Nov 2006 23:05:24 +0100 (CET) Message-ID: <456F5662.2010403@alvestrand.no> Date: Thu, 30 Nov 2006 23:08:34 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Soobok Lee Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards References: <20061130164924.GA24636@ns5.lsb.org> In-Reply-To: <20061130164924.GA24636@ns5.lsb.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > Hi, All > > After looking into EAI drafts, I find this WG had been focusing on > 18n(utf8-ization) of all Email related RFC standards, > rather than defining ACE-encoding standard for non-ascii localpart. > I can guess and accept the reason behind the former approach, but > i still believe the latter approach has some merits and even co-exist > with the cureent EAI framework. > It is, however, not the approach this WG is chartered to follow, and discussion is therefore out of scope for this WG. I am sorry to be so blunt about it, but this group has work to do in finishing its approach, and spending resources exploring further a path that has been abandoned before the WG was chartered is not an efficient use of this WG's time. You are free to submit whatever drafts you want on your own, but they are not within the scope of this WG. Harald, speaking as chair. > 1. > The framework document does not exclude the use of > proprietary (home-made) localpart ACE encoding per host basis, but > this WG has no nameprep-like stringprep profile draft for localpart > ACE encoding yet. Do It Yourself policy ? :-) > > If we need and call it "localprep", it'll be almost the exact > copy of nameprep RFC with addition of expanded delimiters set and > email-specific security considerations and suggestion of x?-- prefix. > This encoding clearly has some limitations and may not be "MUST USE" > for every host, but will help fast adoption of EAI for some parties, > especially for major email portals who can accept the limitations. > the nameprep with more delimiters(,=/_ etc) would be enough for > most asian and european email users. > > So, I suggest we have a draft for a stringprep profile for localpart > encoding in this WG. > > 2. > current framework document has cautions about use of unauthenticated > binding between Non-ASCII and alt-address, so more draft work is > required to fight against alt-address spoofing attacks. > Old JET members had a brief talk about this alt-address spoofing issue > recently and i hope we could post a summary and suggestion here. > > Best Regards, > > Soobok Lee > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 20:18:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpx2R-0006lH-5W; Thu, 30 Nov 2006 20:18:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpx2P-0006kF-Tu for ima@ietf.org; Thu, 30 Nov 2006 20:18:01 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gpx2J-0002qK-AB for ima@ietf.org; Thu, 30 Nov 2006 20:18:01 -0500 Received: (snipe 28007 invoked by uid 0); 1 Dec 2006 10:18:23 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.127564 secs); Received: from unknown (HELO ?192.168.10.145?) (Z?G?own@210.107.249.23) by unknown with SMTP; 1 Dec 2006 10:18:23 +0900 X-RCPTTO: lsb@lsb.org, ima@ietf.org, yangwooko@gmail.com Message-ID: <456F827F.8070902@icu.ac.kr> Date: Fri, 01 Dec 2006 10:16:47 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Soobok Lee Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards References: <20061130164924.GA24636@ns5.lsb.org> In-Reply-To: <20061130164924.GA24636@ns5.lsb.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > > Hi, All > > After looking into EAI drafts, I find this WG had been focusing on > 18n(utf8-ization) of all Email related RFC standards, > rather than defining ACE-encoding standard for non-ascii localpart. > I can guess and accept the reason behind the former approach, but > i still believe the latter approach has some merits and even co-exist > with the cureent EAI framework. Please be careful about the current charter of EAI WG. It is clearly focused on "an" approach that is described in framework document. If you want to pursue other approach, you may need another WG. > 1. > The framework document does not exclude the use of > proprietary (home-made) localpart ACE encoding per host basis, but > this WG has no nameprep-like stringprep profile draft for localpart > ACE encoding yet. Do It Yourself policy ? :-) > > If we need and call it "localprep", it'll be almost the exact > copy of nameprep RFC with addition of expanded delimiters set and > email-specific security considerations and suggestion of x?-- prefix. > This encoding clearly has some limitations and may not be "MUST USE" > for every host, but will help fast adoption of EAI for some parties, > especially for major email portals who can accept the limitations. > the nameprep with more delimiters(,=/_ etc) would be enough for > most asian and european email users. > > So, I suggest we have a draft for a stringprep profile for localpart > encoding in this WG. Section 7 of framework document mentions a little bit about local(?)-prep. I am very glad if you come up with a draft for this. However, I am confused because you mentioned some-prep the local-prep "only" in the context of ACE. I think that the usefulness of local-prep is not necessarily coupled with the use of a specific encoding. > 2. > current framework document has cautions about use of unauthenticated > binding between Non-ASCII and alt-address, so more draft work is > required to fight against alt-address spoofing attacks. > Old JET members had a brief talk about this alt-address spoofing issue > recently and i hope we could post a summary and suggestion here. > > Best Regards, > > Soobok Lee > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 20:23:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpx7K-0000AH-QS; Thu, 30 Nov 2006 20:23:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpx7J-0000A9-PD for ima@ietf.org; Thu, 30 Nov 2006 20:23:05 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpx7I-0003X5-4f for ima@ietf.org; Thu, 30 Nov 2006 20:23:05 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB11MvLR031167; Fri, 1 Dec 2006 10:22:57 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB11Mvd3031166; Fri, 1 Dec 2006 10:22:57 +0900 Date: Fri, 1 Dec 2006 10:22:57 +0900 From: Soobok Lee To: Harald Alvestrand Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Message-ID: <20061201012257.GB24636@ns5.lsb.org> References: <20061130164924.GA24636@ns5.lsb.org> <456F5662.2010403@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456F5662.2010403@alvestrand.no> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Nov 30, 2006 at 11:08:34PM +0100, Harald Alvestrand wrote: > Soobok Lee wrote: > >Hi, All > > > >After looking into EAI drafts, I find this WG had been focusing on > > 18n(utf8-ization) of all Email related RFC standards, > > rather than defining ACE-encoding standard for non-ascii localpart. > > I can guess and accept the reason behind the former approach, but > > i still believe the latter approach has some merits and even co-exist > > with the cureent EAI framework. > > > It is, however, not the approach this WG is chartered to follow, and > discussion is therefore out of scope for this WG. I understand your concern as the chair. But, when alt-address parameter is not given by MUA or not available at all, downgrading MUA/MTA may favor some default ACE-encoding for localparts, over just bouncing back or rejecting. and if we agree that such default auto-converint ACE encoding is useful, this will support that ACE-encoding job falls within this WG scope. Moreover, current un-authenticated alt-address binding may cause some spoofing problem which has different nature than that of ascii-only email address, so default ace-encoding has some merits from security viewpoints. This is the second reason why i believe default ace encoding falls within this WG. Of course, such ACE-encoding may be used not only for downgrading but also for the early composing stage in MUA, but, this latter un-intended use of ACE encoding is out of scope of this WG. Soobok > > I am sorry to be so blunt about it, but this group has work to do in > finishing its approach, and spending resources exploring further a path > that has been abandoned before the WG was chartered is not an efficient > use of this WG's time. > > You are free to submit whatever drafts you want on your own, but they > are not within the scope of this WG. > > Harald, speaking as chair. > >1. > >The framework document does not exclude the use of > >proprietary (home-made) localpart ACE encoding per host basis, but > >this WG has no nameprep-like stringprep profile draft for localpart > >ACE encoding yet. Do It Yourself policy ? :-) > > > >If we need and call it "localprep", it'll be almost the exact > >copy of nameprep RFC with addition of expanded delimiters set and > >email-specific security considerations and suggestion of x?-- prefix. > >This encoding clearly has some limitations and may not be "MUST USE" > >for every host, but will help fast adoption of EAI for some parties, > >especially for major email portals who can accept the limitations. > >the nameprep with more delimiters(,=/_ etc) would be enough for > >most asian and european email users. > > > >So, I suggest we have a draft for a stringprep profile for localpart > >encoding in this WG. > > > >2. > >current framework document has cautions about use of unauthenticated > >binding between Non-ASCII and alt-address, so more draft work is > >required to fight against alt-address spoofing attacks. > >Old JET members had a brief talk about this alt-address spoofing issue > >recently and i hope we could post a summary and suggestion here. > > > >Best Regards, > > > >Soobok Lee > > > >_______________________________________________ > >IMA mailing list > >IMA@ietf.org > >https://www1.ietf.org/mailman/listinfo/ima > > > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 20:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxFS-0002Oj-4z; Thu, 30 Nov 2006 20:31:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxFR-0002OR-0b for ima@ietf.org; Thu, 30 Nov 2006 20:31:29 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpxFP-0004bl-D6 for ima@ietf.org; Thu, 30 Nov 2006 20:31:28 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB11VKLR000700; Fri, 1 Dec 2006 10:31:20 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB11VK0l000699; Fri, 1 Dec 2006 10:31:20 +0900 Date: Fri, 1 Dec 2006 10:31:20 +0900 From: Soobok Lee To: Yangwoo Ko Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Message-ID: <20061201013120.GC24636@ns5.lsb.org> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456F827F.8070902@icu.ac.kr> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Dec 01, 2006 at 10:16:47AM +0900, Yangwoo Ko wrote: > > Soobok Lee wrote: > > > >Hi, All > > > >After looking into EAI drafts, I find this WG had been focusing on > > 18n(utf8-ization) of all Email related RFC standards, > > rather than defining ACE-encoding standard for non-ascii localpart. > > I can guess and accept the reason behind the former approach, but > > i still believe the latter approach has some merits and even co-exist > > with the cureent EAI framework. > > Please be careful about the current charter of EAI WG. > It is clearly focused on "an" approach that is described > in framework document. If you want to pursue other approach, > you may need another WG. I understand, but the problem is on "time". :-) > > >1. > >The framework document does not exclude the use of > >proprietary (home-made) localpart ACE encoding per host basis, but > >this WG has no nameprep-like stringprep profile draft for localpart > >ACE encoding yet. Do It Yourself policy ? :-) > > > >If we need and call it "localprep", it'll be almost the exact > >copy of nameprep RFC with addition of expanded delimiters set and > >email-specific security considerations and suggestion of x?-- prefix. > >This encoding clearly has some limitations and may not be "MUST USE" > >for every host, but will help fast adoption of EAI for some parties, > >especially for major email portals who can accept the limitations. > >the nameprep with more delimiters(,=/_ etc) would be enough for > >most asian and european email users. > > > >So, I suggest we have a draft for a stringprep profile for localpart > >encoding in this WG. > > Section 7 of framework document mentions a little bit about > local(?)-prep. I am very glad if you come up with a draft for > this. I will try to look into this prep thing . thanks. > > However, I am confused because you mentioned some-prep the > local-prep "only" in the context of ACE. I think that the > usefulness of local-prep is not necessarily coupled with the > use of a specific encoding. I agree. Soobok > > >2. > >current framework document has cautions about use of unauthenticated > >binding between Non-ASCII and alt-address, so more draft work is > >required to fight against alt-address spoofing attacks. > >Old JET members had a brief talk about this alt-address spoofing issue > >recently and i hope we could post a summary and suggestion here. > > > >Best Regards, > > > >Soobok Lee > > > >_______________________________________________ > >IMA mailing list > >IMA@ietf.org > >https://www1.ietf.org/mailman/listinfo/ima > > > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 20:47:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxUm-0002hH-VR; Thu, 30 Nov 2006 20:47:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxUl-0002gL-DI for ima@ietf.org; Thu, 30 Nov 2006 20:47:19 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpxUi-0006fS-VE for ima@ietf.org; Thu, 30 Nov 2006 20:47:19 -0500 Received: (eyou send program); Fri, 01 Dec 2006 09:47:01 +0800 Message-ID: <364937621.08275@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Fri, 01 Dec 2006 09:47:01 +0800 Message-ID: <004701c714ea$bdbfb9b0$1206e29f@cnnicyao> From: "Yao Jiankang" To: "Soobok Lee" References: <20061130164924.GA24636@ns5.lsb.org><456F5662.2010403@alvestrand.no> <364936190.06051@cnnic.cn> Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Date: Fri, 1 Dec 2006 09:48:03 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1213633993==" Errors-To: ima-bounces@ietf.org --===============1213633993== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNvb2JvayBMZWUiIDxsc2JA bHNiLm9yZz4NClRvOiAiSGFyYWxkIEFsdmVzdHJhbmQiIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubz4N CkNjOiA8aW1hQGlldGYub3JnPg0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAwMSwgMjAwNiA5OjIy IEFNDQpTdWJqZWN0OiBSZTogW0VBSV0gaTE4biBvZiBsb2NhbHBhcnQgdmVyc3VzIGkxOG4gb2Yg ZW1haWwgUkZDIHN0YW5kYXJkcw0KDQoNCj4gT24gVGh1LCBOb3YgMzAsIDIwMDYgYXQgMTE6MDg6 MzRQTSArMDEwMCwgSGFyYWxkIEFsdmVzdHJhbmQgd3JvdGU6DQo+PiBTb29ib2sgTGVlIHdyb3Rl Og0KPj4gPkhpLCBBbGwNCj4+ID4NCj4+ID5BZnRlciBsb29raW5nIGludG8gRUFJIGRyYWZ0cywg SSBmaW5kIHRoaXMgV0cgaGFkIGJlZW4gZm9jdXNpbmcgb24NCj4+ID4gMThuKHV0ZjgtaXphdGlv bikgb2YgYWxsIEVtYWlsIHJlbGF0ZWQgUkZDIHN0YW5kYXJkcywgDQo+PiA+IHJhdGhlciB0aGFu ICBkZWZpbmluZyBBQ0UtZW5jb2Rpbmcgc3RhbmRhcmQgZm9yIG5vbi1hc2NpaSBsb2NhbHBhcnQu DQo+PiA+IEkgY2FuIGd1ZXNzIGFuZCBhY2NlcHQgdGhlIHJlYXNvbiBiZWhpbmQgdGhlIGZvcm1l ciBhcHByb2FjaCwgYnV0DQo+PiA+IGkgc3RpbGwgYmVsaWV2ZSB0aGUgbGF0dGVyIGFwcHJvYWNo IGhhcyBzb21lIG1lcml0cyBhbmQgZXZlbiBjby1leGlzdA0KPj4gPiB3aXRoIHRoZSBjdXJlZW50 IEVBSSBmcmFtZXdvcmsuDQo+PiA+ICANCj4+IEl0IGlzLCBob3dldmVyLCBub3QgdGhlIGFwcHJv YWNoIHRoaXMgV0cgaXMgY2hhcnRlcmVkIHRvIGZvbGxvdywgYW5kIA0KPj4gZGlzY3Vzc2lvbiBp cyB0aGVyZWZvcmUgb3V0IG9mIHNjb3BlIGZvciB0aGlzIFdHLg0KPiANCj4gSSB1bmRlcnN0YW5k IHlvdXIgY29uY2VybiBhcyB0aGUgY2hhaXIuDQo+IA0KPiBCdXQsIHdoZW4gYWx0LWFkZHJlc3Mg cGFyYW1ldGVyIGlzIG5vdCBnaXZlbiBieSBNVUEgb3Igbm90IGF2YWlsYWJsZSBhdCBhbGwsDQo+ IGRvd25ncmFkaW5nIE1VQS9NVEEgbWF5IGZhdm9yIHNvbWUgZGVmYXVsdCBBQ0UtZW5jb2Rpbmcg Zm9yIGxvY2FscGFydHMsDQo+IG92ZXIganVzdCBib3VuY2luZyBiYWNrIG9yIHJlamVjdGluZy4N Cg0Kb24gc3VjaCBvY2Nhc2lvbnMsICBib3VuY2luZyBiYWNrICBpcyBhIGdvb2QgY2hvaWNlLg0K QUNFLWVuY29kaW5nIG9uIHRoZSBsb2NhbCBwYXJ0cyB3aWxsIGNhdXNlIGEgbG90IG9mIHBvdGVu dGlhbCBwcm9ibGVtcywgd2hpY2ggaGFzIGJlZW4gZGlzY3Vzc2VkIGEgbG90IG9uIHRoaXMgbWFp bGluZyBsaXN0IGFuZCBtYW55IGRyYWZ0cy4NCkFDRS1lbmNvZGluZyBpcyB1Z2x5IHRvIHVzZXJz LiBpZiBzb21lIE1VQS9NVEEgaXMgc3VyZSB0aGF0IHNvbWUgVVRGLTggYWRkcmVzcyBjYW4gYmUg c2FmZWx5IHRyYW5zZm9ybWVkIGludG8gQUNFLWFkZHJlc3Mgd2l0aG91dCBsb3NpbmcgYW55IGlu Zm9ybWF0aW9uLA0KdGhlc2UgTVVBL01UQSBtYXkgc2VsZWN0IHRoZWlyIG93biB2ZXJzaW9uIG9m IEFDRS1hZGRyZXNzLg0KDQoNCj4gYW5kIGlmIHdlIGFncmVlIHRoYXQgc3VjaCBkZWZhdWx0IGF1 dG8tY29udmVyaW50IEFDRSBlbmNvZGluZyBpcyB1c2VmdWwsDQo+IHRoaXMgd2lsbCBzdXBwb3J0 IHRoYXQgQUNFLWVuY29kaW5nIGpvYiBmYWxscyB3aXRoaW4gdGhpcyBXRyBzY29wZS4NCg0KYXMg ZGlzY3Vzc2VkIGFib3ZlLCBkZWZhdWx0IGF1dG8tY29udmVyaW50IEFDRSBlbmNvZGluZyBoYXMg c29tZSBwcm9ibGVtcy4NCg0KPiANCj4gTW9yZW92ZXIsIGN1cnJlbnQgdW4tYXV0aGVudGljYXRl ZCBhbHQtYWRkcmVzcyBiaW5kaW5nIG1heSBjYXVzZSBzb21lIHNwb29maW5nDQo+IHByb2JsZW0g d2hpY2ggaGFzIGRpZmZlcmVudCBuYXR1cmUgdGhhbiB0aGF0IG9mIGFzY2lpLW9ubHkgZW1haWwg YWRkcmVzcywNCj4gc28gZGVmYXVsdCBhY2UtZW5jb2RpbmcgaGFzIHNvbWUgbWVyaXRzIGZyb20g c2VjdXJpdHkgdmlld3BvaW50cy4NCj4gVGhpcyBpcyB0aGUgc2Vjb25kIHJlYXNvbiB3aHkgaSBi ZWxpZXZlIGRlZmF1bHQgYWNlIGVuY29kaW5nIGZhbGxzIA0KPiB3aXRoaW4gdGhpcyBXRy4NCg0K Zm9yIGZ1dHVyZSBhbHQtYWRkcmVzcyBiaW5kaW5nLCB3ZSBtYXkgaGF2ZSBhIG9wZXJhdGlvbiBn dWlkZWxpbmUgdG8gcHJlc2NyaWJlIGhvdyB0byBiaW5kLiBidXQgaXQgaXMgbm90IG91ciBjdXJy ZW50IGRvY3VtZW50IHBsYW4uDQppdCBpcyBhbHNvIG5vdCBjb3JlIHByb3RvY29sIGlzc3VlLg0K DQoNCj4gDQo+IE9mIGNvdXJzZSwgc3VjaCBBQ0UtZW5jb2RpbmcgbWF5IGJlIHVzZWQgbm90IG9u bHkgZm9yIGRvd25ncmFkaW5nDQo+IGJ1dCBhbHNvIGZvciB0aGUgZWFybHkgY29tcG9zaW5nIHN0 YWdlIGluIE1VQSwgYnV0LCB0aGlzIGxhdHRlcg0KPiB1bi1pbnRlbmRlZCB1c2Ugb2YgQUNFIGVu Y29kaW5nIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIFdHLg0KDQphcyB5b3UgaGF2ZSB1bmRlcnN0 YW5kIGl0LCBFQUkgV0cgaXMgd29ya2luZyBvdXQgYSBzb2x1dGlvbiBiYXNlZCBvbiBTTVRQIGV4 dGVuc2lvbiBub3QgQUNFLg0KDQoNCllhbyBKaWFua2FuZw0KQ05OSUMNCg0KPiANCj4gU29vYm9r DQo+IA0KPj4gDQo+PiBJIGFtIHNvcnJ5IHRvIGJlIHNvIGJsdW50IGFib3V0IGl0LCBidXQgdGhp cyBncm91cCBoYXMgd29yayB0byBkbyBpbiANCj4+IGZpbmlzaGluZyBpdHMgYXBwcm9hY2gsIGFu ZCBzcGVuZGluZyByZXNvdXJjZXMgZXhwbG9yaW5nIGZ1cnRoZXIgYSBwYXRoIA0KPj4gdGhhdCBo YXMgYmVlbiBhYmFuZG9uZWQgYmVmb3JlIHRoZSBXRyB3YXMgY2hhcnRlcmVkIGlzIG5vdCBhbiBl ZmZpY2llbnQgDQo+PiB1c2Ugb2YgdGhpcyBXRydzIHRpbWUuDQo+PiANCj4+IFlvdSBhcmUgZnJl ZSB0byBzdWJtaXQgd2hhdGV2ZXIgZHJhZnRzIHlvdSB3YW50IG9uIHlvdXIgb3duLCBidXQgdGhl eSANCj4+IGFyZSBub3Qgd2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIFdHLg0KPj4gDQo+PiAgICAg ICAgICAgIEhhcmFsZCwgc3BlYWtpbmcgYXMgY2hhaXIuDQo+PiA+MS4gDQo+PiA+VGhlIGZyYW1l d29yayBkb2N1bWVudCBkb2VzIG5vdCBleGNsdWRlIHRoZSB1c2Ugb2YgDQo+PiA+cHJvcHJpZXRh cnkgKGhvbWUtbWFkZSkgbG9jYWxwYXJ0IEFDRSBlbmNvZGluZyBwZXIgaG9zdCBiYXNpcywgYnV0 DQo+PiA+dGhpcyBXRyBoYXMgbm8gbmFtZXByZXAtbGlrZSBzdHJpbmdwcmVwIHByb2ZpbGUgZHJh ZnQgZm9yIGxvY2FscGFydCANCj4+ID5BQ0UgZW5jb2RpbmcgeWV0LiBEbyBJdCBZb3Vyc2VsZiBw b2xpY3kgPyA6LSkgDQo+PiA+DQo+PiA+SWYgd2UgbmVlZCBhbmQgY2FsbCBpdCAibG9jYWxwcmVw IiwgaXQnbGwgYmUgYWxtb3N0IHRoZSBleGFjdA0KPj4gPmNvcHkgb2YgbmFtZXByZXAgUkZDIHdp dGggIGFkZGl0aW9uIG9mIGV4cGFuZGVkIGRlbGltaXRlcnMgc2V0IGFuZCANCj4+ID5lbWFpbC1z cGVjaWZpYyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgc3VnZ2VzdGlvbiBvZiB4Py0tIHBy ZWZpeC4NCj4+ID5UaGlzIGVuY29kaW5nIGNsZWFybHkgaGFzIHNvbWUgbGltaXRhdGlvbnMgYW5k IG1heSBub3QgYmUgIk1VU1QgVVNFIiANCj4+ID5mb3IgZXZlcnkgaG9zdCwgYnV0IHdpbGwgaGVs cCBmYXN0IGFkb3B0aW9uIG9mIEVBSSBmb3Igc29tZSBwYXJ0aWVzLCANCj4+ID5lc3BlY2lhbGx5 IGZvciBtYWpvciBlbWFpbCBwb3J0YWxzIHdobyBjYW4gYWNjZXB0IHRoZSBsaW1pdGF0aW9ucy4N Cj4+ID50aGUgbmFtZXByZXAgd2l0aCBtb3JlIGRlbGltaXRlcnMoLD0vXyBldGMpIHdvdWxkIGJl IGVub3VnaCBmb3INCj4+ID5tb3N0IGFzaWFuIGFuZCBldXJvcGVhbiBlbWFpbCB1c2Vycy4NCj4+ ID4NCj4+ID5TbywgSSBzdWdnZXN0IHdlIGhhdmUgYSBkcmFmdCBmb3IgYSBzdHJpbmdwcmVwIHBy b2ZpbGUgZm9yIGxvY2FscGFydCANCj4+ID5lbmNvZGluZyBpbiB0aGlzIFdHLg0KPj4gPg0KPj4g PjIuDQo+PiA+Y3VycmVudCBmcmFtZXdvcmsgZG9jdW1lbnQgaGFzIGNhdXRpb25zIGFib3V0IHVz ZSBvZiB1bmF1dGhlbnRpY2F0ZWQgDQo+PiA+YmluZGluZyBiZXR3ZWVuIE5vbi1BU0NJSSBhbmQg YWx0LWFkZHJlc3MsICBzbyBtb3JlIGRyYWZ0IHdvcmsgIGlzDQo+PiA+cmVxdWlyZWQgdG8gZmln aHQgYWdhaW5zdCBhbHQtYWRkcmVzcyBzcG9vZmluZyBhdHRhY2tzLg0KPj4gPk9sZCBKRVQgbWVt YmVycyBoYWQgYSBicmllZiB0YWxrIGFib3V0IHRoaXMgYWx0LWFkZHJlc3Mgc3Bvb2ZpbmcgaXNz dWUNCj4+ID5yZWNlbnRseSBhbmQgaSBob3BlIHdlIGNvdWxkIHBvc3QgYSBzdW1tYXJ5IGFuZCBz dWdnZXN0aW9uIGhlcmUuDQo+PiA+DQo+PiA+QmVzdCBSZWdhcmRzLA0KPj4gPg0KPj4gPlNvb2Jv ayBMZWUNCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gPklNQSBtYWlsaW5nIGxpc3QNCj4+ID5JTUFAaWV0Zi5vcmcNCj4+ID5odHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCj4+ID4NCj4+ID4gIA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1B IG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaW1h --===============1213633993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============1213633993==-- From ima-bounces@ietf.org Thu Nov 30 21:35:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpyFQ-0002ip-T2; Thu, 30 Nov 2006 21:35:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpyFP-0002YW-7q for ima@ietf.org; Thu, 30 Nov 2006 21:35:31 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpyFN-0008Fa-LM for ima@ietf.org; Thu, 30 Nov 2006 21:35:31 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB12ZLLR012158; Fri, 1 Dec 2006 11:35:21 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB12ZIJg012156; Fri, 1 Dec 2006 11:35:18 +0900 Date: Fri, 1 Dec 2006 11:35:18 +0900 From: Soobok Lee To: Yao Jiankang Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Message-ID: <20061201023518.GD24636@ns5.lsb.org> References: <364936190.06051@cnnic.cn> <004701c714ea$bdbfb9b0$1206e29f@cnnicyao> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004701c714ea$bdbfb9b0$1206e29f@cnnicyao> User-Agent: Mutt/1.4i X-Spam-Score: 0.6 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Dec 01, 2006 at 09:48:03AM +0800, Yao Jiankang wrote: > > > But, when alt-address parameter is not given by MUA or not available at all, > > downgrading MUA/MTA may favor some default ACE-encoding for localparts, > > over just bouncing back or rejecting. > > on such occasions, bouncing back is a good choice. > ACE-encoding on the local parts will cause a lot of potential problems, which has been discussed a lot on this mailing list and many drafts. > ACE-encoding is ugly to users. if some MUA/MTA is sure that some UTF-8 address can be safely transformed into ACE-address without losing any information, > these MUA/MTA may select their own version of ACE-address. As your [smtpext] section 2.5 stated, Some may prefer transformed the non-ASCII address to the ASCII Compatible Encoding(ACE) address as the value of the ALT-ADDRESS. The big problem with applying an ACE to all local-parts is that the sending or converting system doesn't know if there are some specific data or instructions embedded in the address that the ACE process would hide. Some SMTP servers may depend on these specific data or instructions to do some operations while the local parts applied with ACE will lose or hide these data or instructions. How about having some guideline to *ban* on embedding any data/instruction into the NON-ASCII localpart, since NON-ASCII lables are most for humans not for machines. They will use ASCII localpart for that purpose. No harm at all. moreover, ACE encoding for downgrading may be geared to have minimum loss of information. For interoperability, some default ace encoding is good for MUA/MTA. even if ACE-encoding has some "costs", bouncing back has some costs either. this is the summary of argument against ace autoconverting i found. 1) ACE encoded localpart looks ugly and causes confusion. EAI-capable would convert them back to NON-ASCII. In most cases, ugly form would not be seen from end users. 2) some MTA have length limits on local parts, utf8/ace encoding produce different lengths of localparts for one mailbox name. In extreme cases, site-specific length limit would be broken, in which case the site admin reject to register that ace lable perl case by case basis or by reject-all. 3) lose some characters when auto-converting Can be avoided as addresssed in the above. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 30 22:17:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpytZ-0001xV-K3; Thu, 30 Nov 2006 22:17:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpytZ-0001vd-35 for ima@ietf.org; Thu, 30 Nov 2006 22:17:01 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpytX-0001ww-58 for ima@ietf.org; Thu, 30 Nov 2006 22:17:01 -0500 Received: (eyou send program); Fri, 01 Dec 2006 11:16:33 +0800 Message-ID: <364942993.18459@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Fri, 01 Dec 2006 11:16:33 +0800 Message-ID: <010a01c714f7$3fcb6380$1206e29f@cnnicyao> From: "Yao Jiankang" To: "Soobok Lee" References: <364936190.06051@cnnic.cn> <004701c714ea$bdbfb9b0$1206e29f@cnnicyao> <364940517.17976@cnnic.cn> Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Date: Fri, 1 Dec 2006 11:17:36 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.8 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1547928541==" Errors-To: ima-bounces@ietf.org --===============1547928541== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNvb2JvayBMZWUiIDxsc2JA bHNiLm9yZz4NClRvOiAiWWFvIEppYW5rYW5nIiA8eWFvamtAY25uaWMuY24+DQpDYzogPGltYUBp ZXRmLm9yZz47ICJIYXJhbGQgQWx2ZXN0cmFuZCIgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPg0KU2Vu dDogRnJpZGF5LCBEZWNlbWJlciAwMSwgMjAwNiAxMDozNSBBTQ0KU3ViamVjdDogUmU6IFtFQUld IGkxOG4gb2YgbG9jYWxwYXJ0IHZlcnN1cyBpMThuIG9mIGVtYWlsIFJGQyBzdGFuZGFyZHMNCg0K DQo+IE9uIEZyaSwgRGVjIDAxLCAyMDA2IGF0IDA5OjQ4OjAzQU0gKzA4MDAsIFlhbyBKaWFua2Fu ZyB3cm90ZToNCj4+IA0KPj4gPiBCdXQsIHdoZW4gYWx0LWFkZHJlc3MgcGFyYW1ldGVyIGlzIG5v dCBnaXZlbiBieSBNVUEgb3Igbm90IGF2YWlsYWJsZSBhdCBhbGwsDQo+PiA+IGRvd25ncmFkaW5n IE1VQS9NVEEgbWF5IGZhdm9yIHNvbWUgZGVmYXVsdCBBQ0UtZW5jb2RpbmcgZm9yIGxvY2FscGFy dHMsDQo+PiA+IG92ZXIganVzdCBib3VuY2luZyBiYWNrIG9yIHJlamVjdGluZy4NCj4+IA0KPj4g b24gc3VjaCBvY2Nhc2lvbnMsICBib3VuY2luZyBiYWNrICBpcyBhIGdvb2QgY2hvaWNlLg0KPj4g QUNFLWVuY29kaW5nIG9uIHRoZSBsb2NhbCBwYXJ0cyB3aWxsIGNhdXNlIGEgbG90IG9mIHBvdGVu dGlhbCBwcm9ibGVtcywgd2hpY2ggaGFzIGJlZW4gZGlzY3Vzc2VkIGEgbG90IG9uIHRoaXMgbWFp bGluZyBsaXN0IGFuZCBtYW55IGRyYWZ0cy4NCj4+IEFDRS1lbmNvZGluZyBpcyB1Z2x5IHRvIHVz ZXJzLiBpZiBzb21lIE1VQS9NVEEgaXMgc3VyZSB0aGF0IHNvbWUgVVRGLTggYWRkcmVzcyBjYW4g YmUgc2FmZWx5IHRyYW5zZm9ybWVkIGludG8gQUNFLWFkZHJlc3Mgd2l0aG91dCBsb3NpbmcgYW55 IGluZm9ybWF0aW9uLA0KPj4gdGhlc2UgTVVBL01UQSBtYXkgc2VsZWN0IHRoZWlyIG93biB2ZXJz aW9uIG9mIEFDRS1hZGRyZXNzLg0KPiANCj4gDQo+IEFzIHlvdXIgW3NtdHBleHRdIHNlY3Rpb24g Mi41IHN0YXRlZCwgDQo+IDxxdW90ZT4NCj4gICBTb21lIG1heSBwcmVmZXIgdHJhbnNmb3JtZWQg dGhlIG5vbi1BU0NJSSBhZGRyZXNzIHRvIHRoZSBBU0NJSQ0KPiAgIENvbXBhdGlibGUgRW5jb2Rp bmcoQUNFKSBhZGRyZXNzIGFzIHRoZSB2YWx1ZSBvZiB0aGUgQUxULUFERFJFU1MuDQo+ICAgVGhl IGJpZyBwcm9ibGVtIHdpdGggYXBwbHlpbmcgYW4gQUNFIHRvIGFsbCBsb2NhbC1wYXJ0cyBpcyB0 aGF0IHRoZQ0KPiAgIHNlbmRpbmcgb3IgY29udmVydGluZyBzeXN0ZW0gZG9lc24ndCBrbm93IGlm IHRoZXJlIGFyZSBzb21lIHNwZWNpZmljDQo+ICAgZGF0YSBvciBpbnN0cnVjdGlvbnMgZW1iZWRk ZWQgaW4gdGhlIGFkZHJlc3MgdGhhdCB0aGUgQUNFIHByb2Nlc3MNCj4gICB3b3VsZCBoaWRlLiAg U29tZSBTTVRQIHNlcnZlcnMgbWF5IGRlcGVuZCBvbiB0aGVzZSBzcGVjaWZpYyBkYXRhIG9yDQo+ ICAgaW5zdHJ1Y3Rpb25zIHRvIGRvIHNvbWUgb3BlcmF0aW9ucyB3aGlsZSB0aGUgbG9jYWwgcGFy dHMgYXBwbGllZCB3aXRoDQo+ICAgQUNFIHdpbGwgbG9zZSBvciBoaWRlIHRoZXNlIGRhdGEgb3Ig aW5zdHJ1Y3Rpb25zLiANCj4gPC9xdW90ZT4NCj4gDQo+IEhvdyBhYm91dCBoYXZpbmcgc29tZSBn dWlkZWxpbmUgdG8gKmJhbiogb24gZW1iZWRkaW5nIGFueSBkYXRhL2luc3RydWN0aW9uDQo+IGlu dG8gdGhlIE5PTi1BU0NJSSBsb2NhbHBhcnQsIHNpbmNlICBOT04tQVNDSUkgbGFibGVzIGFyZSBt b3N0IGZvciBodW1hbnMNCj4gbm90IGZvciBtYWNoaW5lcy4gVGhleSB3aWxsIHVzZSBBU0NJSSBs b2NhbHBhcnQgZm9yIHRoYXQgcHVycG9zZS4gTm8gaGFybQ0KPiBhdCBhbGwuDQoNCnllcywgSSBh bHNvIGNvbnNpZGVyZWQgdGhpcyBpc3N1ZSBhYm91dCAqYmFuKiBvbiBlbWJlZGRpbmcgYW55IGRh dGEvaW5zdHJ1Y3Rpb24NCiBpbnRvIHRoZSBOT04tQVNDSUkgbG9jYWxwYXJ0IGJlZm9yZS4NCm9u IGFub3RoZXIgdGhvdWdodCwgKmJhbiIgd2lsbCBhbHNvIGNhdXNlIHNvbWUgcHJvYmxlbXMgYW5k IGhhcyBzb21lIGluY29udmVuaWVuY2UuDQpmb3IgZXhhbXBsZSwgSSBjYW4gdXNlIHN1Yi1hZGRy ZXNzIHN1Y2ggYXMgeWFvK2lldGZAb3JnYW5pemF0aW9uLmNvbSBiZWZvcmUgIEVBSSBwcm90b2Nv bCBpcyBwdWJsaXNoZWQuDQpidXQgSSBjYW4gbm90IHVzZSBzdWItYWRkcmVzcyBzdWNoIGFzIFtD aGluZXNlIENoYXJhY3RlciB5YW9dK2lldGZASUROIGFmdGVyICBFQUkgcHJvdG9jb2wgaXMgcHVi bGlzaGVkLg0KDQpzbyBhZnRlciBFQUkgcHJvdG9jb2xzIGFyZSBwdWJsaXNoZWQsIGl0IGlzIG5v dCBvdXIgZGVzaWduIGFpbSB0aGF0ICBzb21lIGVtYWlsIGFkZHJlc3MgZm9ybSB3aWxsIGJlIGRp cy1hbGxvd2VkLiANCg0KDQo+IA0KPiBtb3Jlb3ZlciwgQUNFIGVuY29kaW5nIGZvciBkb3duZ3Jh ZGluZyBtYXkgYmUgZ2VhcmVkIHRvIGhhdmUgbWluaW11bQ0KPiBsb3NzIG9mIGluZm9ybWF0aW9u LiBGb3IgaW50ZXJvcGVyYWJpbGl0eSwgc29tZSBkZWZhdWx0IGFjZSBlbmNvZGluZw0KPiBpcyBn b29kIGZvciBNVUEvTVRBLg0KDQpZZXMsIGFzIHlvdSBoYXZlIGFscmVhZHkgc2FpZCwgdGhlIEVB SSBXRyBoYXMgbm90IGV4Y2x1ZGUgc29tZSBNVUEvTVRBIHdoaWNoIG1heSB1c2UgaXRzIG93biB2 ZXJzaW9uIG9mICBBQ0UgZW5jb2RpbmcuDQoNCj4gDQo+IGV2ZW4gaWYgQUNFLWVuY29kaW5nIGhh cyBzb21lICJjb3N0cyIsIGJvdW5jaW5nIGJhY2sgaGFzIHNvbWUgY29zdHMgZWl0aGVyLg0KPiB0 aGlzIGlzIHRoZSBzdW1tYXJ5IG9mIGFyZ3VtZW50IGFnYWluc3QgYWNlIGF1dG9jb252ZXJ0aW5n IGkgZm91bmQuDQo+IA0KeWVzLCBib3RoIGhhcyBzb21lIGNvc3RzLiBzbyB3ZSBzZWxlY3QgdGhl IHNhZmUgb25lLg0KDQo+IDEpIEFDRSBlbmNvZGVkIGxvY2FscGFydCBsb29rcyB1Z2x5IGFuZCBj YXVzZXMgY29uZnVzaW9uLg0KPiAgIEVBSS1jYXBhYmxlIHdvdWxkIGNvbnZlcnQgdGhlbSBiYWNr IHRvIE5PTi1BU0NJSS4gSW4gbW9zdCBjYXNlcywgdWdseSBmb3JtDQo+ICAgIHdvdWxkIG5vdCBi ZSBzZWVuIGZyb20gZW5kIHVzZXJzLg0KDQpJIGFtIHN1cmUgdGhhdCBzb21lIE1VQSBvciBNVEEg d2lsbCBuZXZlciBiZSB1cGdyYWRlZCBpZiBBQ0UgaXMgdXNlZC4NCnRoZXNlIHVzZXJzIG9mIGVh aS1pbmNhcGFiaWxpdHkgTVVBL01UQSB3aWxsIGFsd2F5cyBzZWUgdGhlIGVtYWlsIGFkZHJlc3Mg c3VjaCBhcyB4bi0tYWRzZmdhc2dhZmdxZXJxd2VyYXNkZmlsYWRhQGV4YW1wbGUuY29tIGFuZCAg eG4tLWFkc2ZnYXNnYWZncWVycXdlcmFzZGZpaWFkYUBleGFtcGxlLmNvbSAuDQoNCnRoZXNlIDIg YWRkcmVzcyBhcmUgc2FtZT8NCg0KYWN0dWFsbHksIGl0IGlzIG5vdCBzYW1lLiBpdCBjYXVzZSBj b25mdXNpb24uDQoNCj4gDQo+IDIpIHNvbWUgTVRBIGhhdmUgbGVuZ3RoIGxpbWl0cyBvbiBsb2Nh bCBwYXJ0cywNCj4gICB1dGY4L2FjZSBlbmNvZGluZyBwcm9kdWNlIGRpZmZlcmVudCBsZW5ndGhz IG9mIGxvY2FscGFydHMgZm9yDQo+ICAgb25lIG1haWxib3ggbmFtZS4gSW4gZXh0cmVtZSBjYXNl cywgc2l0ZS1zcGVjaWZpYyBsZW5ndGggbGltaXQgd291bGQNCj4gICBiZSBicm9rZW4sIGluIHdo aWNoIGNhc2UgdGhlIHNpdGUgYWRtaW4gcmVqZWN0IHRvIHJlZ2lzdGVyIHRoYXQgDQo+ICAgYWNl IGxhYmxlIHBlcmwgY2FzZSBieSBjYXNlIGJhc2lzIG9yIGJ5IHJlamVjdC1hbGwuIA0KPiANCg0K YXMgeW91IHNhaWQgaXQsIHNvbWUgTVRBIGhhdmUgbGVuZ3RoIGxpbWl0cyBvbiBsb2NhbCBwYXJ0 cywgYnV0IHNvbWUgTVRBIGhhdmUgbm90IHN0cmljdCBsZW5ndGggbGltaXRzIG9uIGxvY2FsIHBh cnRzLg0KZm9yIGV4YW1wbGUsIE1UQSBBIHByZWZlciB0aGUgbGVuZ3RoIDMyIGNoYXJhY3RlcnMs IGJ1dCBNVEEgQiBwcmVmZXIgdGhlIGxlbmd0aCA2NCBjaGFyYWN0ZXJzLg0KDQpob3cgY29tbXVu aWN0aW9ucyBiZXR3ZWVuIEEgYW5kIEIgd2hlbiB0aGUgZW1haWwgYWRkcmVzcyBpbmNsdWRpbmcg NjQgY2hhcmFjdGVycyBmcm9tIEIgaXMgc2VudCB0byBBPw0KDQpTbyB3ZSBkbyBzb21lIGZyYWdt ZW50Pw0KDQo+IDMpIGxvc2Ugc29tZSBjaGFyYWN0ZXJzIHdoZW4gYXV0by1jb252ZXJ0aW5nDQo+ ICAgQ2FuIGJlIGF2b2lkZWQgYXMgYWRkcmVzc3NlZCBpbiB0aGUgYWJvdmUuDQoNCm1heSBsb3Nl IHNvbWUgaW5mb3JtYXRpb24sIHBscyBzZWUgYWJvdmUuDQoNCj4gDQo+IFNvb2Jvaw== --===============1547928541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============1547928541==-- From ima-bounces@ietf.org Thu Nov 30 23:30:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq02G-0007ir-A6; Thu, 30 Nov 2006 23:30:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq02F-0007ii-FM for ima@ietf.org; Thu, 30 Nov 2006 23:30:03 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq02D-00009g-QJ for ima@ietf.org; Thu, 30 Nov 2006 23:30:03 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB14TZLR029488; Fri, 1 Dec 2006 13:29:35 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB14TYMb029486; Fri, 1 Dec 2006 13:29:34 +0900 Date: Fri, 1 Dec 2006 13:29:34 +0900 From: Soobok Lee To: Yao Jiankang Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Message-ID: <20061201042934.GE24636@ns5.lsb.org> References: <364936190.06051@cnnic.cn> <004701c714ea$bdbfb9b0$1206e29f@cnnicyao> <364940517.17976@cnnic.cn> <010a01c714f7$3fcb6380$1206e29f@cnnicyao> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <010a01c714f7$3fcb6380$1206e29f@cnnicyao> User-Agent: Mutt/1.4i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns5.lsb.org id kB14TZLR029488 X-Spam-Score: 0.6 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Dec 01, 2006 at 11:17:36AM +0800, Yao Jiankang wrote: >=20 > ----- Original Message -----=20 > >=20 > > How about having some guideline to *ban* on embedding any data/instru= ction > > into the NON-ASCII localpart, since NON-ASCII lables are most for hu= mans > > not for machines. They will use ASCII localpart for that purpose. No = harm > > at all. >=20 > yes, I also considered this issue about *ban* on embedding any data/ins= truction > into the NON-ASCII localpart before. > on another thought, *ban" will also cause some problems and has some in= convenience. > for example, I can use sub-address such as yao+ietf@organization.com be= fore EAI protocol is published. > but I can not use sub-address such as [Chinese Character yao]+ietf@IDN = after EAI protocol is published. >=20 > so after EAI protocols are published, it is not our design aim that so= me email address form will be dis-allowed.=20 in your example, "+" can be added as a legal delimiter for localparts. /=3D= _! can be added as legal delimiters likewise. For my example, "[SOOBOK in UTF8].[LEE in UTF8]+eai_ietf@lsb.org can be a= utoconverted into "xn--sbsbsbs.xn--lelelele+eai_ietf@lsb.org. No loss of information. dot a= nd + and underbar was not lost. The receiving SMTP server parses it back to NONASCII in order to find dat= a/instruction for whitelisting filtering. Even the receiving server can work directly on xn--******+eai_ietf@lsb.org without NON-ASCII version if it is alrea= dy registered as an ascii *alias* for NON_ASCII in the server alias database. =20 Still I can find no problem at all. >=20 >=20 > >=20 > > moreover, ACE encoding for downgrading may be geared to have minimum > > loss of information. For interoperability, some default ace encoding > > is good for MUA/MTA. >=20 > Yes, as you have already said, the EAI WG has not exclude some MUA/MTA = which may use its own version of ACE encoding. Yes. it's better we have one default ace encoding rather than having noth= ing ,=20 even though it can not be perfect and has some costs. >=20 > >=20 > > even if ACE-encoding has some "costs", bouncing back has some costs e= ither. > > this is the summary of argument against ace autoconverting i found. > >=20 > yes, both has some costs. so we select the safe one. I believe ace encoding can be made safer by eliminating some problems ab= out converting problem. >=20 > > 1) ACE encoded localpart looks ugly and causes confusion. > > EAI-capable would convert them back to NON-ASCII. In most cases, ug= ly form > > would not be seen from end users. >=20 > I am sure that some MUA or MTA will never be upgraded if ACE is used. MUA will be upgraded easily since their market is occupied by a few big venders (MS,Mozilla,Opera,Eudora etc). To pursuade them to adopt EAI protocols early, protocols should be made s= imple=20 and efficient as possible, and provide some easy transition path to final full-blown utf8 protocol s= ets.=20 ACE for downgrading will do the job in the road, i believe. Without ace encoding, industry-wide EAI adoption will be very slow. > these users of eai-incapability MUA/MTA will always see the email addre= ss such as xn--adsfgasgafgqerqwerasdfilada@example.com and xn--adsfgasga= fgqerqwerasdfiiada@example.com . Yes. many end users give up chechking the diffference. and this is the va= lid security problem. but, IDNA and even the ASCII mboxname/domain name has the same problem, l= ike sooboklee@hanmail.net vs soobok1ee@hanmail.net. IDN labels/NON-ASCII localpart can contain the exact-same-looking charact= ers. Slash-like chars are on unicode special char section/CJK section/Japanese= section etc. >=20 > these 2 address are same? >=20 > actually, it is not same. it cause confusion. >=20 > >=20 > > 2) some MTA have length limits on local parts, > > utf8/ace encoding produce different lengths of localparts for > > one mailbox name. In extreme cases, site-specific length limit woul= d > > be broken, in which case the site admin reject to register that=20 > > ace lable perl case by case basis or by reject-all.=20 > >=20 >=20 > as you said it, some MTA have length limits on local parts, but some MT= A have not strict length limits on local parts. > for example, MTA A prefer the length 32 characters, but MTA B prefer th= e length 64 characters. Most CJK names falls between 2~5 unicode chars. The length of xn--ewqeqwe= wqqw will be 4+10~12. so, in most cases ace encoded localpart won't exceed 30 chars. =EC=97=90=EB=B2=A0=EB=A0=88=EC=8A=A4=ED=8A=B8.com (5 unicode char mt. Eve= rest in korean).com =3D=3D> XN--OM2B17FB6FZRDD5V.COM (19 chars).com For ace label to exceed 30 chars, 8 unicode chars is needed , i guess. >=20 > how communictions between A and B when the email address including 64 c= haracters from B is sent to A? >=20 > So we do some fragment? Just bounce at this time. It will be rare. the cost is minimum. >=20 > > 3) lose some characters when auto-converting > > Can be avoided as addresssed in the above. >=20 > may lose some information, pls see above. + may can be a legal delimiter for localpart as it had been so far in ascii world. Soobok Lee >=20 > >=20 > > Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima