Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA13408 for ietf-822-bks; Fri, 26 May 2000 13:19:45 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA13404 for ; Fri, 26 May 2000 13:19:44 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 26 May 2000 13:06:31 -0700 (Pacific Daylight Time) Received: from dino.platinum.corp.microsoft.com ([172.30.236.62]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 26 May 2000 13:06:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4378.0 content-class: urn:content-classes:message Subject: RE: Correct display of "To:" value MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC739.75C8C206" Date: Fri, 26 May 2000 10:40:19 -0700 Message-ID: <15E1974078862B46A05D49AEC15B2AB801D53C@dino.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correct display of "To:" value Thread-Index: Ab/HDpujly+u3E4sR+2C46YTw3+iuwAKb93w From: "Jeff Stephenson" To: "Harald Alvestrand" , "Jacob Palme" , Cc: "Andreas Pfneisl" X-OriginalArrivalTime: 26 May 2000 20:06:57.0968 (UTC) FILETIME=[F235BB00:01BFC74D] Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFC739.75C8C206 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Harald Alvestrand [mailto:Harald@Alvestrand.no] > Sent: Thursday, May 25, 2000 10:40 PM > > ... > > Outlook is not able to display the headers as they are received. Actually Outlook _can_ display the RFC822 headers, though it is, I admit, not immediately obvious how to do so. From the menubar on the open message, select View | Options. The headers of any message that was received via SMTP will be displayed in the dialog. I asked Andreas to send me the headers from his message; the human-friendly name has indeed been stripped in the version that he received. I suggested that he compare the Received: lines between the message that he received and the message of the other recipient that did see the human-friendly name to perhaps figure out which server stripped the name. -- jeff ------_=_NextPart_001_01BFC739.75C8C206 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct display of "To:" value

> -----Original Message-----
> From: Harald Alvestrand [mailto:Harald@Alvestrand.no]
> Sent: Thursday, May 25, 2000 10:40 PM
>
> ...
>
> Outlook is not able to display the headers as = they are received.

Actually Outlook _can_ display the RFC822 headers, = though it is, I admit, not immediately obvious how to do so. From = the menubar on the open message, select View | Options. The = headers of any message that was received via SMTP will be displayed in = the dialog.

I asked Andreas to send me the headers from his = message; the human-friendly name has indeed been stripped in the version = that he received. I suggested that he compare the Received: lines = between the message that he received and the message of the other = recipient that did see the human-friendly name to perhaps figure out = which server stripped the name.

-- jeff

------_=_NextPart_001_01BFC739.75C8C206-- Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09599 for ietf-822-bks; Fri, 26 May 2000 09:43:35 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09594 for ; Fri, 26 May 2000 09:43:34 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA00497; Fri, 26 May 2000 12:49:40 -0400 (EDT) Message-Id: <200005261649.MAA00497@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@innosoft.com cc: Keith Moore , Dan Kohn , iesg@ietf.org, gregv@ieee.org, ietf-822@imc.org Subject: Re: Last Call: SMTP Service Extensions for Transmission of Large and Binary MIME Messages to Proposed Standard In-reply-to: Your message of "Fri, 26 May 2000 08:25:14 -0800." <01JPUM4BD6SY00004J@mauve.mrochek.com> Date: Fri, 26 May 2000 12:49:40 -0400 Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The only case I can see for this being as nonobvious and people seem to > think is that the requirements, although clearly stated, are scattered > throughout a set of very large documents. If that's the problem then the way > to fix it is to have a separate document that collects all of this stuff > and explains how to do these various sorts of transcodings. And hiding > that in the BINARYMIME specification isn't markedly more useful than > hiding it in the MIME specification itself. if there are lots of details not already documented in published RFCs, I agree that another document would be better. but I do think it would be desirable to include a very brief discussion of transcoding issues with references to published material, because folks who implement BINARYMIME are likely to need to be concerned with those issues. Keith Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09430 for ietf-822-bks; Fri, 26 May 2000 09:29:49 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09426 for ; Fri, 26 May 2000 09:29:47 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA00246; Fri, 26 May 2000 12:36:59 -0400 (EDT) Message-Id: <200005261636.MAA00246@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@innosoft.com cc: Keith Moore , Dan Kohn , iesg@ietf.org, gregv@ieee.org, ietf-822@imc.org Subject: Re: Last Call: SMTP Service Extensions for Transmission of Large and Binary MIME Messages to Proposed Standard In-reply-to: Your message of "Fri, 26 May 2000 08:25:14 -0800." <01JPUM4BD6SY00004J@mauve.mrochek.com> Date: Fri, 26 May 2000 12:36:59 -0400 Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I do note, however, > that the 8bitMIME transcoding experience has been remarkably free of > broken implementations; while there are lots of problems with MIME > coding out there I don't think I've ever traced one back to a transcoder. I recall some early problems with such transcoding, but the bugs that I saw were flushed out fairly quickly. Keith Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA08344 for ietf-822-bks; Fri, 26 May 2000 08:47:34 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08339 for ; Fri, 26 May 2000 08:47:32 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JPUKP5E7CW00004J@mauve.mrochek.com> for ietf-822@imc.org; Fri, 26 May 2000 08:54:39 -0800 (PST) Date: Fri, 26 May 2000 08:25:14 -0800 (PST) Subject: Re: Last Call: SMTP Service Extensions for Transmission of Large and Binary MIME Messages to Proposed Standard In-reply-to: "Your message dated Fri, 26 May 2000 10:09:49 -0400" <200005261409.KAA28121@astro.cs.utk.edu> To: Keith Moore Cc: Dan Kohn , iesg@ietf.org, gregv@ieee.org, ietf-822@imc.org Message-id: <01JPUM4BD6SY00004J@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii References: <25D0C66E6D25D311B2AC0008C7913EE0B26F8A@tdmail2.teledesic.com> Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > This is a useful protocol and I support it moving to Proposed Standard. > > However, I would suggest adding text covering two boundary conditions. I do > > not believe these changes are large enough to require a new Last Call. > > > > First, I would add text stating that this extension IS suitable for use on > > the Submission port, as described in Section 7 of RFC 2476. This is > > requested by RFC 2476 for all new SMTP Service Extensions. > I concur. It's important that messages intended to be transmitted > as BINARYMIME be submitted as BINARYMIME. > > Second (and less important), I would state that although CR and LF do not > > represent line endings in BDAT chunks, the RFC 2781 prohibition against > > using a UTF-16 charset within the text top-level media type remains. This > > is because a gateway transformation of such a text object from BinaryMIME to > > 7bit or 8bit MIME would result in an improperly formatted MIME object that > > could cause many existing mailers to fail. > Not that I disagree with the 2781 prohibition, but I think it has more to > do with the content-transfer-encoding than the text/* media type. A > UTF-16 object encoded as base64 works just fine regardless of media type, > but a UTF-16 object encoded as 7bit or 8bit will fail regardless of > media type. Actually, you are both correct. Both the media type text/* and the 7bit and 8bit encodings prohibit UTF-16 content. That is, you aren't allowed to use UTF-16 with text/plain even if you use base64 or binary encoding. This is explicit and intentional. This requirement arises from the need to be able to switch from one encoding to another without incident, not directly from the 7bit and 8bit encodings themselves. But regardless of origin, the requirement is there for both things. And I see no harm with reiterating this requirement here. But if it is done both halves need to be reiterated. > The problem with text/*, I suppose, is that a MTA converting the > message might decide that if an object originally encoded in > base64 or binary is labelled as text/*, one of { 7bit, 8bit or > quoted-printable } is an appropriate encoding for the converted > object. It is required that such transcoding be possible. But it is less from the need to be able to trancode and spit out text/plain; charset=utf-16, CTE 8bit on the wire than from a need to transcode and be able to put something into a file that applications can deal with. That is, the restrictions on 8bit are mostly for backwards compatibility. > (actually quoted-printable is okay as long as > it never contains "hard line breaks", but an encoder that assumes > that the input is text will probably generate hard line breaks for > CR LF sequences in the input.) I prefer to see it as a simple requirement: In text/* CR and LF have to be represented as 13 and 10 and nulls are prohibited. See RFC 2046, section 4.1.1. Worrying about why this is so is academically interesting but not especially relevant to implementations. We can spend lots of time discussing why a given requirement is there, but at the end of the day the important point is that it is there and you need to follow it. > all of which illustrates (along with my earlier comment to iesg) that > re-encoding of MIME messages is subtle and has a number of pitfalls. Well, it ain't all that subtle. The rules are quite clear; the pitfalls the direct result of flagrant violations of the rules. You don't need to know the whys; if you just follow the rules you should be OK. > > If the second point is considered obvious, feel free to leave it out. > > However, HTTP/1.1 is exempted from this restriction in section 19.4.2 of RFC > > 2616, and one argument for that exemption is that HTTP is a binary-safe > > transport. > this isn't (intended to be) quite the same thing as you are saying. > 2616 is meant to allow text/* parts that normally use CRLF for > line endings to use either bare CR or bare LF instead when they > are transmitted in HTTP. but it doesn't (is not intended to) allow > the definition of new text parts that don't use CRLF as line endings. Correct; if you want to use UTF-16 with, say, HTML, you are supposed to use application/html, not text/html. Even in HTTP, although it is weakened to a SHOULD not a MUST. > > There will clearly be much more gatewaying between BinaryMIME > > MTAs and non-binary capable ones than from HTTP servers to non-binary > > capable MTAs, so I believe that this (existing) restriction should be > > reiterated. > not sure where it will fit in the document, but a discussion of > re-encoding subtleties, including a reference to RFC 2781, does > seem appropriate. The only case I can see for this being as nonobvious and people seem to think is that the requirements, although clearly stated, are scattered throughout a set of very large documents. If that's the problem then the way to fix it is to have a separate document that collects all of this stuff and explains how to do these various sorts of transcodings. And hiding that in the BINARYMIME specification isn't markedly more useful than hiding it in the MIME specification itself. Somewhere I have the text that originally was to be in the 8bitMIME document that explained how to transcode (the working group forced me to remove it); I suppose I could resurrect it if need be. I do note, however, that the 8bitMIME transcoding experience has been remarkably free of broken implementations; while there are lots of problems with MIME coding out there I don't think I've ever traced one back to a transcoder. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id HAA06127 for ietf-822-bks; Fri, 26 May 2000 07:02:55 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06123 for ; Fri, 26 May 2000 07:02:54 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA28121; Fri, 26 May 2000 10:09:50 -0400 (EDT) Message-Id: <200005261409.KAA28121@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dan Kohn cc: iesg@ietf.org, gregv@ieee.org, ietf-822@imc.org Subject: Re: Last Call: SMTP Service Extensions for Transmission of Large and Binary MIME Messages to Proposed Standard In-reply-to: Your message of "Thu, 25 May 2000 16:36:25 PDT." <25D0C66E6D25D311B2AC0008C7913EE0B26F8A@tdmail2.teledesic.com> Date: Fri, 26 May 2000 10:09:49 -0400 Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > This is a useful protocol and I support it moving to Proposed Standard. > However, I would suggest adding text covering two boundary conditions. I do > not believe these changes are large enough to require a new Last Call. > > First, I would add text stating that this extension IS suitable for use on > the Submission port, as described in Section 7 of RFC 2476. This is > requested by RFC 2476 for all new SMTP Service Extensions. I concur. It's important that messages intended to be transmitted as BINARYMIME be submitted as BINARYMIME. > Second (and less important), I would state that although CR and LF do not > represent line endings in BDAT chunks, the RFC 2781 prohibition against > using a UTF-16 charset within the text top-level media type remains. This > is because a gateway transformation of such a text object from BinaryMIME to > 7bit or 8bit MIME would result in an improperly formatted MIME object that > could cause many existing mailers to fail. Not that I disagree with the 2781 prohibition, but I think it has more to do with the content-transfer-encoding than the text/* media type. A UTF-16 object encoded as base64 works just fine regardless of media type, but a UTF-16 object encoded as 7bit or 8bit will fail regardless of media type. The problem with text/*, I suppose, is that a MTA converting the message might decide that if an object originally encoded in base64 or binary is labelled as text/*, one of { 7bit, 8bit or quoted-printable } is an appropriate encoding for the converted object. (actually quoted-printable is okay as long as it never contains "hard line breaks", but an encoder that assumes that the input is text will probably generate hard line breaks for CR LF sequences in the input.) all of which illustrates (along with my earlier comment to iesg) that re-encoding of MIME messages is subtle and has a number of pitfalls. > If the second point is considered obvious, feel free to leave it out. > However, HTTP/1.1 is exempted from this restriction in section 19.4.2 of RFC > 2616, and one argument for that exemption is that HTTP is a binary-safe > transport. this isn't (intended to be) quite the same thing as you are saying. 2616 is meant to allow text/* parts that normally use CRLF for line endings to use either bare CR or bare LF instead when they are transmitted in HTTP. but it doesn't (is not intended to) allow the definition of new text parts that don't use CRLF as line endings. > There will clearly be much more gatewaying between BinaryMIME > MTAs and non-binary capable ones than from HTTP servers to non-binary > capable MTAs, so I believe that this (existing) restriction should be > reiterated. not sure where it will fit in the document, but a discussion of re-encoding subtleties, including a reference to RFC 2781, does seem appropriate. Keith Received: by ns.secondary.com (8.9.3/8.9.3) id FAA29745 for ietf-822-bks; Fri, 26 May 2000 05:20:53 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA29735 for ; Fri, 26 May 2000 05:20:51 -0700 (PDT) Received: from langfjella.maxware.no (langfjella.maxware.no [10.128.1.123]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id OAA00589; Fri, 26 May 2000 14:27:59 +0200 Message-Id: <4.3.1.2.20000526073736.04ecc9f0@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 26 May 2000 07:39:39 +0200 To: "Jacob Palme" , ietf-822@imc.org From: Harald Alvestrand Subject: Re: Correct display of "To:" value Cc: "Andreas Pfneisl" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:16 25.05.2000 +0200, Jacob Palme wrote: >I got an email from an email user, complaining that MS >Outlook 2000 shows the name of the sender in possibly >incorrect way. He wrote (I have not checked myself) that he >got the same mail header displayed in the following two >ways by MS Outlook 2000 and Netscape 4.6: > > > The header received by MS Outlook 2000 looks like this: > > > > From: Andreas.Pfneisl@reflex.at (Andreas.Pfneisl@reflex.at) Outlook Express or Outlook? the common Outlook (non-Express) format would be "Andreas.Pfneisl@reflex.at" underlined as a hyperlink that you cold click on to get the address book entry; if the address book entry existed, only the entry name would show. Also, the addresses are separated by semicolons for your enjoyment. Outlook is not able to display the headers as they are received. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no Received: by ns.secondary.com (8.9.3/8.9.3) id QAA21936 for ietf-822-bks; Thu, 25 May 2000 16:42:33 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21932 for ; Thu, 25 May 2000 16:42:31 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 May 2000 16:45:18 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE0B26F8A@tdmail2.teledesic.com> From: Dan Kohn To: iesg@ietf.org, gregv@ieee.org Cc: ietf-822@imc.org Subject: RE: Last Call: SMTP Service Extensions for Transmission of Large and Binary MIME Messages to Proposed Standard Date: Thu, 25 May 2000 16:36:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a useful protocol and I support it moving to Proposed Standard. However, I would suggest adding text covering two boundary conditions. I do not believe these changes are large enough to require a new Last Call. First, I would add text stating that this extension IS suitable for use on the Submission port, as described in Section 7 of RFC 2476. This is requested by RFC 2476 for all new SMTP Service Extensions. Second (and less important), I would state that although CR and LF do not represent line endings in BDAT chunks, the RFC 2781 prohibition against using a UTF-16 charset within the text top-level media type remains. This is because a gateway transformation of such a text object from BinaryMIME to 7bit or 8bit MIME would result in an improperly formatted MIME object that could cause many existing mailers to fail. If the second point is considered obvious, feel free to leave it out. However, HTTP/1.1 is exempted from this restriction in section 19.4.2 of RFC 2616, and one argument for that exemption is that HTTP is a binary-safe transport. There will clearly be much more gatewaying between BinaryMIME MTAs and non-binary capable ones than from HTTP servers to non-binary capable MTAs, so I believe that this (existing) restriction should be reiterated. Thanks. - dan -- Daniel Kohn tel:+1-425-602-6222 http://www.dankohn.com -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Thursday, 2000-05-25 10:25 Cc: gregv@ieee.org Subject: Last Call: SMTP Service Extensions for Transmission of Large and Binary MIME Messages to Proposed Standard The IESG has received a request to consider SMTP Service Extensions for Transmission of Large and Binary MIME Messages as a Proposed Standard. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 25, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-vaudreuil-esmtp-binary2-00.txt Received: by ns.secondary.com (8.9.3/8.9.3) id HAA11105 for ietf-822-bks; Thu, 25 May 2000 07:52:52 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11101 for ; Thu, 25 May 2000 07:52:51 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA22360; Thu, 25 May 2000 11:00:03 -0400 (EDT) Message-Id: <200005251500.LAA22360@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jacob Palme cc: ietf-822@imc.org, "Andreas Pfneisl" Subject: Re: Correct display of "To:" value In-reply-to: Your message of "Thu, 25 May 2000 10:16:58 +0200." Date: Thu, 25 May 2000 11:00:03 -0400 Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: RFC 822 doesn't specify how headers are to be displayed, it only specifies how they are to be sent on the wire. However, from a purely stylistic point-of-view: > The header received by MS Outlook 2000 looks like this: > > From: Andreas.Pfneisl@reflex.at (Andreas.Pfneisl@reflex.at) this is brain damaged and missing information - in this case, the "phrase" containing the human friendly name of the author. (it is just a coincidence that his name is embedded in the address). > The header received by Netscape Communicator 4.6 looks like this: > > From: "Andreas Pfneisl" this is much better. it's of course possible that in the first case the information was stripped by some gateway or dysfunctional interface. before it got to the user agent. such gateways should be avoided whenever possible, as they almost invariably lead to a loss of valuable information. Keith Received: by ns.secondary.com (8.9.3/8.9.3) id CAA25805 for ietf-822-bks; Thu, 25 May 2000 02:25:52 -0700 (PDT) Received: from badis.pdc.kth.se (IDENT:root@badis.pdc.kth.se [130.237.221.45]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA25800 for ; Thu, 25 May 2000 02:25:50 -0700 (PDT) Received: (from jas@localhost) by badis.pdc.kth.se (8.10.0/8.10.0) id e4P9X7b13163; Thu, 25 May 2000 11:33:07 +0200 To: Jacob Palme Cc: ietf-822@imc.org, "Andreas Pfneisl" Subject: Re: Correct display of "To:" value References: In-Reply-To: Jacob Palme's message of "Thu, 25 May 2000 10:16:58 +0200" From: Simon Josefsson Date: 25 May 2000 11:33:06 +0200 Message-ID: Lines: 29 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jacob Palme writes: > I got an email from an email user, complaining that MS > Outlook 2000 shows the name of the sender in possibly > incorrect way. He wrote (I have not checked myself) that he > got the same mail header displayed in the following two > ways by MS Outlook 2000 and Netscape 4.6: > > > The header received by MS Outlook 2000 looks like this: > > > > From: Andreas.Pfneisl@reflex.at (Andreas.Pfneisl@reflex.at) > > > > The header received by Netscape Communicator 4.6 looks like this: > > > > From: "Andreas Pfneisl" "Received" or "displayed"? If they received different headers, that would probably be ok (investigate why that occured? Gateways etc). If the programs displayed the same header (which one?) in those two formats, I guess the conversion algorithm(s) used might destroy information for the user. > Any comment on these two formats? Both look fine to me, the first is mailbox (addr-spec + comment) and the other mailbox (phrase route-addr). Or did I missunderstand your question? Received: by ns.secondary.com (8.9.3/8.9.3) id BAA24700 for ietf-822-bks; Thu, 25 May 2000 01:42:33 -0700 (PDT) Received: from unni.dsv.su.se (unni.dsv.su.se [130.237.161.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA24695 for ; Thu, 25 May 2000 01:42:31 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by unni.dsv.su.se (8.9.3+Sun/8.9.3) with ESMTP id KAA22916; Thu, 25 May 2000 10:49:43 +0200 (MET DST) Mime-Version: 1.0 Message-Id: Date: Thu, 25 May 2000 10:16:58 +0200 To: ietf-822@imc.org From: Jacob Palme Subject: Correct display of "To:" value Cc: "Andreas Pfneisl" Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I got an email from an email user, complaining that MS Outlook 2000 shows the name of the sender in possibly incorrect way. He wrote (I have not checked myself) that he got the same mail header displayed in the following two ways by MS Outlook 2000 and Netscape 4.6: > The header received by MS Outlook 2000 looks like this: > > From: Andreas.Pfneisl@reflex.at (Andreas.Pfneisl@reflex.at) > > The header received by Netscape Communicator 4.6 looks like this: > > From: "Andreas Pfneisl" Any comment on these two formats? -- Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/jpalme/ Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18181 for ietf-822-bks; Tue, 16 May 2000 09:58:41 -0700 (PDT) Received: from prserv.net (out2.prserv.net [32.97.166.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18177 for ; Tue, 16 May 2000 09:58:31 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.39]) by prserv.net (out2) with SMTP id <2000051617043422900cd00de>; Tue, 16 May 2000 17:04:36 +0000 To: w3c-xml-plenary@w3.org, w3c-i18n-ig@w3.org, xml-dev@lists.oasis-open.org, ietf-822@imc.org, ietf-types@iana.org Subject: Fw: Announcement of yet another I-D for XML media types X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_May_17_02:05:30_2000_955)--" Content-Transfer-Encoding: 7bit Message-Id: <20000517020533F.muraw3c@attglobal.net> Date: Wed, 17 May 2000 02:05:33 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 67 Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----Next_Part(Wed_May_17_02:05:30_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Colleagues, A new Internet Draft for XML media types has been released. Please discuss about it at the ietf-xml-mime mailing list. You can join this mailing list and read its arcive at: http://www.imc.org/ietf-xml-mime/ Sincerely yours, MURATA Makoto (FAMILY Given) ----Next_Part(Wed_May_17_02:05:30_2000_955)-- Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Received: from ns.secondary.com [208.184.76.39] by in5.prserv.net id 958495754.117540-1 ; Tue, 16 May 2000 16:49:14 +0000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17755 for ietf-xml-mime-bks; Tue, 16 May 2000 09:39:08 -0700 (PDT) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17751 for ; Tue, 16 May 2000 09:39:07 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.39]) by prserv.net (out1) with SMTP id <20000516164512252012p229e>; Tue, 16 May 2000 16:45:12 +0000 To: ietf-xml-mime@imc.org Subject: Announcement of yet another I-D for XML media types X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000517014611A.muraw3c@attglobal.net> Date: Wed, 17 May 2000 01:46:11 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan, Simon, and I created yet another I-D for XML media types. It is available at: http://www.ietf.org/internet-drafts/draft-murata-xml-04.txt The biggest change is the suffix. It is "+xml" rather than "|xml". Miles Sabin pointed out that "|" is missing in some variations of EBCDIC. We thus believe "|" is inappropriate. We believe that the mojority of this ML prefer "+" to "-". In reply to Rick Jelliffee, we added arguments against the charset parameter of application/xml. We have also made it clear that users are not forced to read and write %HH. We are looking forward to your feedbacks. MURATA Makoto ----Next_Part(Wed_May_17_02:05:30_2000_955)---- Received: by ns.secondary.com (8.9.3/8.9.3) id IAA21094 for ietf-822-bks; Tue, 9 May 2000 08:38:48 -0700 (PDT) Received: from prserv.net (out2.prserv.net [32.97.166.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21090 for ; Tue, 9 May 2000 08:38:47 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.124]) by prserv.net (out2) with SMTP id <2000050915441922901huk6ke>; Tue, 9 May 2000 15:44:19 +0000 To: ietf-822@imc.org Subject: FYI: Announcement of a new I-D for XML media types X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000510004429V.muraw3c@attglobal.net> Date: Wed, 10 May 2000 00:44:29 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 46 Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Colleagues, A new Internet Draft for XML media types has been released. Please discuss about it at the ietf-xml-mime mailing list. You can join this mailing list and read its arcive at: http://www.imc.org/ietf-xml-mime/ Sincerely yours, MURATA Makoto (FAMILY Given) ----------------------------------------------------------------- Simon St. Laurent, Dan Kohn, and I create a new I-D for XML media types. It is available at: http://www.ietf.org/internet-drafts/draft-murata-xml-03.txt Major differences from previous versions are as below: 1. Fragment identifiers for text/xml and application/xml are escaped XPointers (section 6). This addition was requested by the XML Core WG of W3C. 2. The base URI may be embedded in text/xml, application/xml, text/xml-external-parsed-entity, or application/xml-external-parsed-entity (section 7). Again, this addition was requested by the XML Core WG of W3C. 3. utf-16le and utf-16be are mentioned (sections 5 and 9). Since RFC 2781 (UTF-16, an encoding of ISO 10646) introduce these two charsets, they have to be mentioned. 4. appendix comparing alternatives to '|xml' suffix added. The suffix is changed from "-xml" to "|xml". As of now, no media types ending with "-xml" are registered yet. 5. The security section is expanded on the basis of David Megginson's presentation to XTech 2000. 6. Lots of minor editing. We are looking forward to your feedbacks. MURATA Makoto Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA16605 for ietf-822-bks; Fri, 5 May 2000 14:55:41 -0700 (PDT) Received: from peace.netnation.com (mail@peace.netnation.com [204.174.223.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16563; Fri, 5 May 2000 14:55:23 -0700 (PDT) Received: from [172.143.15.158] (helo=suzannejacob) by peace.netnation.com with smtp (Exim 3.13 #5) id 12nq8C-0001Nl-00; Fri, 05 May 2000 14:59:33 -0700 From: "Salus Financial" To: "Salus Financial" Subject: THE INSURANCE PROFESSIONALS Date: Fri, 5 May 2000 14:59:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01BFB6A2.72FE7860" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00EF_01BFB6A2.72FE7860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit THE INSURANCE PROFESSIONALS It�s a fact that one out of every three Canadians will experience a life altering illness during his or her lifetime. With today�s advances in medical science the chances of survival are greater than ever! Should you be diagnosed with...and survive...any of the following 17 conditions covered under this plan the insurer will provide you with a lump sum payment of tax free cash. *Heart Attack *Cancer *Stroke *Coronary Artery Bypass Surgery *Multiple Sclerosis *Alzheimer�s Disease *Parkinson�s Disease *Major Organ Transplant *Paralysis *Kidney Failure *Coma *Blindness *Severe Burns *Loss of Speech *Occupational HIV *Loss of Limbs *Deafness Picture receiving $100,000 or $250,000 or more to help towards recovery, maintaining your lifestyle or saving your business. Fax (604) 647-0631 or return this e-mail today for more information on this new, innovative and affordable living benefit product. Name: __________________________________ Address: ________________________________ ________________________________ Date of Birth: ____________________________ Phone: _____________ Fax: ________________ I am not interested in further information. Please take me off of your list. ------=_NextPart_000_00EF_01BFB6A2.72FE7860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

THE=20 INSURANCE PROFESSIONALS

It’s a fact = that one out of every three = Canadians will=20 experience a life altering illness during his or her = lifetime.

With today’s advances in medical science = the chances of=20 survival are greater than ever!

Should you be = diagnosed=20 with...and survive...any of the following 17 conditions covered under = this plan=20 the insurer will provide you with a lump=20 sum payment of tax free=20 cash.

=20 *Heart Attack &nbs= p; =20 *Cancer

=20 *Stroke &nbs= p; &nb= sp; *Coronary=20 Artery Bypass Surgery

=20 *Multiple Sclerosis =20 *Alzheimer’s Disease

=20 *Parkinson’s Disease *Ma= jor=20 Organ Transplant

=20 *Paralysis &nbs= p; =20 =20 *Kidney=20 Failure

=20 *Coma &nbs= p; =20 =20 *Blindness =20

=20 *Severe Burns =20 =20 *Loss of Speech

=20 *Occupational HIV = =20 *Loss of Limbs

=20 *Deafness

Picture receiving = $100,000 or $250,000 or more = to help=20 towards recovery, maintaining your lifestyle or saving your=20 business.

Fax (604) 647-0631 or return this = e-mail=20 today for more information on this new, innovative and affordable living = benefit=20 product.

=20 Name: = __________________________________

=20 Address: = ________________________________

&nbs= p; =20 =20 ________________________________

=20 Date of Birth: = ____________________________

=20 Phone: _____________ Fax: ________________

I=20 am not interested in further information. Please take me off of = your=20 list.

------=_NextPart_000_00EF_01BFB6A2.72FE7860-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA16453 for ietf-822-bks; Fri, 5 May 2000 14:45:37 -0700 (PDT) Received: from peace.netnation.com (mail@peace.netnation.com [204.174.223.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16397; Fri, 5 May 2000 14:44:32 -0700 (PDT) Received: from [172.143.15.158] (helo=suzannejacob) by peace.netnation.com with smtp (Exim 3.13 #5) id 12npsv-0006Y3-00; Fri, 05 May 2000 14:43:46 -0700 From: "Salus Financial" To: "Salus Financial" Subject: THE INSURANCE PROFESSIONALS Date: Fri, 5 May 2000 14:43:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01BFB6A0.3CE311C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01BFB6A0.3CE311C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit THE INSURANCE PROFESSIONALS It�s a fact that one out of every three Canadians will experience a life altering illness during his or her lifetime. With today�s advances in medical science the chances of survival are greater than ever! Should you be diagnosed with...and survive...any of the following 17 conditions covered under this plan the insurer will provide you with a lump sum payment of tax free cash. *Heart Attack *Cancer *Stroke *Coronary Artery Bypass Surgery *Multiple Sclerosis *Alzheimer�s Disease *Parkinson�s Disease *Major Organ Transplant *Paralysis *Kidney Failure *Coma *Blindness *Severe Burns *Loss of Speech *Occupational HIV *Loss of Limbs *Deafness Picture receiving $100,000 or $250,000 or more to help towards recovery, maintaining your lifestyle or saving your business. Fax (604) 647-0631 or return this e-mail today for more information on this new, innovative and affordable living benefit product. Name: __________________________________ Address: ________________________________ ________________________________ Date of Birth: ____________________________ Phone: _____________ Fax: ________________ I am not interested in further information. Please take me off of your list. ------=_NextPart_000_00A7_01BFB6A0.3CE311C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

THE=20 INSURANCE PROFESSIONALS

It’s a fact = that one out of every three = Canadians will=20 experience a life altering illness during his or her = lifetime.

With today’s advances in medical science = the chances of=20 survival are greater than ever!

Should you be = diagnosed=20 with...and survive...any of the following 17 conditions covered under = this plan=20 the insurer will provide you with a lump=20 sum payment of tax free=20 cash.

=20 *Heart Attack &nbs= p; =20 =20 *Cancer

=20 *Stroke &nbs= p; &nb= sp; *Coronary=20 Artery Bypass Surgery

=20 *Multiple Sclerosis =20 *Alzheimer’s Disease

=20 *Parkinson’s Disease *Ma= jor=20 Organ Transplant

=20 *Paralysis &nbs= p; =20 =20 *Kidney=20 Failure

=20 *Coma &nbs= p; =20 =20 *Blindness =20

=20 *Severe Burns =20 =20 *Loss of Speech

=20 *Occupational HIV = =20 *Loss of Limbs

=20 *Deafness

Picture receiving = $100,000 or $250,000 or more = to help=20 towards recovery, maintaining your lifestyle or saving your=20 business.

Fax (604) 647-0631 or return this = e-mail=20 today for more information on this new, innovative and affordable living = benefit=20 product.

=20 Name: = __________________________________

=20 Address: = ________________________________

&nbs= p; =20 =20 ________________________________

=20 Date of Birth: = ____________________________

=20 Phone: _____________ Fax: ________________

I=20 am not interested in further information. Please take me off of = your=20 list.

------=_NextPart_000_00A7_01BFB6A0.3CE311C0-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA05663 for ietf-822-bks; Fri, 5 May 2000 03:35:53 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05659 for ; Fri, 5 May 2000 03:35:52 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13359; Fri, 5 May 2000 06:41:10 -0400 (EDT) Message-Id: <200005051041.GAA13359@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: usenet-format@landfield.com, ietf-822@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-lindsey-usefor-signed-00.txt Date: Fri, 05 May 2000 06:41:09 -0400 Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Signed Headers in Mail and Netnews Author(s) : C. Lindsey Filename : draft-lindsey-usefor-signed-00.txt Pages : 29 Date : 04-May-00 The huge growth of Netnews/Usenet in recent years has been accompanied by many attempts to abuse the system by various forms of malpractice, particularly the forging of various headers, causing it to appear that articles came from parties other than those that actually injected them or conveyed some Approval that the real poster was not entitled to give. Insofar as Netnews is regularly gatwayed to and from Email systems, these problems also extend to the Email domain. This document provides a cryptographically secure means whereby it can be established beyond doubt that relevant headers of a Netnews article or an Email message have not been tampered with in transit, and that they were indeed originated by the person purporting to have done so. It seeks to supplement, rather than to supplant, the existing protocols for signing the bodies of articles and messages. [This proposal arises from the activities of the Usenet Format Working Group, which is charged with updating the Netnews standards. Comments are invited, preferably sent to the mailing list of the Group at usenet-format@landfield.com.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lindsey-usefor-signed-00.txt 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-lindsey-usefor-signed-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-lindsey-usefor-signed-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. --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: <20000504122010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lindsey-usefor-signed-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lindsey-usefor-signed-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000504122010.I-D@ietf.org> --OtherAccess-- --NextPart--