From owner-ietf-822 Sun Jan 12 17:23:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id RAA02594 for ietf-822-bks; Sun, 12 Jan 1997 17:23:33 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-822@imc.imc.org using -f Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id RAA02582 for ; Sun, 12 Jan 1997 17:23:26 -0800 (PST) X-Sender: phoffman@mail.proper.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Jan 1997 17:22:57 -0800 To: ietf-822@imc.org From: "Paul E. Hoffman" Subject: The new "ietf-822" mailing list Sender: owner-ietf-822@imc.org Precedence: bulk Greetings. This is the first message on the ietf-822 mailing list, which has moved from CREN to IMC. The participants of the list are the same. There is a Web site for the list at which has an archive of both the old list and the new one. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-822 Tue Feb 18 16:07:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA15536 for ietf-822-bks; Tue, 18 Feb 1997 16:07:31 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA15531 for ; Tue, 18 Feb 1997 16:07:28 -0800 (PST) Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16639(1)>; Tue, 18 Feb 1997 16:08:58 PST Received: from palimpsest ([127.0.0.1]) by palimpsest.parc.xerox.com with SMTP id <242>; Tue, 18 Feb 1997 16:08:46 PDT Message-ID: <330A448D.7EA8@parc.xerox.com> Date: Tue, 18 Feb 1997 15:08:45 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ietf-822@imc.org Subject: content-disposition Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk After a lot of wrangling about how to present form data within multipart, RFC 1867 ("Form-based File Upload in HTML") recommended that data returned from filling out a form be returned as multipart/form-data where each part is identified with content-disposition: form-data. One of the things holding back RFC 1867 from standards track is that content-disposition was itself "experimental". There is ample experience now with RFC 1867, at least in HTTP, although there are some mail implementations as well. draft-moore-mime-cdisp-00 makes no mention of this use of content-disposition. There's a desire to move RFC 1867 onto standards track, or at least those parts that are outside the realm of HTML markup, even if the HTML extensions become part of W3C's next revision of HTML. What are your thoughts? Would you consider mentioning the possibility of content-disposition: form-data; name="fieldname" as a legitimate use of content-disposition within multipart/form-data in draft-moore-mime-cdisp? Thanks, Larry From owner-ietf-822 Tue Feb 18 23:32:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA21234 for ietf-822-bks; Tue, 18 Feb 1997 23:32:41 -0800 (PST) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA21223 for ; Tue, 18 Feb 1997 23:32:38 -0800 (PST) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id CAA01230; Wed, 19 Feb 1997 02:34:39 -0500 (EST) Message-Id: <199702190734.CAA01230@ig.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Larry Masinter cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: content-disposition In-reply-to: Your message of "Tue, 18 Feb 1997 15:08:45 PST." <330A448D.7EA8@parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 1997 02:34:39 -0500 Sender: owner-ietf-822@imc.org Precedence: bulk > After a lot of wrangling about how to present form data > within multipart, RFC 1867 ("Form-based File Upload in HTML") > recommended that data returned from filling out a form > be returned as multipart/form-data where each part is > identified with > content-disposition: form-data. > > One of the things holding back RFC 1867 from standards track > is that content-disposition was itself "experimental". There is > ample experience now with RFC 1867, at least in HTTP, although > there are some mail implementations as well. > > draft-moore-mime-cdisp-00 > > makes no mention of this use of content-disposition. This was an accidental omission on my part; I had intended to include form-data and simply forgot to do so. Barring strong objections, I'll put it in the next draft. Keith From owner-ietf-822 Fri Feb 21 19:25:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA04666 for ietf-822-bks; Fri, 21 Feb 1997 19:25:16 -0800 (PST) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA04662; Fri, 21 Feb 1997 19:25:12 -0800 (PST) Received: from [205.214.160.130] (d20.netgate.net [205.214.160.52]) by ng.netgate.net (8.8.5/8.6.9) with ESMTP id TAA26971; Fri, 21 Feb 1997 19:30:56 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 2 (High) Date: Fri, 21 Feb 1997 19:26:15 -0800 To: imc-mailconnect@imc.org From: Dave Crocker Subject: MailConnect 2 interoperability event Cc: (drums, ietf-smtp@imc.org, ietf-822@imc.org, imap@cac.washington.edu) Sender: owner-ietf-822@imc.org Precedence: bulk =46olks, The Internet Mail Consortium is now trying to finalize details for MailConnect 2, an engineering interoperability event for Internet mail software developers. This past summer's MailConnect 1 tested IMAP4 and MIME. MailConnect 2 is intended for ESMTP and more IMAP4 testing. In previous queries, the end of March appeared to be the best choice for bringing developers together. I would like to get some quick feedback about preferred dates, from folks who are likely to attend. LOGISTICS The event will be in the same venue as before, the San Jose, CA Hilton. They now have a T1 connection to the net. We'll be providing snacks and drinks and, will provide lunch this time. We are investigating reduced room rates at the Hilton. Let me know if you would be likely to stay there: Yes ____ No ____ DATE Please indicate ALL of the following that are feasible for you: March 18/19 - T/W ____ 19/20 - W/Th ____ 21/22 - Th/F ____ March 25/26 - T/W ____ 27/28 - W/Th ____ 28/29 - Th/F ____ April 1/2 - T/W ____ 2/3 - W/Th ____ (no 3/4, to avoid the Friday before IETF) If a later date is very strongly preferred, please let me know. If a later date is very strongly NOT preferred, also let me know. COSTS Early Registration: $1500 for IMC members; $2000 for non-members Late Registration: $2000 for IMC members; $2500 for non-members d/ -------------------- Dave Crocker, Director +1 408 246 8253 Internet Mail Consortium (f) +1 408 249 6205 127 Segre Place dcrocker@imc.org Santa Cruz, CA 95060 USA info@imc.org , http://www.imc.org From owner-ietf-822 Wed Mar 5 11:08:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA25824 for ietf-822-bks; Wed, 5 Mar 1997 11:08:29 -0800 (PST) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA25813; Wed, 5 Mar 1997 11:08:11 -0800 (PST) Received: from [205.214.160.83] (d45.netgate.net [205.214.160.79]) by ng.netgate.net (8.8.5/8.6.9) with ESMTP id LAA08457; Wed, 5 Mar 1997 11:15:38 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 2 (High) Date: Wed, 5 Mar 1997 11:08:33 -0800 To: imc-mailconnect@imc.org From: Dave Crocker Subject: MailConnect 2 / 26-27 March 97: Email Interoperability testing Cc: (drums, ietf-smtp@imc.org, ietf-822@imc.org, imap@cac.washington.edu) Sender: owner-ietf-822@imc.org Precedence: bulk The Internet Mail Consortium is sponsoring a second interoperability testing event for Internet Mail. MailConnect 2 will be held: Wednesday - Thursday, 26-27 March 1997 with setup: available the day before at: San Jose, California Hilton testing: IMAP4 and ESMTP The details of the testing will be determined by the attendees, based on discussion on the imc-mailconnect mailing list, beforehand. This is the second time we will be testing IMAP4 and the first for SMTP extensions. The event is for engineering testing, rather than for press and marketing demonstrations. These events improve actual interoperability among independent implementations, typically producing enormous imrpovements within the very short time of the meeting. =46or further details, please see: To subscribe to the event discusssion list, send a message to imc-mailconnect-request@imc.org with the single word subscribe in the body of the message. d/ -------------------- Dave Crocker, Director +1 408 246 8253 Internet Mail Consortium (f) +1 408 249 6205 127 Segre Place dcrocker@imc.org Santa Cruz, CA 95060 USA info@imc.org , http://www.imc.org From owner-ietf-822 Tue Apr 29 10:45:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA02426 for ietf-822-bks; Tue, 29 Apr 1997 10:45:04 -0700 (PDT) Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by mail.proper.com (8.8.5/8.7.3) with SMTP id KAA02422 for ; Tue, 29 Apr 1997 10:45:00 -0700 (PDT) Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA20533 for ; Tue, 29 Apr 1997 10:45:59 -0700 Received: from shorter.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA26577; Tue, 29 Apr 1997 10:45:57 -0700 Received: from cochin.eng.sun.com by shorter.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA15530; Tue, 29 Apr 1997 10:45:59 -0700 Received: from cochin by cochin.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03526; Tue, 29 Apr 1997 10:45:56 -0700 Date: Tue, 29 Apr 1997 10:45:56 -0700 (PDT) From: John Mani Reply-To: John Mani Subject: URL type To: ietf-822@imc.org cc: jmk@cochin.Eng.Sun.COM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Ie0k4RNezTf5GBmxqR6XfA== X-Mailer: dtmail 1.1.0 CDE Version 1.1_40 SunOS 5.5.1 sun4u sparc Sender: owner-ietf-822@imc.org Precedence: bulk Hi all We want to use the MIME typing system as a generic datatyping/naming mechanism (outside of mail) in our system. I know that RFC 2017 states that 'message/external-body; access-type=URL; URL=' is the recommended way of typing URLs in MIME email. However this is probably too cumbersome and too mail-specific in our generic system. What we want is a way to specify URLs as real "standalone" types. Our choices are "text/x-url" and "application/x-url". What would be the appropriate 'type' in this case ? (What's the guiding factor in deciding which type - application or text ?) And finally, is there any interest in making this a standard type ? Comments ? thanx -john From owner-ietf-822 Tue Apr 29 11:41:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA03455 for ietf-822-bks; Tue, 29 Apr 1997 11:41:20 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [128.248.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA03450 for ; Tue, 29 Apr 1997 11:41:17 -0700 (PDT) Received: (qmail 17322 invoked by uid 666); 29 Apr 1997 18:50:16 -0000 Date: 29 Apr 1997 18:50:16 -0000 Message-ID: <19970429185016.17321.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: URL type Sender: owner-ietf-822@imc.org Precedence: bulk > We want to use the MIME typing system as a generic datatyping/naming > mechanism (outside of mail) in our system. Why? There are several well-known extensible type identification systems with far less overhead than MIME. Are you subject to the constraints that MIME was designed to satisfy? Human readability, RFC 822 header field use, variable content encodings, invulnerability to various forms of corruption? ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Fri Jun 13 12:05:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA17811 for ietf-822-bks; Fri, 13 Jun 1997 12:05:11 -0700 (PDT) Received: from porta-sparc.mcom.com (h-205-217-229-148.netscape.com [205.217.229.148]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA17805 for ; Fri, 13 Jun 1997 12:05:08 -0700 (PDT) Received: from jgmyers-nt (h-205-217-229-208.mcom.com [205.217.229.208]) by porta-sparc.mcom.com (1.0.b2/8.8.5) with ESMTP id MAA27348 for ; Fri, 13 Jun 1997 12:06:46 -0700 (PDT) Message-ID: <33A19AB6.E026E93F@netscape.com> Date: Fri, 13 Jun 1997 12:08:38 -0700 From: John Gardiner Myers X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-822@imc.org Subject: Accept-Language: proposal X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk I have a need to localize the human-readable text inside of DSN's and other automated responses to 822-format messages. Here is a proposal I would like to float here, prior to issuing an internet-draft. Rough definition: Define an "Accept-Language" header with the following syntax. accept-language = "Accept-Language" ":" 1#Language-tag ; Language-tag as defined in RFC 1766 This header discloses the language preference(s) of the sender. Languages listed earlier in the list are preferred. The existence of this header also indicates that the sender is capable of handling text encoded in the utf-8 charset [RFC 2044], when properly MIME labeled. Comments: The syntax of this header is deliberately a subset of that in HTTP. Since this header is presumably only going to be generated by "new" UA's, it is not unreasonable to require these "new" UA's to support UTF-8. The alternative of also negotiating acceptable charset is worse. Disadvantages: Does not necessarily work correctly if the message goes through list expansion. The language preferences of the list maintainer can be different than those of the original sender, so if the list expander does not know to strip or replace the Accept-Language header, the list maintainer could get DSN's in a language and charset they don't understand. So, what do people think? From owner-ietf-822 Fri Jun 13 12:56:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA18366 for ietf-822-bks; Fri, 13 Jun 1997 12:56:38 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA18362 for ; Fri, 13 Jun 1997 12:56:35 -0700 (PDT) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <16902(6)>; Fri, 13 Jun 1997 12:58:37 PDT Received: from bronze.parc.xerox.com ([13.1.100.114]) by casablanca.parc.xerox.com with SMTP id <71897>; Fri, 13 Jun 1997 12:58:30 PDT Message-ID: <33A1A65C.430D@parc.xerox.com> Date: Fri, 13 Jun 1997 12:58:20 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: John Gardiner Myers CC: ietf-822@imc.org Subject: Re: Accept-Language: proposal References: <33A19AB6.E026E93F@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk > The existence of this header also indicates that the sender is capable > of handling text encoded in the utf-8 charset [RFC 2044], when properly > MIME labeled. > Please no. > The syntax of this header is deliberately a subset of that in HTTP. Please don't use something with the same syntax but different semantics. In HTTP, accept-language and accept-charset are orthogonal, and the reasons for making them so in HTTP apply equally to mail. Larry -- http://www.parc.xerox.com/masinter From owner-ietf-822 Fri Jun 13 13:16:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA18653 for ietf-822-bks; Fri, 13 Jun 1997 13:16:56 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA18649 for ; Fri, 13 Jun 1997 13:16:52 -0700 (PDT) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.6.Beta3/8.8.6.Beta3) with ESMTP id QAA16698; Fri, 13 Jun 1997 16:19:15 -0400 Message-Id: <199706132019.QAA16698@black-ice.cc.vt.edu> To: John Gardiner Myers Cc: ietf-822@imc.org Subject: Re: Accept-Language: proposal In-Reply-To: Your message of "Fri, 13 Jun 1997 12:08:38 PDT." <33A19AB6.E026E93F@netscape.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <33A19AB6.E026E93F@netscape.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_2109757544P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 13 Jun 1997 16:19:15 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_2109757544P Content-Type: text/plain; charset=us-ascii On Fri, 13 Jun 1997 12:08:38 PDT, you said: > The existence of this header also indicates that the sender is capable > of handling text encoded in the utf-8 charset [RFC 2044], when properly > MIME labeled. Umm.. yeah, but.. this may not do what you hope. This AIX 4.2 box I'm typing on has *some* UFT-8 support. However, my MUA does not support it, nor do I have fonts to cover the entire UTF-8 space. Also, remember that UTF-8 is only an *encoding* scheme. It is *not* an internationalization or localization scheme. As such, things like currency formats, date/time preferences, and sorting/collating issues are totally not addressed. If the person requests Cyrillic, what's the format of the date? Why are you implying UTF-8 support? What does this buy you? > Since this header is presumably only going to be generated by "new" > UA's, it is not unreasonable to require these "new" UA's to support > UTF-8. The alternative of also negotiating acceptable charset is worse. How about an alternative of "Return English if you can't supply in one of the requested languages"? This would eliminate a UTF-8 requirement, and be more backward-compatible as well.. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_2109757544P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM6GrPdQBOOoptg9JAQGNkwP9GvZ7ViG69mBlq5JV82pQQ5u42lw9vsQE VZrj9V3OIgf4550jAuvs7c8NXJ/BKOxNi7j7AxNN+xeiFP9WFidBAc3kfx3uMQv/ KrYfVpkL2PibhJjgLjO1D+5+Nzvw/GUTRx0LaAwjpDKz47hga7T+4rxUNzMC9lTR QWl/nVqsYmA= =1Olx -----END PGP MESSAGE----- --==_Exmh_2109757544P-- From owner-ietf-822 Fri Jun 13 15:17:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA19965 for ietf-822-bks; Fri, 13 Jun 1997 15:17:35 -0700 (PDT) Received: from porta-sparc.mcom.com (h-205-217-229-148.netscape.com [205.217.229.148]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA19961 for ; Fri, 13 Jun 1997 15:17:32 -0700 (PDT) Received: from jgmyers-nt (h-205-217-229-208.mcom.com [205.217.229.208]) by porta-sparc.mcom.com (1.0.b2/8.8.5) with ESMTP id PAA27903 for ; Fri, 13 Jun 1997 15:19:11 -0700 (PDT) Message-ID: <33A1C7CF.843F0690@netscape.com> Date: Fri, 13 Jun 1997 15:21:03 -0700 From: John Gardiner Myers X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-822@imc.org Subject: Re: Accept-Language: proposal X-Priority: 3 (Normal) References: <33A19AB6.E026E93F@netscape.com> <33A1A65C.430D@parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk Larry Masinter wrote: > Please no. Do you mean "no, please define accept-charset as well" or "no, please call this header something other than accept-charset"? I strongly disagree with the former, I could be convinced of the latter. > In HTTP, accept-language and accept-charset are orthogonal, > and the reasons for making them so in HTTP apply equally to mail. I disagree that the reasons for accept-charset in HTTP apply equally to mail. 1) In mail, the lack of interactivity significantly raises the importance of using a canonical format over the importance of having the sender avoid the cost of converting from local form to canonical form. 2) Time has passed on since accept-charset was designed. The report of the IAB Character Set Workshop strongly recommends transitioning to ISO-10646 based charsets, such as UTF-8 and/or UTF-7. Valdis.Kletnieks@vt.edu wrote: > This AIX 4.2 box I'm typing on has *some* UFT-8 support. However, > my MUA does not support it, nor do I have fonts to cover the entire UTF-8 > space. Your MUA also doesn't support the accept-language header. In order for it to support the accept-language header, it would have to be extended to understand the UTF-8 charset. It is not necessary that your MUA be able to display the entire UTF-8 codepoint space. It is only necessary for your MUA to be able to display that subset of the space that is necessary to display text in the languages that are advertised. If text in your languages all fit into iso-8859-1, for example, your MUA only has to be able to convert from UTF-8 to iso-8859-1 when displaying text. > Also, remember that UTF-8 is only an *encoding* scheme. It is *not* an > internationalization or localization scheme. As such, things like currency > formats, date/time preferences, and sorting/collating issues are totally > not addressed. If the person requests Cyrillic, what's the format of the > date? These issues are addressed by the language tags in the accept-language header. The person does not request Cyrillic, they request a specific language that happens to use Cyrillic characters. > Why are you implying UTF-8 support? What does this buy you? Simplicity. It removes the need for senders and recipients to negotiate and convert amongst a large number of different charsets. It removes the possibility of having a successful negotiation of a common language be stymied by a failure to negotiate a common charset capable of representing the necessary characters. > How about an alternative of "Return English if you can't supply in one of > the requested languages"? This would eliminate a UTF-8 requirement, and > be more backward-compatible as well.. This alternative would not remove the UTF-8 requirement. Once a sender has determined which language to use, it has the problem of figuring out which charset is both capable of expressing text in that language and which will be understood by the recipient. Without either a separate charset negotiation or charset support being communicated by the accept-language header itself, only us-ascii is known to be supported by the recipient. From owner-ietf-822 Fri Jun 13 16:20:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA20674 for ietf-822-bks; Fri, 13 Jun 1997 16:20:50 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA20657 for ; Fri, 13 Jun 1997 16:20:46 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id TAA00955; Fri, 13 Jun 1997 19:22:21 -0400 (EDT) Message-Id: <199706132322.TAA00955@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: John Gardiner Myers cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: Accept-Language: proposal In-reply-to: Your message of "Fri, 13 Jun 1997 12:08:38 PDT." <33A19AB6.E026E93F@netscape.com> Date: Fri, 13 Jun 1997 19:21:17 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk If it's not going to have the syntax used in HTTP, I'd rather have it called by some other name. I don't think the UTF-8 requirement is reasonable. It seems like this would impose a huge implementation burden for most UAs. With this requirement in place, most people can't use it or benefit from it. Without this requirement, many users could just add a header field to outgoing mail specifying the languages and charsets that the user can deal with, without needing UTF-8 support. Also, the chosen I18N approach to DSNs was to define precise error codes and include enough information so that the error could be presented in the user's language by the user agent. As far as I can tell, the error codes are usually adequate for this purpose, in that they can describe most conditions with sufficient precision. So I have to wonder if this is really needed for DSNs. And while I could see something like this header being used for email-based document requests, for it to affect DSNs would require that MTAs look at the header of the subject message. This is a layering violation. Keith From owner-ietf-822 Fri Jun 13 17:44:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA21439 for ietf-822-bks; Fri, 13 Jun 1997 17:44:20 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA21435 for ; Fri, 13 Jun 1997 17:44:16 -0700 (PDT) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <18228(7)>; Fri, 13 Jun 1997 17:46:16 PDT Received: from bronze-208.parc.xerox.com ([13.0.209.122]) by casablanca.parc.xerox.com with SMTP id <71898>; Fri, 13 Jun 1997 17:45:59 PDT Message-ID: <33A1E9BB.6F5B@parc.xerox.com> Date: Fri, 13 Jun 1997 17:45:47 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: John Gardiner Myers CC: ietf-822@imc.org Subject: Re: Accept-Language: proposal References: <33A19AB6.E026E93F@netscape.com> <33A1A65C.430D@parc.xerox.com> <33A1C7CF.843F0690@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk Let me try to say this differently: Headers should be compatible between HTTP and mail: that is, a single message header should have the same meaning, no matter which protocol is being used. Accept-Language already has a meaning in HTTP. If you want to use it in mail, you should only use it with the same meaning. Do not attach new meanings to the same header. If you really need a different meaning, then use a different header name. > I disagree that the reasons for accept-charset in HTTP apply equally to > mail. > > 1) In mail, the lack of interactivity significantly raises the > importance of using a canonical format over the importance of having the > sender avoid the cost of converting from local form to canonical form. > > 2) Time has passed on since accept-charset was designed. The report of > the IAB Character Set Workshop strongly recommends transitioning to > ISO-10646 based charsets, such as UTF-8 and/or UTF-7. I don't see what these have to do with it; you might as well just assume you can always send UTF-8, then. Whether or not "Accept-Language" is present in the message doesn't have much to do with it. In fact, "Accept-Language" is a misnomer; it should probably have been called "Prefer-Language". If you want to have a header that means "You can reply with UTF-8", why not make it "Mime-Version: 1.1" or something; the appearance of accept-language is not by itself an indication of anything other than language preference. Larry From owner-ietf-822 Sat Jun 14 23:30:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA03067 for ietf-822-bks; Sat, 14 Jun 1997 23:30:40 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA03063 for ; Sat, 14 Jun 1997 23:30:37 -0700 (PDT) Received: from eleanor.innosoft.com ("port 61137"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IK2WWEEM3YANC4L3@INNOSOFT.COM> for ietf-822@imc.org; Sat, 14 Jun 1997 23:32:13 PDT Date: Sat, 14 Jun 1997 23:33:52 -0700 (PDT) From: Chris Newman Subject: Re: Accept-Language: proposal In-reply-to: <199706132322.TAA00955@spot.cs.utk.edu> To: Keith Moore Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Fri, 13 Jun 1997, Keith Moore wrote: > I don't think the UTF-8 requirement is reasonable. > It seems like this would impose a huge implementation burden for most UAs. > With this requirement in place, most people can't use it or benefit > from it. Without this requirement, many users could just add a header > field to outgoing mail specifying the languages and charsets that the > user can deal with, without needing UTF-8 support. I disagree with this point. UTF-8 is not particularly hard to support -- it's certainly much easier to support than a large table of multiple charsets for each language and all the cross-conversions (which often use Unicode as an intermediate). We need to start "hooking" UTF-8 to proposals like this so that we can transition away from the current mess of character sets we have. In addition, an "accept-language" header which requires UTF-8 is a far simpler architecture than a combination of "accept-language" and "accept-charset". Given the IAB charset workshop guidelines I think it would be a mistake to let "accept-charset" leak out of HTTP. From owner-ietf-822 Mon Jun 16 00:13:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA01303 for ietf-822-bks; Mon, 16 Jun 1997 00:13:40 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id AAA01299 for ; Mon, 16 Jun 1997 00:13:36 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01IK41ER0CBKANC2N5@INNOSOFT.COM> for ietf-822@imc.org; Sun, 15 Jun 1997 19:41:13 PDT Date: Sun, 15 Jun 1997 19:15:10 -0700 (PDT) From: Ned Freed Subject: Re: Accept-Language: proposal In-reply-to: "Your message dated Fri, 13 Jun 1997 12:08:38 -0700" <33A19AB6.E026E93F@netscape.com> To: John Gardiner Myers Cc: ietf-822@imc.org Message-id: <01IK434D9SOOANC2N5@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk > I have a need to localize the human-readable text inside of DSN's and > other automated responses to 822-format messages. Here is a proposal I > would like to float here, prior to issuing an internet-draft. > Rough definition: > Define an "Accept-Language" header with the following syntax. > accept-language = "Accept-Language" ":" 1#Language-tag > ; Language-tag as defined in RFC 1766 > This header discloses the language preference(s) of the sender. > Languages listed earlier in the list are preferred. I agree with Larry that use of Accept-Language: in this fashion, which doesn't correspond to the HTTP semantics, is a showstopper. The IETF has both critiqued and modified HTTP usage where that usage conflicts with MIME, and I think the IETF was correct in doing this. But it is only fair that when the shoe is on the other foot, and we're defining stuff for MIME-based but non-HTTP-based protocols like Internet mail, that we pay attention to HTTP usage and not do things that conflict with it. There are two ways to solve this problem. One is to use the same field name and keep the semantics the same. The other is to define a new field with limited semantics. I see problems with both approaches. The first seems excessive for the stated application. And the second only solves this one problem without providing a basis for other sorts of capability discovery (e.g. discovery of support for things other than langauge, support for different capabilities for different sorts of messages like notifications, receipts, replies, or new mail). Capability discovery in email should either be done right or not done at all. A point solution specifically for this one limited application is a good idea if and only if we decide right her and now that this is the only sort of capability discovery we ever intend to do. And since I do not believe that this is the only sort we want I don't think this is a good idea. > The existence of this header also indicates that the sender is capable > of handling text encoded in the utf-8 charset [RFC 2044], when properly > MIME labeled. I agree with Larry about this as well -- the issue of language and character set are largely orthogonal, and as such should not be coupled in this bizzarre way. I have no problem with a mechanismm that lets you say you want responses to be in UTF-8 per se; however, such a mechanism should be part of a more general capability discovery system and not coupled to language like it was an afterthought as this proposal does. > Does not necessarily work correctly if the message goes through list > expansion. The language preferences of the list maintainer can be > different than those of the original sender, so if the list expander > does not know to strip or replace the Accept-Language header, the list > maintainer could get DSN's in a language and charset they don't > understand. This is exactly why such a mechanism has to be done right -- there's clearly a distinction between what the list moderator wants in notifications and what a message originator wants in a reply. And don't think for a minute that should you define a field like this that it won't end up being used to control other sorts of automated and even manual replies -- it will. Ned From owner-ietf-822 Mon Jun 16 08:41:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA08495 for ietf-822-bks; Mon, 16 Jun 1997 08:41:25 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA08490 for ; Mon, 16 Jun 1997 08:41:23 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1608.0) id ; Mon, 16 Jun 1997 08:42:48 -0700 Message-ID: <2FBF98FC7852CF11912A000000000001050E825F@DINO> From: "Jeff Stephenson (Exchange)" To: "'John Gardiner Myers'" , ietf-822@imc.org Subject: RE: Accept-Language: proposal Date: Mon, 16 Jun 1997 08:42:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1608.0) Content-Type: text/plain Sender: owner-ietf-822@imc.org Precedence: bulk It seems to me that it would be better to have the UA provide a localized human-readable explanation of the error based on the enhanced error codes, for two reasons: 1) This proposal, to be useful, requires that MTAs be able to generate DSNs in a large number of languages. In practice, I suspect that you'd find maybe 5 or 6 major languages being supported, with the result that in many cases DSNs would still end up being generated in English. 2) The user agent, almost by definition, is going to be localized for any particular user; it can use the enhanced error codes to generate an appropriate message. Further the UA is in a position to tell the user what, if anything, they can do about the problem using that particular UA. I also share Keith's concern about the layering issue: this functionality should be an SMTP extension rather than an 822 header. But unless I'm missing something, I don't think it should be either - enhanced error codes should be all that's required. -- jeff > -----Original Message----- > From: John Gardiner Myers [SMTP:jgmyers@netscape.com] > Sent: Friday, June 13, 1997 12:09 PM > To: ietf-822@imc.org > Subject: Accept-Language: proposal > > I have a need to localize the human-readable text inside of DSN's and > other automated responses to 822-format messages. Here is a proposal > I > would like to float here, prior to issuing an internet-draft. > <...snip...> > Disadvantages: > > Does not necessarily work correctly if the message goes through list > expansion. The language preferences of the list maintainer can be > different than those of the original sender, so if the list expander > does not know to strip or replace the Accept-Language header, the list > maintainer could get DSN's in a language and charset they don't > understand. > > So, what do people think? From owner-ietf-822 Mon Jun 16 11:21:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA10674 for ietf-822-bks; Mon, 16 Jun 1997 11:21:17 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA10670 for ; Mon, 16 Jun 1997 11:21:14 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id OAA14761; Mon, 16 Jun 1997 14:21:04 -0400 (EDT) Message-Id: <199706161821.OAA14761@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Chris Newman cc: Keith Moore , ietf-822@imc.org Subject: Re: Accept-Language: proposal In-reply-to: Your message of "Sat, 14 Jun 1997 23:33:52 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Jun 1997 14:21:03 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > On Fri, 13 Jun 1997, Keith Moore wrote: > > I don't think the UTF-8 requirement is reasonable. > > It seems like this would impose a huge implementation burden for most UAs. > > With this requirement in place, most people can't use it or benefit > > from it. Without this requirement, many users could just add a header > > field to outgoing mail specifying the languages and charsets that the > > user can deal with, without needing UTF-8 support. > > I disagree with this point. UTF-8 is not particularly hard to support -- It would require a huge effort to take every tool that I use to process mail, and extend them all to use UTF-8. This remains true even if I only care about supporting the 8859/1 subset. (in my case, we're talking MH, exmh, metamail, xterm, procmail, /bin/mail, and numerous scripts) > We need to start "hooking" UTF-8 to proposals like this so that we can > transition away from the current mess of character sets we have. I strongly disagree. I want to encouage a transition to UTF-8, but not by "hooking" it to what would otherwise be a very simple and useful extension, and not in such a way that it would have a severe adverse impact on the installed base. We haven't yet recovered from the 822-to-MIME transition. The vast majority of mailers out there can't yet deal with it adequately. (They may have some support for it, but in general it seems to be lousy.) To raise the bar further at this point would not encourage adoption of UTF-8, it would just degrade interoperability. Some tools would ignore the UTF-8 requirement and generate accept-language anyway; other tools would use this as an excuse to send UTF-8 to those in the first set and thus annoy the user. Many tools would implement UTF-8 poorly (just as they have implemented MIME poorly) and this would be an additional source of user complaints. Neither is it reasonable for every UA that sends messages, to assume that the reply will be read (or processed) by a UA with the same capabilities. It might be reasonable to assume that it will be read by the same *user*, but it's quite unreasonable to assume that the message will be read by the same *tool*, or even on the same host. Keith From owner-ietf-822 Sun Jun 29 22:02:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA21346 for ietf-822-bks; Sun, 29 Jun 1997 22:02:19 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id WAA21342 for ; Sun, 29 Jun 1997 22:02:15 -0700 (PDT) Received: (qmail 7986 invoked by uid 666); 30 Jun 1997 05:12:47 -0000 Date: 30 Jun 1997 05:12:47 -0000 Message-ID: <19970630051247.7985.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk ``Every time you do a "Group-reply" some poor shmoes are receiving duplicate e-mails.'' This is one user's description of what happens when you follow up to From: Member To: List It's used as a justification---in fact, the only justification---for reply-to munging, i.e., adding Reply-To: mailing-list@some.net. As http://www.unicom.com/FAQ/reply-to-harmful.html explains in detail, reply-to munging is harmful. But the user's criticism is still valid. Followups produce duplicates. You might suggest leaving From out of the followup address list. But that's even worse: if the sender isn't in the To line he won't get a copy of the followup. This problem is well known. The solution---having a header field that says where to send followups---has been proposed many times. But MUAs don't seem to support any such field. Why not? Perhaps it would help to have a good name. ``Followup-To'' is taken by news, unfortunately. ``Wide-Reply-To'' and ``Group-Reply-To'' are incomprehensible to novice users. ``Followups'' might work, but it's probably too close to ``Followup-To''. Any ideas? How many MUA implementors do we have here, anyway? ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Mon Jun 30 13:56:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA01791 for ietf-822-bks; Mon, 30 Jun 1997 13:56:50 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA01787 for ; Mon, 30 Jun 1997 13:56:46 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA22990; Mon, 30 Jun 1997 16:58:38 -0400 (EDT) Message-Id: <199706302058.QAA22990@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: best name for followups? In-reply-to: Your message of "30 Jun 1997 05:12:47 -0000." <19970630051247.7985.qmail@koobera.math.uic.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Jun 1997 16:58:36 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > ``Every time you do a "Group-reply" some poor shmoes are receiving > duplicate e-mails.'' > > This is one user's description of what happens when you follow up to > > From: Member > To: List > > It's used as a justification---in fact, the only justification---for > reply-to munging, i.e., adding Reply-To: mailing-list@some.net. > [...] > > This problem is well known. The solution---having a header field that > says where to send followups---has been proposed many times. But MUAs > don't seem to support any such field. Why not? Partially because there's not a consensus that this is a good idea. Even if you only have reply, sometimes you want to reply to author only, sometimes to author and all recipients, sometimes to author and particular recipients, etc. Sometimes you want to use the reply-to field; other times you want to override that field. Add a followup-to (wide-reply-to, group-reply-to whatever) field to the mix and it just makes things more confusing. (e.g. Sometimes you really do want to reply to the From/to/cc addresses instead of the addresses in either the followup-to or reply-to fields. etc.) Followup-to would also not solve many of the problems that currently exist with list reply-to munging: + The author of the subject message isn't always on the mailing list, in which case he misses the replies/followups. + A single message can be posted to multiple mailing lists, in which case followups should arguably go to all lists. (Yes, this is annoying for those on several of those lists, but cross-list discussions are often useful.) + The author may post from a different address than his list subscription. I post from moore@cs.utk.edu but get inbound list mail at moore+listname@cs.utk.edu; and inbound list mail gets read at a lower priority than mail sent to my primary mailbox. When replies from my list postings go to moore@cs.utk.edu, I can respond more quickly. And a followup-to like header is certainly not "the" only available solution. For instance, UAs could suppress duplicate messages. This doesn't require any changes to the protocols, or to the list servers, and has immediate benefit for anyone whose UA implements it. (Though there are security risks with trusting message-ids alone for this...you have to actually compare the messages to see if they're similar enough to call them duplicates. But message-ids should be a good way to identify *candidates* for duplicate suppression.) > Perhaps it would help to have a good name. ``Followup-To'' is taken by > news, unfortunately. ``Wide-Reply-To'' and ``Group-Reply-To'' are > incomprehensible to novice users. ``Followups'' might work, but it's > probably too close to ``Followup-To''. We've already had proposals for a name. What we haven't had is agreement that such proposals, if adopted, would do more good than harm. Keith From owner-ietf-822 Mon Jun 30 16:37:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA03407 for ietf-822-bks; Mon, 30 Jun 1997 16:37:53 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA03403 for ; Mon, 30 Jun 1997 16:37:49 -0700 (PDT) Received: (qmail 14283 invoked by uid 666); 30 Jun 1997 23:48:23 -0000 Date: 30 Jun 1997 23:48:22 -0000 Message-ID: <19970630234822.14282.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk It's important to understand that the author sets followups. Let me emphasize once again that reply-to munging is harmful; the question is how to fix the message duplication _without_ reply-to munging. In light of this understanding, let's review Keith's complaints: > + The author of the subject message isn't always on the mailing list, > in which case he misses the replies/followups. No, he doesn't miss anything, because he puts his own address into the followup field along with the list address. Of course, he doesn't have to bother with a followup field in this case, since the default followup targets will work properly. If he _is_ on the list, he should supply a followup field without his address. His MUA can do this automatically if it knows that he's on the list; some MUAs already support the necessary database. > + A single message can be posted to multiple mailing lists, in which > case followups should arguably go to all lists. So the user puts all the lists into the followup field. MUAs configured as above will do the right thing automatically. > When replies > from my list postings go to moore@cs.utk.edu, I can respond more > quickly. So leave your address in the followup field. You have control. (Btw, why is ietf-822 so slow? It doesn't look good for a mailing list to take half an hour to distribute a message---especially when it's a mailing list for mail implementors!) > And a followup-to like header is certainly not "the" only available > solution. For instance, UAs could suppress duplicate messages. Suppressing duplicates is fine, if you can afford to do it securely, but it solves only half the problem. After a long sequence of followups---let's say a sequence of 500 messages from different contributors---there are, with current defaults, 501 recipient addresses in the header. Software breaks. Humans can no longer read the header. Each new message takes ten times as much archive space as it should. Every contributor is at risk of being a permanent recipient of a neverending discussion; there is no escape. Of course, people don't let the header grow so much. They trim it down to just the list address. But this introduces some of the same problems as reply-to munging; for example, it destroys cross-posted discussions. With a followup field, the solution is trivial: the MUA copies the message's followup field into subsequent followups by default. > Even if you only have reply, sometimes you want to reply to author > only, sometimes to author and all recipients, sometimes to author and > particular recipients, etc. So what? Are you going to argue that we shouldn't have Reply-To since people sometimes want followups instead? > Add a followup-to > (wide-reply-to, group-reply-to whatever) field to the mix and it just > makes things more confusing. Explanation, please. Who exactly would be confused? Users will have a button for replies, just as they do now. Users will have a button for followups, just as they do now. They can control replies with Reply-To, just as they do now. They can control followups with the new field. This is much simpler than the current situation. > What we haven't had is > agreement that such proposals, if adopted, would do more good than > harm. Explanation, please. How exactly would a followup field hurt anyone? > We've already had proposals for a name. I know. I don't think ``Wide-Reply-To'' will work. As you can easily verify, ``wide reply'' is meaningless for a typical user. (``Does that have something to do with the window size?'') Even when the MUA has a ``wide reply'' feature, most users have no clue what it does. ``Group reply'' is somewhat better (and apparently more common in MUAs), but still not immediately clear to most users. Any other suggestions? ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 2 13:42:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA05161 for ietf-822-bks; Wed, 2 Jul 1997 13:42:41 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA05157 for ; Wed, 2 Jul 1997 13:42:35 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA03204; Wed, 2 Jul 1997 16:44:34 -0400 (EDT) Message-Id: <199707022044.QAA03204@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: best name for followups? In-reply-to: Your message of "30 Jun 1997 23:48:22 -0000." <19970630234822.14282.qmail@koobera.math.uic.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jul 1997 16:44:33 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > It's important to understand that the author sets followups. Let me > emphasize once again that reply-to munging is harmful; the question is > how to fix the message duplication _without_ reply-to munging. In this case, there's no need for a Followup-To header field. The existing Reply-To field (as defined in the current 822bis draft) is sufficient to allow the author to specify his preference as to where replies should go. One could argue that Reply-To is broken because so many lists mung it, and because so many UAs use it only as a replacement for the "From" address, when doing a "reply to sender and recipients". I don't really think there is a big need to allow a sender to separately specify "reply to address-list X if you want to just reply to me", and "reply to address-list Y if you want to followup". Even for those times when this is needed, the author can use From for the former, and Reply-to for the latter. (With Sender used to indicate the author's "real" address) > > And a followup-to like header is certainly not "the" only available > > solution. For instance, UAs could suppress duplicate messages. > > Suppressing duplicates is fine, if you can afford to do it securely, but > it solves only half the problem. > > After a long sequence of followups---let's say a sequence of 500 > messages from different contributors---there are, with current defaults, > 501 recipient addresses in the header. Software breaks. Humans can no > longer read the header. Each new message takes ten times as much archive > space as it should. Every contributor is at risk of being a permanent > recipient of a neverending discussion; there is no escape. The existing Reply-To header could be used to prevent such problems. Why isn't it used that way more often? Because humans blindly reply to their mail without checking the recipient list, or because UAs don't encourage people to check the recipient list when forming replies, or because UAs don't make it easy to change the recipient list. None of these problems can be fixed by adding another frob to the mail protocol. > Of course, people don't let the header grow so much. They trim it down > to just the list address. But this introduces some of the same problems > as reply-to munging; for example, it destroys cross-posted discussions. There's a difference between a human making an intelligent choice about where she wants her replies to go, and a list robot that blindly (and often incorrectly) assumes that replies should go to the entire mailing list. And if a followup-to field were introduced, lists would add or mung that field also, along with reply-to. > With a followup field, the solution is trivial: the MUA copies the > message's followup field into subsequent followups by default. A UA that blindly copy followup-to to followups, creates much the same problem as list robots that blindly mung reply-to. > > Even if you only have reply, sometimes you want to reply to author > > only, sometimes to author and all recipients, sometimes to author and > > particular recipients, etc. > > So what? Are you going to argue that we shouldn't have Reply-To since > people sometimes want followups instead? Followups are an artifact of the netnews environment, where you have separate address schemes for email and netnews. Depending on how you look at it, this was a big mistake, or an accident of history, but having two different address schemes creates lots of problems. Propagating any of this mess into the email world is a Bad Idea. People who have used netnews are accustomed to the notion of public responses (aka "followups") as opposed to private responses (aka "email"). So they may tend to think that their email UA should have a "followup" button (and UAs for both email and news do have such a button). But in the email world there's no inherent distinction between "public responses" and "private responses" and it's silly to pretend that there is one. You can define some notion of "followup" for email using a followup-to header, but doing so doesn't add any new services -- it just replicates services that already exist. It might makes people feel better because there's something for the followup button to do, but it's not useful purpose. > > Add a followup-to > > (wide-reply-to, group-reply-to whatever) field to the mix and it just > > makes things more confusing. > > Explanation, please. Who exactly would be confused? Besides you? (sorry, that was too easy.) > Users will have a button for replies, just as they do now. > > Users will have a button for followups, just as they do now. Good UAs already have separate commands for reply-to-sender and reply-to-sender-and-recipients. Ideally, users should be able to override reply-to for those cases where they really want to send the message somewhere else, so you need a way to do that. And users need to be able to set their reply-to and from addresses on outgoing mail. This is already getting confusing for most users -- who don't understand why "reply" doesn't "do the right thing". (these same users would never have such a problem with snail mail -- they'd simply address the snail mail reply to whomever they thought should receive it.) Support for followup-to would require that UAs add other commands ("followup", "set followup-to") in addition to the set above. Users who are confused by existing reply options would be even more confused by the addition of followup options which basically do the same thing as replies. They'll make more mistakes, there will be more variation in behaviors between different UAs (thus confusing authors who expect that their recipients' UAs work the same as theirs), and there will be more calls to Tech Support. > > What we haven't had is > > agreement that such proposals, if adopted, would do more good than > > harm. > > Explanation, please. How exactly would a followup field hurt anyone? I've already explained this. > > We've already had proposals for a name. > > I know. I don't think ``Wide-Reply-To'' will work. As you can easily > verify, ``wide reply'' is meaningless for a typical user. (``Does that > have something to do with the window size?'') Even when the MUA has a > ``wide reply'' feature, most users have no clue what it does. > > ``Group reply'' is somewhat better (and apparently more common in MUAs), > but still not immediately clear to most users. > > Any other suggestions? First explain how "followup" would differ from "reply", beyond the fact that it would use different header names and that it's not supported by any of the installed base. Also please explain why it would not suffer from the same problems that reply suffers from. Once you have defined the new feature, convince people that the new feature is worth implementing and supporting. *Then* worry about what to call the header field. Keith From owner-ietf-822 Wed Jul 2 17:05:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA07092 for ietf-822-bks; Wed, 2 Jul 1997 17:05:25 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA07088 for ; Wed, 2 Jul 1997 17:05:22 -0700 (PDT) Received: (qmail 2131 invoked by uid 666); 3 Jul 1997 00:16:05 -0000 Date: 3 Jul 1997 00:16:05 -0000 Message-ID: <19970703001605.2130.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk Keith says that users can control replies with Reply-To (in the absence of reply-to munging). I agree. However, users currently have no way to control followups. Keith then suggests that there's no need for users to control replies and followups separately. That's absurd. One of the big munging harms discussed in http://www.unicom.com/FAQ/reply-to-harmful.html is the user's inability to control replies. Next Keith proposes using Sender in place of From, using From to control replies, and using Reply-To to control followups. This is a massive change from the RFC 822 Reply-To semantics supported by dozens of existing clients. The transition would be a disaster. > There's a difference between a human making an intelligent choice > about where she wants her replies to go, Here Keith is referring to people deleting recipients from followups. The problem is that these people don't have the information they need: are those recipients members of the mailing list? The result is that non-subscribers are often accidentally removed. > And if a followup-to field were introduced, lists would add or mung > that field also, along with reply-to. If Keith doesn't understand why Reply-To munging happens right now, he should read http://www.unicom.com/BBS/bbs_forum.cgi?forum=replyto. The more clients that support a followup field, the less motivation there is for this type of munging. > A UA that blindly copy followup-to to followups, creates much the same > problem as list robots that blindly mung reply-to. If Keith doesn't understand the harms caused by Reply-To munging, he should read http://www.unicom.com/FAQ/reply-to-harmful.html. > Followups are an artifact of the netnews environment, where you have > separate address schemes for email and netnews. Nonsense. Replies and followups are fundamentally different operations. Practically every mailer supports both replies and followups. This has nothing to do with the difference between mail addresses and news addresses. > having two different address schemes creates lots of problems. I agree. One solution is to integrate the newsgroup address space into the mail address space. Here's a working example: To: djb@koobera.math.uic.edu, sci.crypt@pubnews.demon.co.uk It would be easy to set up a global usenet.news domain, configured locally to talk to a nearby NNTP server. Newsgroups are simply high-volume mailing lists with many entry points and a fancy distribution mechanism. > But in the email world there's no inherent distinction > between "public responses" and "private responses" and it's silly to > pretend that there is one. Every popular MUA supports both replies and followups. > You can define some notion of "followup" > for email using a followup-to header, but doing so doesn't add any new > services -- it just replicates services that already exist. False. It provides a direct way to control followups; this feature does not exist right now. MUAs will check the followup field before checking From/To/Cc or Reply-To/To/Cc. Many simple situations can be handled with the proposed Mail-Copies-To field, which says whether to include the sender in followups, but a followup field is a much more direct solution. > > Explanation, please. Who exactly would be confused? > Besides you? (sorry, that was too easy.) I find this comment rather amusing, given the number of ridiculous statements that Keith has made in this discussion---claiming that the followup field is for MLMs to set, claiming that the widely recognized problem of duplicates doesn't exist, claiming that the problem is solved by MUA duplicate elimination, etc. > Users who are confused by existing reply options would be even more confused > by the addition of followup options which basically do the same thing > as replies. [ ... ] > Support for followup-to would require that UAs add other commands > ("followup", "set followup-to") in addition to the set above. Here Keith makes yet another stupid mistake: he seems to think that followups are something different from the MUA's existing ``wide reply'' or ``group reply'' or ``reply to all'' feature. One wonders how many times Keith needs to see the problem statement before he understands it. Here it is again: Right now, when someone _follows up_ to a mailing list message from a subscriber, the subscriber and the mailing list are both in the followup's recipient list by default. The obvious fix is to let the subscriber override the default _followup_ target, omitting his own address. > > Explanation, please. How exactly would a followup field hurt anyone? > I've already explained this. Nonsense. Keith has explained bad consequences of two red herrings: first, having MLMs munge the followup field; second, having followups distinguished from reply-to-sender-and-recipients. > First explain how "followup" would differ from "reply", beyond the > fact that it would use different header names and that it's not > supported by any of the installed base. Nonsense. It's supported by most, perhaps all, of the installed base. It's even supported by Berkeley Mail. What isn't standardized is the _name_. > Also please explain why it > would not suffer from the same problems that reply suffers from. The motivation for reply-to munging is that, in its absence, a typical user has no easy way to follow up without the problem of duplicates discussed above. If, on the other hand, his MUA supports a followup field, subscribers suddenly have the ability to eliminate those duplicates. Once the followup field is universally supported, the motivation for reply-to munging will be gone. > Once you have defined the new feature, convince people that the new feature > is worth implementing and supporting. *Then* worry about what to call > the header field. Is there anyone other than Keith who's confused about the function and benefits of a followup field? I don't see Keith's self-imposed blindness as a major problem here; MUA implementors have never paid much attention to him in the past, and aren't likely to pay attention to him now. The introduction of Mail-Copies-To in two MUAs indicates that other people understand the problem here. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Thu Jul 3 02:14:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id CAA13523 for ietf-822-bks; Thu, 3 Jul 1997 02:14:49 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id CAA13519 for ; Thu, 3 Jul 1997 02:14:44 -0700 (PDT) Received: from eleanor.innosoft.com ("port 35456"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IKS7ULGWXA8WVYX7@INNOSOFT.COM> for ietf-822@imc.org; Thu, 3 Jul 1997 02:15:55 PDT Date: Thu, 03 Jul 1997 02:17:39 -0700 (PDT) From: Chris Newman Subject: Re: best name for followups? In-reply-to: <19970703001605.2130.qmail@koobera.math.uic.edu> To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk I find the arguments in: very technically compelling. I'd love to know of any way to make it politically compelling... I also find Keith's comment that users don't have the information necessary to set a followup-to email header correctly, and won't want to enter one manually compelling; although I disagree that reply-to offers sufficient functionality. I think the current situation is broken as I hate having to manually edit people out of headers all the time and worry that some of the people I'm removing might not be on the list. Now what information does the person who sends to a list have which is useful to know? I think there are three useful preferences the sender can communicate: (1) Keep my personal address in all group replies. (2) I read the list; but like to get a bcc of group replies to messages I post. (3) I read the list; so don't use my personal address in replies. What about a new header which simply communicates this information? Group-Reply-Pref: include-me Group-Reply-Pref: bcc-me Group-Reply-Pref: exclude-me Defaults to "include-me" if not present since that's current practice and we don't want to surprise users with a behavior change. If this got deployed I know a bunch of people who would love to use it. - Chris From owner-ietf-822 Thu Jul 3 09:17:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA18388 for ietf-822-bks; Thu, 3 Jul 1997 09:17:49 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA18380 for ; Thu, 3 Jul 1997 09:17:46 -0700 (PDT) Received: (qmail 7149 invoked by uid 666); 3 Jul 1997 16:28:33 -0000 Date: 3 Jul 1997 16:28:33 -0000 Message-ID: <19970703162833.7148.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > users don't have the information > necessary to set a followup-to email header correctly, The user simply has to (1) create a followup field from Reply-To/To/Cc or From/To/Cc, and (2) remove his address if it's covered by a mailing list. Exactly which information is he missing? #1 is trivial to do automatically. #2 is also trivial for MUAs that know which lists the user is on, such as mutt. > Group-Reply-Pref: exclude-me This is the Mail-Copies-To approach. It covers many simple situations, as I mentioned---for example, the default situation described above. However, I prefer a followup field, for the same reason that I like having a followup field in news: it's more flexible. For example, I can manually redirect a crossposted discussion away from an inappropriate mailing list. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Thu Jul 3 17:06:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA23795 for ietf-822-bks; Thu, 3 Jul 1997 17:06:02 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA23790 for ; Thu, 3 Jul 1997 17:05:57 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id UAA10034; Thu, 3 Jul 1997 20:08:02 -0400 (EDT) Message-Id: <199707040008.UAA10034@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: best name for followups? In-reply-to: Your message of "03 Jul 1997 16:28:33 -0000." <19970703162833.7148.qmail@koobera.math.uic.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jul 1997 20:08:02 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > However, I prefer a followup field, for the same reason that I like > having a followup field in news: it's more flexible. For example, I can > manually redirect a crossposted discussion away from an inappropriate > mailing list. In email, using reply-to, I can manually redirect a discussion away from inappropriate recipients. What's the difference? Keith From owner-ietf-822 Thu Jul 3 17:02:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA23755 for ietf-822-bks; Thu, 3 Jul 1997 17:02:20 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA23751 for ; Thu, 3 Jul 1997 17:02:15 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id UAA09966; Thu, 3 Jul 1997 20:04:20 -0400 (EDT) Message-Id: <199707040004.UAA09966@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: best name for followups? In-reply-to: Your message of "03 Jul 1997 00:16:05 -0000." <19970703001605.2130.qmail@koobera.math.uic.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jul 1997 20:04:19 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > Keith says that users can control replies with Reply-To (in the absence > of reply-to munging). I agree. However, users currently have no way to > control followups. True. But you haven't demonstrated that followups are (a) significantly distinct from replies and (b) worth having. > Keith then suggests that there's no need for users to control replies > and followups separately. That's absurd. Not if there's no good reason to have followups (as distinct from replies) in the first place. > One of the big munging harms > discussed in http://www.unicom.com/FAQ/reply-to-harmful.html is the > user's inability to control replies. Yes, but the same problems and more would exist for followups if followup-to were defined, because lists would mung those as well. Oddly enough, the best way I can see to get lists to stop munging reply-to is to define some sort of list-reply-to header and get UAs to support that. This would still be confusing to users, but at least there would be a clear separation of function - reply-to is specified by the message author, and list-reply-to is specified by the list that you received the message from. And it wouldn't stop reply-to munging entirely, but it might decrease its incedence. > Next Keith proposes using Sender in place of From, using From to control > replies, and using Reply-To to control followups. This is a massive > change from the RFC 822 Reply-To semantics supported by dozens of > existing clients. The transition would be a disaster. This is of course not what I had in mind. Part of your confusion is due to your insistence on a notion of followup as separate from reply, even when interpreting a message that I wrote. Since I don't believe that there is a significant difference between these operations, I obviously would not propose "using Reply-To to control followups". > > There's a difference between a human making an intelligent choice > > about where she wants her replies to go, > > Here Keith is referring to people deleting recipients from followups. Nope. I don't believe in followups as distinct from replies. > The problem is that these people don't have the information they need: > are those recipients members of the mailing list? The result is that > non-subscribers are often accidentally removed. If someone replies to a message addressed to both me and this mailing list, they shouldn't be trying to figure out whether I'm on the mailing list. I am on this mailing list, but I don't receive mail from this list at the same address that appears in the From field of mail I send. If someone deletes me from the recipient list of a response because they assume I'm on the mailing list, chances are that I won't see the response anytime soon. > > And if a followup-to field were introduced, lists would add or mung > > that field also, along with reply-to. > > If Keith doesn't understand why Reply-To munging happens right now, he > should read http://www.unicom.com/BBS/bbs_forum.cgi?forum=replyto. The > more clients that support a followup field, the less motivation there is > for this type of munging. I understand why Reply-To munging happens (actually there are lots of reasons), but I disagree that adding a followup-to header will actually lessen the degree of header munging, or simplify things for the user, or increase the probability that hitting a single button on the user's UA will do the right thing. > > A UA that blindly copy followup-to to followups, creates much the same > > problem as list robots that blindly mung reply-to. > > If Keith doesn't understand the harms caused by Reply-To munging, he > should read http://www.unicom.com/FAQ/reply-to-harmful.html. I pretty much agree with everything in Chip's statement, and have publically expressed support for it in the past. Your implication that I don't understand his argument is disingenuous. > > Followups are an artifact of the netnews environment, where you have > > separate address schemes for email and netnews. > > Nonsense. Replies and followups are fundamentally different operations. please explain what's different about them in a way that doesn't either: refer to netnews or change the definition of reply and reply-to. > Practically every mailer supports both replies and followups. Perhaps every UA that supports netnews supports both replies and followups (at least for netnews), but none of the email-only UAs that I've used support both. Most UAs support reply-to-sender and reply-to-all, with some variation as to (a) whether "reply-to" is used instead of the "from" address, or as the "default" recipient list, and (b) the definition of "all" (does it include cc addresses or just to addresses?) I think we'd be better off defining "reply" and "reply-to-all" in terms of existing to/cc/from/reply-to headers, than to add new headers in the mix. > This has nothing to do with the difference between mail addresses and > news addresses. > > > having two different address schemes creates lots of problems. > > I agree. One solution is to integrate the newsgroup address space into > the mail address space. Here's a working example: > > To: djb@koobera.math.uic.edu, sci.crypt@pubnews.demon.co.uk > > It would be easy to set up a global usenet.news domain, configured > locally to talk to a nearby NNTP server. I wouldn't mind seeing something like that, though it would be really difficult to get people to agree on a domain name for news. (technically it may be easy; politically it would be very difficult. locally-configured domain names aren't supposed to exist. don't try to argue otherwise; this is an old war and reopening it won't get anywhere useful) Easier would be to establish a convention for domain literals, e.g. sci.crypt@[news:] or keith_moore@[fax:+14239748295] > Newsgroups are simply high-volume mailing lists with many entry points > and a fancy distribution mechanism. > > > But in the email world there's no inherent distinction > > between "public responses" and "private responses" and it's silly to > > pretend that there is one. > > Every popular MUA supports both replies and followups. Depends on what you mean by followups. > > You can define some notion of "followup" > > for email using a followup-to header, but doing so doesn't add any new > > services -- it just replicates services that already exist. > > False. It provides a direct way to control followups; circular argument. Having X would provide a way to control X. to which my response is: Not having X would rid me of the need to control X. unless you can give me a much better justification for X, I'm quite sure that I'm better off without it. (and no, the fact that something called X apparently exists on some UAs, which is almost certainly implemented differently on each UA, and also differently than what you propose, is not a justification for perpetuating X or standardizing X') > > > Explanation, please. Who exactly would be confused? > > Besides you? (sorry, that was too easy.) > > I find this comment rather amusing, given the number of ridiculous > statements that Keith has made in this discussion---claiming that the > followup field is for MLMs to set, claiming that the widely recognized > problem of duplicates doesn't exist, claiming that the problem is solved > by MUA duplicate elimination, etc. Your mis-statement of my position provides more evidence of your confusion. > > Users who are confused by existing reply options would be even more confused > > by the addition of followup options which basically do the same thing > > as replies. > [ ... ] > > Support for followup-to would require that UAs add other commands > > ("followup", "set followup-to") in addition to the set above. > > Here Keith makes yet another stupid mistake: he seems to think that > followups are something different from the MUA's existing ``wide reply'' > or ``group reply'' or ``reply to all'' feature. Absolutely they are. Reply-to-all doesn't recognize a followup-to header, and the operation that you're proposing would recognize such a header. If such an operation were implemented, I would still need a different operation to allow me to send a reply-to-all WITHOUT looking at the followup-to field, because I might have reasons for not following the author's suggestion of where I send my responses. Above you stated that followups and replies are fundamentally different operations, and now you're telling me that followup is no different than "reply to all". For a large number of users, "reply" is no different than "reply to all". > One wonders how many times Keith needs to see the problem statement > before he understands it. Here it is again: > > Right now, when someone _follows up_ to a mailing list message from a > subscriber, the subscriber and the mailing list are both in the > followup's recipient list by default. > > The obvious fix is to let the subscriber override the default _followup_ > target, omitting his own address. Your problem statement uses an undefined term, and so is meaningless. If I choose a definition for that term, you'll pick a different definition and claim that my arguments based on my defintion are stupid. And if I equate your word "followup" to my UA's "reply-to-all" command, the author of the subject message does have the ability to override the default recipient list of "reply-to-all", using reply-to. I realize that many UAs don't handle "reply-to-all" this way, in particular a lot of UAs use Reply-to only as a replacement for From. But the DRUMS document already clarifies that reply-to is the author's preference as to where replies should be sent. Adding yet another header to define replies provides marginal additional value at best, and increases the complexity (and variation among UAs) as to how recipients can respond to messages. It's not worth it. > > > Explanation, please. How exactly would a followup field hurt anyone? > > I've already explained this. > > Nonsense. Keith has explained bad consequences of two red herrings: > first, having MLMs munge the followup field; second, having followups > distinguished from reply-to-sender-and-recipients. And you completely ignore my argument against unnecessary complexity, by citing points irrelevant to this argument and calling them red harrings. > > First explain how "followup" would differ from "reply", beyond the > > fact that it would use different header names and that it's not > > supported by any of the installed base. > > Nonsense. It's supported by most, perhaps all, of the installed base. > It's even supported by Berkeley Mail. Okay, but whatever that operation is, it doesn't recognize a followup-to header, and we're better off without one. If someone modified Berekeley Mail to support a followup-to header, I'd end up manually editing headers even more often than I do now. > > Also please explain why it > > would not suffer from the same problems that reply suffers from. > > The motivation for reply-to munging is that, in its absence, a typical > user has no easy way to follow up without the problem of duplicates > discussed above. The problem of duplicates won't be solved by a followup-to header, in any way that couldn't be solved by use of reply-to. Let's take this message as an example. If my preference is for replies to this message to go to me only, I can set "reply-to: moore@cs.utk.edu". If my preference is for replies to go to the 822ext list only, I can set "reply-to: ietf-822@imc.org". If my preference is for replies to go to sender and all recipients, but to get only one copy of the message, I can set "reply-to: ietf-822@imc.org, djb@koobera.math.uic.edu" The recipient of the message can of course override my defaults. Some, perhaps most, UAs will not do what I intend: e.g. if the recipient uses "reply to sender" they will send the reply to the reply-to address, but if the recipient uses "reply to all" they will send the reply to reply-to+to[+cc]. In which case I'll get a duplicate. Followup-to won't fix this: for the forseeable future UAs won't either recognize it or generate it. By the time UAs do recognize it, lists will mung it. If the followup-to field is somehow specified so that lists don't mung it, lists will want their own header that specifies how to send mail to the list (further increasing the complexity of UAs' reply operations). > If, on the other hand, his MUA supports a followup field, subscribers > suddenly have the ability to eliminate those duplicates. But the followup-to field would also be used in other ways, just as reply-to has been used in other ways. It would increase the degree of variation in UA behavior and thereby increase user confusion and tech support costs. If anything, it seems like we have plenty of experience with reply-to that indicates that yet another header to "control" where replies go is a Bad Idea. > Once the followup field is universally supported, the motivation for > reply-to munging will be gone. There's a lot more motivation for reply-to munging than duplicate suppression. Some lists want to keep discussion on the list. Some lists want to keep discussion off of the list. Some lists are built with the assumption that recipient's UAs are broken and can't reply to To or Cc addreses. (If these UAs aren't yet fixed to allow replies to To/Cc, how likely is it that they will be "fixed" to support followup-to?) Many lists are set up to mung reply-to based on the false assumption that "lists are supposed to work this way", proabably because of experience with LISTSERV and listproc and other header-munging list software. (LISTSERV was originally written for BITNET where almost none of the UAs in use could reply to other than a single address). > > Once you have defined the new feature, convince people that the new feature > > is worth implementing and supporting. *Then* worry about what to call > > the header field. > > Is there anyone other than Keith who's confused about the function and > benefits of a followup field? I freely admit that I'm confused about what exists in your mind. Most people can argue with some flexibility: by clearly communicating their ideas, tolerating some difference in definitions from one person to another, using intuition to guess what someone else means in the absence of precise specification, and not assuming that others will uniformly adopt their world-view. You don't seem to be capable of any of these. Consequently, the only reason to discuss things with you at all is for damage control -- to demonstrate to others that your ideas aren't well formed. Which is not to say that you never have good ideas, but you are apparently incapable of adapting your ideas to accomodate others' experience. The surest way to destroy a potentially useful suggestion is for you to argue about it, because you'll exhaust anyone who tries to modify it based on their own experience. Your tendency to name calling, misstating others positions, reiterating positions that have been modified, diverting from the original argument and finding something else to attack when you start to lose, "wife beating" attacks, and non sequitors and other lapses of logic, do not lend credibility to your arguments. Keith From owner-ietf-822 Sat Jul 5 09:18:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA16510 for ietf-822-bks; Sat, 5 Jul 1997 09:18:48 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA16503; Sat, 5 Jul 1997 09:18:42 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.5/8.8.5) with ESMTP id SAA06253; Sat, 5 Jul 1997 18:21:02 +0200 (MET DST) X-Sender: jpalme@dsv.su.se (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Jul 1997 18:20:51 +0200 To: IETF mail extensions mailing list From: Jacob Palme Subject: Advise on the implementation of Supersedes, In-Reply-To and References e-mail headers Sender: owner-ietf-822@imc.org Precedence: bulk I have written a draft document with advice on how to implement the Supersedes, In-Reply-To and References headers in mail and news user agents. The document has been submitted to IETF drafts is available at URL: ftp://ftp.dsv.su.se/users/jpalme/draft-palme-newfields-info-00.txt, and its text is copied below in this message: --- --- cut here --- --- Network Working Group Jacob Palme Internet Draft Stockholm University/KTH draft-palme-newfields-info-00.doc IETF status: To become an informational RFC Expires: January 1998 July 1997 Advise on the implementation of In-Reply-To, References and Supersedes e-mail and netnews headers Status of this Document This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Separate Internets standards documents define the e-mail headers, In-Reply-To, References, Supersedes and Expires. This document, which is an informational RFC, gives some advise on the implementation of these features. Table of Contents 1. User interface 2. Hard and soft Supersedes 3. Data base 4. References 5. Author's Address 1. User interface The fields "In-Reply-To", "References" and "Supersedes" are all used to convey information about references between different e-mail messages or netnews articles. The best way to implement these fields is to tell the recipient that two messages reference each other, and to make it easy for readers to traverse threads (series of linked messages) up and down. In the particular case of "Supersedes", a user who has not yet read either the old or the new version, may be shown only the new version as a new message, but with methods to easily find the old version. A good way to show this information to users is to show the "In-Reply- To", "Supersedes" and "References" fields and allow the user to click on the parameters of these fields to get to the referred-to messages. Additionally, it is useful to add reverse fields to message headers, i.e. "Replied-By", "Referenced-By" and "Superseded-By". This allows a user, when reading a message, to see if someone else has already replied, and it allows users to traverse threads downwards and not only upwards. Such reverse fields should not be sent in e-mail, they are just for local handling in user mailbox databases. 2. Hard and soft Supersedes By a hard supersedes is meant a Supersedes which causes deletion of the supersedes message. By a soft supersedes is meant a Supersedes which still keeps both messages, and allows a user to see and use the reference between them, similarly to In-Reply-To and References. Supersedes should be implemented as soft supersedes. Some implementations, especially in Usenet News, do however implement it as hard supersedes. Hard supersedes has the same security problem as the Cancel command of Usenet News. They can be used to malicuosly deleting other people's messages. Use of strong authentication of the author can reduce this risk. 3. Data base In order to implement this, a data base is needed which, given a Message-ID, can find the message which this Message-ID refers to. This data base has a very simple structure, just a single value mapped to one or more messages. Note, however, that the same message can be stored in more than one mailbox, so the data base should not be restricted to only one location for each Message-ID. Every time a message is added, moved, copied, deleted or purged, this data base need to be updated. The main problem with these kinds of Message-ID data bases is that they tend to become very large with time, and they easily collect garbage (Message-ID-s of messages not any more available in the mailbox data base). The two most common methods to implement such data bases are: (a) Implement a large data base, but with some method of garbage collection to avoid unlimited growth of the data base. (b) Implement a smaller data base, where all objects are deleted after a certain time, for example a few months. With implementation method (b), information about the references in the form of "In-Reply-To", "References", "Supersedes", "Replied-By", "Referenced-By" and "Superseded-By" should also be stored in the message headers themselves. The reason method (b) works is that it is very uncommon that a message has a reference to other than very recent messages. Thus, the lack of "Replied-By", "Referenced-By" and "Superseded-By" headers in these very uncommon cases is acceptable. The advantage with method (b) is that a complex garbage collection method, as for method (a), is not needed. A much simpler garbage collection method, just removing records after a certain expiration time, can be used instead. 4. References Ref. Author, title --------- -------------------------------------------------------- [AUTOLOOP] J. Palme: "Loop control for the Auto-Submitted e-mail header", draft-palme-autosub-03.txt, July 1997. [MIME1] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996. . [MIME2] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996. [MIME3] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, December 1996. [MIME4] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, January 1997. [MIME5] "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996. [NEWFIELDS] J. Palme: "The Auto-Submitted, Supersedes and Expires E-mail Headers", draft-ietf-mailext-new-fields-08.txt, July 1997. [NEWS] M.R. Horton, R. Adams: "Standard for interchange of USENET messages", RFC 1036, December 1987. [RFC822] D. Crocker: "Standard for the format of ARPA Internet text messages." STD 11, RFC 822, August 1982. [SMTP] J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. 5. Author's Address Jacob Palme Phone: +46-8-16 16 67 Stockholm University and KTH Fax: +46-8-783 08 29 Electrum 230 E-mail: jpalme@dsv.su.se S-164 40 Kista, Sweden ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-822 Tue Jul 8 16:43:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA29427 for ietf-822-bks; Tue, 8 Jul 1997 16:43:03 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA29423 for ; Tue, 8 Jul 1997 16:43:00 -0700 (PDT) Received: (qmail 9269 invoked by uid 666); 8 Jul 1997 23:54:12 -0000 Date: 8 Jul 1997 23:54:12 -0000 Message-ID: <19970708235412.9268.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk Time for a reality check. BSD Mail supports two response functions: 1. ``reply to originator'' = From. 2. ``send mail to sender and all recipients'' = From + To + Cc. Elm supports two response functions: 1. ``reply'' = From. 2. ``group reply'' = From + To + Cc. Pine supports one function but asks ``reply to all recipients?'': 1. ``no'' = From. 2. ``yes'' = From + To + Cc. Mutt supports two response functions: 1. ``reply'' = From. 2. ``reply to all recipients'' = From + To + Cc. Does Keith see the pattern yet? Or shall I start listing non-UNIX mailers too? There's certainly no standardization at the edges of these functions. For example, some MUAs copy the original To into the new Cc field; some copy it into the new To field. But there's always a reply function, using From in the common case, and a followup function, using From + To + Cc in the common case. Now, once again, here's the problem: A subscriber sends a message to a mailing list. Someone follows up. The response is sent to both the subscriber and the mailing list. As I've already discussed in detail, the extra address is generally harmful. I don't think there's any dispute about this. Unfortunately, the person following up can't tell that situation apart from the following situation, where the extra address is generally beneficial: A non-subscriber sends a message to a mailing list. Someone follows up. The response is sent to the non-subscriber and the mailing list. So the original author has to put some extra information into his header to differentiate the two situations. The obvious solution is a followup field. This would put control directly in the hands of the original author, and it would be trivial to implement. My question is what this field should be called. > But you haven't demonstrated that followups are (a) significantly > distinct from replies and (b) worth having. Existing MUAs support followups. Followups have vastly different effects from replies. I really don't care whether Keith accepts these facts; his willful ignorance is not typical of MUA implementors. > And if I equate your word "followup" to my UA's "reply-to-all" command, > the author of the subject message does have the ability to override > the default recipient list of "reply-to-all", using reply-to. > I realize that many UAs don't handle "reply-to-all" this way, That's because they're following RFC 822, section 4.4.4. > And you completely ignore my argument against unnecessary complexity, I agree with Keith that RFC 822 is unnecessarily complex. But we're stuck with it. Keith's proposed change in semantics would be a disaster. > Okay, but whatever that operation is, it doesn't recognize a > followup-to header, and we're better off without one. If someone > modified Berekeley Mail to support a followup-to header, I'd end up > manually editing headers even more often than I do now. Let's see some specific examples supporting this claim. In exactly what situation would a followup field, implemented as I described, produce worse results than the current defaults? > Followup-to won't fix this: for the forseeable future UAs won't > either recognize it or generate it. Duh. There's no transition problem here. MUAs can support a followup field without trouble. As support spreads, duplicate messages will disappear. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Tue Jul 8 20:06:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA01248 for ietf-822-bks; Tue, 8 Jul 1997 20:06:15 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id UAA01244 for ; Tue, 8 Jul 1997 20:06:11 -0700 (PDT) Received: (qmail 12396 invoked by uid 666); 9 Jul 1997 03:17:24 -0000 Date: 9 Jul 1997 03:17:24 -0000 Message-ID: <19970709031724.12395.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > In email, using reply-to, I can manually redirect a discussion away from > inappropriate recipients. What's the difference? My proposal---using Reply-To to control replies, and a followup field to control followups---is a _labelled_ change from RFC 822 semantics. Your proposal---using From to control replies, and Reply-To to control followups---is an _unlabelled_ change from RFC 822 semantics. You keep complaining that MUAs don't use From and Reply-To the way you suggest. That's because they're following RFC 822, section 4.4.4. Of course, this is only a guess at what your proposal means, since you consistently refuse to say what you want real MUAs to do with their two built-in response functions. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 9 00:39:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA03306 for ietf-822-bks; Wed, 9 Jul 1997 00:39:11 -0700 (PDT) Received: from candle.brasslantern.com (root@ncs-39.nbn.com [199.4.66.39]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id AAA03301 for ; Wed, 9 Jul 1997 00:39:06 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id XAA09577; Tue, 8 Jul 1997 23:52:16 -0700 From: "Bart Schaefer" Message-Id: <970708235216.ZM9576@candle.brasslantern.com> Date: Tue, 8 Jul 1997 23:52:15 -0700 In-Reply-To: <19970709031724.12395.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: best name for followups?" (Jul 9, 3:17am) References: <19970709031724.12395.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: best name for followups? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 9, 3:17am, D. J. Bernstein wrote: } Subject: Re: best name for followups? } } > In email, using reply-to, I can manually redirect a discussion away from } > inappropriate recipients. What's the difference? } } My proposal---using Reply-To to control replies, and a followup field to } control followups---is a _labelled_ change from RFC 822 semantics. } } Your proposal---using From to control replies, and Reply-To to control } followups---is an _unlabelled_ change from RFC 822 semantics. That's not Keith's proposal, and you ought to know that it isn't. Keith's proposal is to use Reply-To to control replies, and to ignore the concept of followups entirely. I happen to agree with him on the latter point; I don't think it's useful to apply the netnews concept of `followup' to the common email UA function of `reply using From + To + Cc'. They happen to have a similar effect if and only if one of those headers contains the address of a mailing list, but they're still not really the same thing. } You keep complaining that MUAs don't use From and Reply-To the way you } suggest. That's because they're following RFC 822, section 4.4.4. Actually, none of them are following 4.4.4 when they do `reply to all', because 4.4.4 doesn't apply to the To and Cc fields. It applies only to From, Sender, and Reply-To. Anything that automatically uses To and Cc in that way is extended functionality, not covered by RFC822. There is no mention anywhere in 822 of using To and Cc that way. Even if you grant dispensation for common practice, it's debatable whether they're following 4.4.4; the statement there is: If the "Reply-To" field exists, then the reply should go to the addresses indicated in that field and not to the address(es) indicated in the "From" field. It's been argued that the "and not to ..." clause is extraneous, and that the interpretation was meant to be "... go to the addresses indicated in that field, and nowhere else." Which is exactly what the basic `reply' function does in all the UAs that you listed; the `reply to all' function is ignoring the implicit "and nowhere else." (Section 4.3.1: The "Reply-To" field is added by the originator and serves to direct replies, ... Section 4.4.3: The "Reply-To" field is added by the originator and is intended to direct replies. But they both muddy the issue by attaching clauses about Return-Path, so there's no definitive "and nowhere else" anywhere.) Furthermore, most of those UAs' `reply to all' functions behave as `reply using (Reply-To OR From) + To + Cc'; some do even more complex things, but in any case they're usually doing a 4.4.4 `reply' and then, in addition, using some other set of addresses. That fits the definition of extended functionality, I'd say. I happen to think it's useful enough extended functionality that it ought to be recognized by the standards; but confusing it with the concept of `following up' is the wrong approach. } Of course, this is only a guess at what your proposal means, since you } consistently refuse to say what you want real MUAs to do with their two } built-in response functions. I won't presume to speak for him, but my understanding is that the second response function should be `reply using Reply-To OR (From + To + Cc)' (note the change in parenthesization). Maybe a better characterization is that `reply' should always mean `using Reply-To OR From', and tacking on addresses from any other source should be in a different category. This essentially means that we don't change RFC882, but rather that we start insisting that UAs obey the strictest possible interpretation of the Reply-To header. I dislike that for various reasons, but I find it even more distasteful to stir `followups' into the mix. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Wed Jul 9 01:43:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA03822 for ietf-822-bks; Wed, 9 Jul 1997 01:43:47 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@ncs-46.nbn.com [199.4.66.46]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id BAA03818 for ; Wed, 9 Jul 1997 01:43:41 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id BAA10045 for ietf-822@imc.org; Wed, 9 Jul 1997 01:46:15 -0700 From: "Bart Schaefer" Message-Id: <970709014614.ZM10044@candle.brasslantern.com> Date: Wed, 9 Jul 1997 01:46:14 -0700 In-Reply-To: <19970708235412.9268.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: best name for followups?" (Jul 8, 11:54pm) References: <19970708235412.9268.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: best name for followups? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 8, 11:54pm, D. J. Bernstein wrote: } Subject: Re: best name for followups? } } A subscriber sends a message to a mailing list. Someone follows up. } The response is sent to both the subscriber and the mailing list. } } A non-subscriber sends a message to a mailing list. Someone follows } up. The response is sent to the non-subscriber and the mailing list. Let's restate those two cases as: A subscriber sends a message to a mailing list. Some recipient uses the reply-using-destination-fields function of his user agent. The response is sent both to the subscriber and to the mailing list. A non-subscriber sends a message to a mailing list. Some recipient uses the reply-using-destination-fields function of his user agent. The response is sent to the non-subscriber and to the mailing list. Now we can all agree, I think, on this: } So the original author has to put some extra information into his header } to differentiate the two situations. There are three ways to approach this problem: 1. The originator who is on the mailing list can ask (not require) the recipients to omit him from the replies. 2. The originator who is NOT on the mailing list can ask the recipients to include him in the replies. 3. Both kinds of originators can suggest the full list of destinations to which the recipients should direct replies. } The obvious solution is a followup field. This would put control } directly in the hands of the original author, and it would be trivial to } implement. My question is what this field should be called. I agree with Keith that a followup field is not an obvious solution, and therefore that debating what to call it is premature. It is not obvious because: * It is introducing a new concept; reply-using-destination-fields is not the same as the traditional netnews concept of `followup'. * It requires UAs to restrict their reply-using-destination-fields behavior when it is present, rather than permitting them to extend their basic reply behavior when it is present. * It requires originators to supply too much information; they must not only suggest how recipients should deal with their own address, but must also suggest how to deal with all destination addresses. I don't think using Reply-To is a viable solution, because: * It requires UAs to restrict their reply-using-destination-fields behavior when it is present. Sounds familiar, but in this case it's worse, because it retroactively changes the interpretation of reply-using-destination-fields for messages sent long ago. * It requires originators to supply too much information (a generic problem with approach #3 above). * Mailing lists must stop rewriting Reply-To. List managers are not going to give up control over list policy (direct replies to the list or away from it) and Reply-To is the only way to influence a large number of existing user agents. So it does seem that a new differentiator is necessary, but I don't think `followup' is the obvious or correct one. The claimed benefits of `followup' are: * Gives control to the original author (but too much so). * Easy to implement (maybe). * Existing UAs support the concept (but they don't, really). * No transition problem from current practice. Here's an alternative which I think betters `followup' on every one of those points: Define a `Reply-Cc' field, with the semantics that the address(es) in the Reply-Cc field should be copied to the Cc field of the reply; the semantics of all existing fields remain unchanged, except of course that the presence of Reply-To does not exclude the Reply-Cc. Gives control to the original author: In approach #1, the originator places the address of the mailing list in Reply-To and omits Reply-Cc. In approach #2, the originator places his own address in Reply-Cc and does whatever he likes with Reply-To. Using both provides approach #3. Easy to implement: Many UAs can begin sending it immediately. Simple rule for what to do with the addresses when constructing a reply. Existing UAs support the concept: Every UA has replies and Cc fields, and every user knows what they mean. Nothing new to learn. No transition problem: `Reply-using-destination-fields' behaviors are completely unchanged. As support spreads, users can use `reply' instead, even in mailing-list circumstances to get `followup'-like behavior, and thereby reduce duplications. List servers don't have to change. There's probably even some mailer out there somewhere that already has a Reply-Cc field that works this way. A final remark: This whole debate could have been avoided by dumping the term `followup'. Call the silly thing `Reply-Destinations' and stick with the concept of `reply'. That doesn't solve any of the other problems with it, but at least Dan can stop pretending that he and Keith don't understand each other. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Wed Jul 9 06:57:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA08767 for ietf-822-bks; Wed, 9 Jul 1997 06:57:07 -0700 (PDT) Received: from transarc.com (transarc.com [192.54.226.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id GAA08760 for ; Wed, 9 Jul 1997 06:57:02 -0700 (PDT) Received: by transarc.com (5.54/3.15) id for ietf-822@imc.org; Wed, 9 Jul 97 09:59:38 EDT Received: via switchmail; Wed, 9 Jul 1997 09:59:38 -0400 (EDT) Received: from bigbend.transarc.com via qmail ID ; Wed, 9 Jul 1997 09:58:37 -0400 (EDT) Received: from bigbend.transarc.com via qmail ID ; Wed, 9 Jul 1997 09:58:25 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.bigbend.transarc.com.sun4c.53 via MS.5.6.bigbend.transarc.com.sun4_51; Wed, 9 Jul 1997 09:58:13 -0400 (EDT) Message-Id: Date: Wed, 9 Jul 1997 09:58:13 -0400 (EDT) From: Craig_Everhart@transarc.com To: ietf-822@imc.org Subject: Re: best name for followups? In-Reply-To: <970709014614.ZM10044@candle.brasslantern.com> References: <19970708235412.9268.qmail@koobera.math.uic.edu> <970709014614.ZM10044@candle.brasslantern.com> Sender: owner-ietf-822@imc.org Precedence: bulk Thank you, thank you for applying more light and less heat to this discussion. And particularly for an actual proposal that looks like forward progress! Excerpts from transarc.system.ietf-822: 9-Jul-97 Re: best name for followups? "Bart Schaefer"@candle.b (5133*) > Here's an alternative which I think betters `followup' on every one of > those points: Define a `Reply-Cc' field, with the semantics that the > address(es) in the Reply-Cc field should be copied to the Cc field of > the reply; the semantics of all existing fields remain unchanged, except > of course that the presence of Reply-To does not exclude the Reply-Cc. > Gives control to the original author: In approach #1, the originator > places the address of the mailing list in Reply-To and omits Reply-Cc. > In approach #2, the originator places his own address in Reply-Cc and > does whatever he likes with Reply-To. Using both provides approach #3. Sounds perfect. Craig From owner-ietf-822 Wed Jul 9 08:50:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA10508 for ietf-822-bks; Wed, 9 Jul 1997 08:50:31 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA10500 for ; Wed, 9 Jul 1997 08:50:25 -0700 (PDT) Received: (qmail 16451 invoked by uid 666); 9 Jul 1997 16:01:41 -0000 Date: 9 Jul 1997 16:01:41 -0000 Message-ID: <19970709160141.16450.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > Keith's proposal is to use Reply-To to control replies, and to ignore > the concept of followups entirely. I know that _Keith_ is ignoring the concept of followups. However, _MUAs_ already have the concept, and they're not going to throw it away. > I don't think it's useful to apply the netnews concept of `followup' to the > common email UA function of `reply using From + To + Cc'. Until I hear better terminology, I'm going to continue to use ``reply'' and ``followup'' as generic terms for the two response functions in existing MUAs. > Actually, none of them are following 4.4.4 when they do `reply to all', You misunderstand. Keith is proposing a change in _replies_, not just followups. The relevant part of 4.4.4 is the third bulleted item: when Reply-To exists, it replaces From as the target of replies. Keith proposes using From whether or not Reply-To exists. Whenever From and Reply-To are different---e.g., a secretary sending a message for the boss---Keith's change in semantics poses an impossible transition problem. The only way for users to retain control over replies is to copy Reply-To into From, violating the RFC 822 From semantics. > Even if you grant dispensation for common practice, Perhaps you should read RFC 822. It explicitly recognizes that MUAs can provide additional response facilities. > I happen to think it's useful enough extended functionality that it ought > to be recognized by the standards; Standards? I'm talking about reality, not the IETF. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 9 09:42:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA11223 for ietf-822-bks; Wed, 9 Jul 1997 09:42:09 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA11219 for ; Wed, 9 Jul 1997 09:42:06 -0700 (PDT) Received: (qmail 16746 invoked by uid 666); 9 Jul 1997 16:53:22 -0000 Date: 9 Jul 1997 16:53:22 -0000 Message-ID: <19970709165322.16745.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk [ criticism of a followup field ] > * It is introducing a new concept; It is working with the concept that already exists in dozens of MUAs. The big problem, as is obvious from this discussion, is coming up with a good name. > * It requires UAs to restrict their reply-using-destination-fields > behavior when it is present, Yes, it's a change in the followup behavior. That's the whole point. > rather than permitting them to extend > their basic reply behavior when it is present. I don't understand. Do you have some specific change in mind? How does it conflict with a change in followup behavior? Hmmm. I get the feeling that you think I'm talking about writing a spec. I'm not. I'm talking about changing the behavior of real MUAs. The only relevant people are MUA implementors. > * It requires originators to supply too much information; they must > not only suggest how recipients should deal with their own address, > but must also suggest how to deal with all destination addresses. Why is this a problem? Could you give a specific example where the originator would have trouble coming up with the information? The followup field is the same as From+To+Cc by default. The MUA can automatically remove the From address if it knows that the user is on a mailing list shown in To+Cc. The followup field is copied into subsequent followups. [ new proposal ] > Here's an alternative which I think betters `followup' on every one of > those points: Define a `Reply-Cc' field, with the semantics that the > address(es) in the Reply-Cc field should be copied to the Cc field of > the reply; Later you make clear that you're proposing a change purely in reply behavior, not in followup behavior. Replies are typically sent to Reply-To defaulting to From. You're saying that they should be sent to Reply-To+Reply-Cc defaulting to From. Right? Aside from Reply-To munging and the difference between To and Cc, your proposal adds no new capabilities. A user can simply merge your Reply-Cc into Reply-To to obtain the same results. Your real proposal is the same as Keith's: you want to put the mailing list into Reply-To, and the sender's personal reply address into From. You expect MUAs to have a respond-to-From-ignoring-Reply-To function. Right? ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 9 10:26:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA11870 for ietf-822-bks; Wed, 9 Jul 1997 10:26:16 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA11856 for ; Wed, 9 Jul 1997 10:26:09 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id KAA12146 for ietf-822@imc.org; Wed, 9 Jul 1997 10:28:42 -0700 From: "Bart Schaefer" Message-Id: <970709102841.ZM12145@candle.brasslantern.com> Date: Wed, 9 Jul 1997 10:28:41 -0700 In-Reply-To: <19970709160141.16450.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: best name for followups?" (Jul 9, 4:01pm) References: <19970709160141.16450.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: best name for followups? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 9, 4:01pm, D. J. Bernstein wrote: } Subject: Re: best name for followups? } } Until I hear better terminology, I'm going to continue to use ``reply'' } and ``followup'' as generic terms for the two response functions in } existing MUAs. I hope you enjoy talking to yourself, then. } > Actually, none of them are following 4.4.4 when they do `reply to all', } } You misunderstand. Keith is proposing a change in _replies_, not just } followups. What's the connection between that and whether UAs are following 4.4.4? } The relevant part of 4.4.4 is the third bulleted item: You'll note that I had quoted that specific item. } when Reply-To exists, it replaces From as the target of replies. When Reply-To exists, it replaces From when automatically generating address lists from originator fields, yes. } Keith proposes using From whether or not Reply-To exists. I've seen no evidence that this is what Keith proposes, other than your willful misrepresentations. Based on what Keith has written, I interpret his proposal as "never use the contents of destination fields to generate reply addresses when a Reply-To header is present." This does not imply "always use From." Keith does also propose "don't send a Reply-To field when that isn't what you mean," but that's a recommendation for originators, not a change for responders. } > Even if you grant dispensation for common practice, } } Perhaps you should read RFC 822. It explicitly recognizes that MUAs can } provide additional response facilities. You refer to this text: This recommendation is intended only for automated use of originator-fields and is not intended to suggest that replies may not also be sent to other recipients of messages. It is up to the respective mail-handling programs to decide what additional facilities will be provided. I agree that this supports the position that UAs should not be restricted from using destination fields to generate reply addresses. However, that undermines your own proposal as much as it does Keith's. It also supports, by the phrase "additional facilities," my assertion that `reply using From + To + Cc' is extended functionality and explicitly not covered (though also explicitly not prohibited) by 4.4.4. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Wed Jul 9 11:10:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA12551 for ietf-822-bks; Wed, 9 Jul 1997 11:10:04 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA12543 for ; Wed, 9 Jul 1997 11:09:57 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id LAA12289 for ietf-822@imc.org; Wed, 9 Jul 1997 11:12:32 -0700 From: "Bart Schaefer" Message-Id: <970709111231.ZM12288@candle.brasslantern.com> Date: Wed, 9 Jul 1997 11:12:31 -0700 In-Reply-To: <19970709165322.16745.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: best name for followups?" (Jul 9, 4:53pm) References: <19970709165322.16745.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: best name for followups? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 9, 4:53pm, D. J. Bernstein wrote: } Subject: Re: best name for followups? } } > * It requires UAs to restrict their reply-using-destination-fields } > behavior when it is present, } } Yes, it's a change in the followup behavior. That's the whole point. } } > rather than permitting them to extend } > their basic reply behavior when it is present. } } I don't understand. Do you have some specific change in mind? See below. } How does it conflict with a change in followup behavior? It doesn't conflict; I just don't believe that a change in reply-using- destination-fields is a good or likely thing. Even if it does change, the change is more likely to be that it becomes `reply using From + To + Cc + The-New-Field', which is exactly the opposite of what you want. Hence if you're going to add a new field, you might as well add a field that has fits that behavior to begin with. } Hmmm. I get the feeling that you think I'm talking about writing a spec. } I'm not. I'm talking about changing the behavior of real MUAs. The only } relevant people are MUA implementors. That's a lovely idea, but if you don't write a spec the chances approach zero of more than two different implementors agreeing on how it works. Look at all the odd edge conditions in reply-using-destination-fields. } > * It requires originators to supply too much information; they must } > not only suggest how recipients should deal with their own address, } > but must also suggest how to deal with all destination addresses. } } Why is this a problem? Could you give a specific example where the } originator would have trouble coming up with the information? The problem is not that the originator can't come up with the information. The problem is that the responding UA can't obey both the originator's recommendation and the responding user's instructions. The responding UA must either ignore the destination fields even when instructed (by the responding user) to include them, which I think is bad; or it must ignore the originator's recommendation when asked to do a simple reply. Skipping ahead for a bit: } Replies are typically sent to Reply-To defaulting to From. You're saying } that they should be sent to Reply-To+Reply-Cc defaulting to From. Right? Right so far. } Aside from Reply-To munging and the difference between To and Cc, your } proposal adds no new capabilities. A user can simply merge your Reply-Cc } into Reply-To to obtain the same results. Essentially correct; the minor difference being that Reply-Cc goes into the Cc field, not into To. In fact, it is exactly the intention that there are no new capabilities *except* the ability to bypass Reply-To munging. } Your real proposal is the same as Keith's: you want to put the mailing } list into Reply-To, and the sender's personal reply address into From. } You expect MUAs to have a respond-to-From-ignoring-Reply-To function. } Right? Completly wrong. To address the "followup problem," I want to put the sender's personal reply address into Reply-Cc if and only if he is not a member of the mailing list; if he is a member of the mailing list, I think the Reply-Cc should be left out entirely. What goes in Reply-To is whatever goes in Reply-To right now, munged however the list server munges it right now; I don't care. I expect MUAs to expand the `reply' function to mean `send to (Reply-To OR From) + Reply-Cc'. I expect `Reply-To' to continue to replace `From' as it does now. I further expect MUAs to expand `reply-using-destination-fields' to mean `send to (Reply-To OR From) + Reply-Cc + To + Cc'. However, I expect users to realize that `reply-using-destination-fields' is no longer the right thing to use to "follow up," because `reply' does what they want. That means I expect UAs that support Reply-Cc to stop making `reply to all' be the most-easily-accessed reply function. } Later you make clear that you're proposing a change purely in reply } behavior, not in followup behavior. It is correct that I do not propose to reduce reply-using-destination- fields behavior in any sense. } The followup field is the same as From+To+Cc by default. The MUA can } automatically remove the From address if it knows that the user is on a } mailing list shown in To+Cc. The followup field is copied into } subsequent followups. The Reply-Cc field is the same as From by default (simpler). The MUA can automatically remove the entire field if it knows the user is on a mailing list (simpler -- and the operation really is that the MUA can ADD the field if it does NOT know whether the user is on the mailing list, which means it works even in UAs that don't maintain that info). The Reply-Cc address is copied into the Cc of subsequent "followups." -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Wed Jul 9 11:47:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA12991 for ietf-822-bks; Wed, 9 Jul 1997 11:47:12 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA12986 for ; Wed, 9 Jul 1997 11:47:09 -0700 (PDT) Received: (qmail 18204 invoked by uid 666); 9 Jul 1997 18:58:23 -0000 Date: 9 Jul 1997 18:58:23 -0000 Message-ID: <19970709185823.18203.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Keith's proposal Sender: owner-ietf-822@imc.org Precedence: bulk > } Keith proposes using From whether or not Reply-To exists. > I've seen no evidence that this is what Keith proposes, Then you aren't paying attention. Here's Keith's proposal: > > > I don't really think there is a big need to allow a sender to > > > separately specify "reply to address-list X if you want to just reply > > > to me", and "reply to address-list Y if you want to followup". Even > > > for those times when this is needed, the author can use From for the > > > former, and Reply-to for the latter. (With Sender used to indicate the > > > author's "real" address) For this to work as described, the first function, reply-to-author, has to use From and ignore Reply-To. > other than your willful misrepresentations. Idiot. > Based on what Keith has written, I interpret his proposal Hint for the clueless: You have to read it before you can interpret it. [ RFC 822 4.4.4 ] > However, that undermines your own proposal as much as it does Keith's. Don't be ridiculous. Nothing in RFC 822 ``undermines'' the use of new header fields for extended functions. In fact, extension fields and user-defined fields are explicitly permitted. Keith's proposal is different. He's changing the semantics of Reply-To and From, with no label to indicate the change. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 9 12:01:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA13180 for ietf-822-bks; Wed, 9 Jul 1997 12:01:34 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA13176 for ; Wed, 9 Jul 1997 12:01:30 -0700 (PDT) Received: from black-ice.cc.vt.edu (localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.8.6/8.8.6) with ESMTP id PAA18606; Wed, 9 Jul 1997 15:04:03 -0400 Message-Id: <199707091904.PAA18606@black-ice.cc.vt.edu> To: "D. J. Bernstein" Cc: ietf-822@imc.org Subject: Re: best name for followups? In-Reply-To: Your message of "09 Jul 1997 16:53:22 -0000." <19970709165322.16745.qmail@koobera.math.uic.edu> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1610773032P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 09 Jul 1997 15:04:02 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_1610773032P Content-Type: text/plain; charset=us-ascii On 09 Jul 1997 16:53:22 -0000, you said: > Hmmm. I get the feeling that you think I'm talking about writing a spec. > I'm not. I'm talking about changing the behavior of real MUAs. The only > relevant people are MUA implementors. I'm (somewhat) an MUA implementor (I guess.. I hack at exmh source a lot ;) So yes, changing the behavior of the MUA is relevant to me. On the other hand, if my wife has me upgrade her copy of Eudora Lite, and it acts differently, that's certainly relevant to *HER*. So - does anybody have a good "feel" for what the *USERS* want? I admit skimming the beginning of the discussion - is this something that is being pondered by us implementors, or are there users saying "gee it would be nice if" as well? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1610773032P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM8PgotQBOOoptg9JAQGhuAP+NgJoPQJVEoaG2Ag3qzXnHRyiMaGe2ibo 5thb3uwtKgXFi+Bv7XZOBrE8ReK7t3Fqt05FyV5lC3z3TMvvtNz8xmt/2gzYLkZj hc5PoHjMljBfrApyTwAGgfjVhOhEO3fbAUiShqwDnn9sqRx7UInmPC4s4bEqN3O7 1nYgtqiPbuw= =NV9k -----END PGP MESSAGE----- --==_Exmh_1610773032P-- From owner-ietf-822 Wed Jul 9 12:32:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA13611 for ietf-822-bks; Wed, 9 Jul 1997 12:32:08 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA13607 for ; Wed, 9 Jul 1997 12:32:04 -0700 (PDT) Received: (qmail 18731 invoked by uid 666); 9 Jul 1997 19:43:18 -0000 Date: 9 Jul 1997 19:43:18 -0000 Message-ID: <19970709194318.18730.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Bart's proposal Sender: owner-ietf-822@imc.org Precedence: bulk > The problem is that the responding UA can't obey both the originator's > recommendation and the responding user's instructions. Huh? I'm talking about convenient _default_ recipient lists. The user is of course free to send mail wherever he wants. > I expect MUAs to expand the `reply' function to mean `send to (Reply-To > OR From) + Reply-Cc'. [ ... ] > I further expect MUAs to expand `reply-using-destination-fields' to mean > `send to (Reply-To OR From) + Reply-Cc + To + Cc'. Okay, now I understand what you mean. Your proposal does not solve the fundamental problem: the reply-to-all addresses always include the reply-to-author addresses. Think about the usual case of a subscriber sending a message to a mailing list. He typically wants reply-to-all to go to the mailing list alone, while reply-to-author goes to him alone. This is impossible if the reply-to-author address is included in reply-to-all. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 9 13:10:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA13928 for ietf-822-bks; Wed, 9 Jul 1997 13:10:20 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA13924 for ; Wed, 9 Jul 1997 13:10:16 -0700 (PDT) Received: from black-ice.cc.vt.edu (localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.8.6/8.8.6) with ESMTP id QAA20962 for ; Wed, 9 Jul 1997 16:12:54 -0400 Message-Id: <199707092012.QAA20962@black-ice.cc.vt.edu> To: ietf-822@imc.org Subject: Re: Bart's proposal In-Reply-To: Your message of "09 Jul 1997 19:43:18 -0000." <19970709194318.18730.qmail@koobera.math.uic.edu> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-2007331864P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 09 Jul 1997 16:12:54 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_-2007331864P Content-Type: text/plain; charset=us-ascii On 09 Jul 1997 19:43:18 -0000, you said: > Think about the usual case of a subscriber sending a message to a > mailing list. He typically wants reply-to-all to go to the mailing list > alone, while reply-to-author goes to him alone. This is impossible if > the reply-to-author address is included in reply-to-all. Man. I've heard of "blond moments", but I must be having a truly blond week here. I've been sitting here wondering what this proposal was about, and following a long and headed discussion on the NAIPR list, and wondering why every time around, I was trimming more and more damned addresses off the cc: list. Finally sank in that they were One And The Same. ;) I take back what I said a few messages ago regarding whether users are asking for it. They are. ;) Now to go back and re-read all the postings, with the benefit of enlightenment ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-2007331864P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM8PwxtQBOOoptg9JAQGV7AP/WMhF5AWsUIazINR+87cx4YKd3RwoBRD9 DC/HWU1l/0u7/ABBYlF7ByKT5zJKBsv8J7vsO7zUIqkzcd4MvMUy/DZTzZO/JVZh BMwVkClEa/8VbcpGLmhp7CZTJsnzjjSR0kX23k/q11f9YzChrhZywHMA+EYPMHBo 1YMu7b9HRww= =6r6i -----END PGP MESSAGE----- --==_Exmh_-2007331864P-- From owner-ietf-822 Wed Jul 9 15:09:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA15479 for ietf-822-bks; Wed, 9 Jul 1997 15:09:53 -0700 (PDT) Received: from bar.pilsnet.sunet.se (bar.pilsnet.sunet.se [192.36.125.14]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA15475 for ; Wed, 9 Jul 1997 15:09:49 -0700 (PDT) Received: (from bygg@localhost) by bar.pilsnet.sunet.se (8.8.5/8.8.5) id AAA18528 for ietf-822@imc.org; Thu, 10 Jul 1997 00:12:23 +0200 (MET DST) Date: Thu, 10 Jul 1997 0:12:23 MET DST From: Johnny Eriksson To: ietf-822@imc.org Subject: Re: Keith's proposal In-Reply-To: Your message of 9 Jul 1997 18:58:23 -0000 Message-ID: Sender: owner-ietf-822@imc.org Precedence: bulk In reply to (?) message from "D. J. Bernstein" : > > other than your willful misrepresentations. > > Idiot. Dan, your manners are worse than mine. That means a *very* *low* level, and that this discussion can no longer be regarded as technical. > ---Dan --Johnny From owner-ietf-822 Wed Jul 9 16:37:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA16606 for ietf-822-bks; Wed, 9 Jul 1997 16:37:48 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA16602 for ; Wed, 9 Jul 1997 16:37:44 -0700 (PDT) Received: (qmail 20269 invoked by uid 666); 9 Jul 1997 23:49:02 -0000 Date: 9 Jul 1997 23:49:02 -0000 Message-ID: <19970709234902.20268.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > So - does anybody have a good "feel" for what the *USERS* want? Well, I'd recommend that everybody consult http://www.unicom.com/FAQ/reply-to-harmful.html and http://www.unicom.com/BBS/bbs_forum.cgi?forum=replyto I started this discussion after reading the latter page. I had always perceived followup duplication as an annoyance, but I hadn't realized that it motivated people to munge reply-to. I've set up a page describing the proposal for future reference: http://pobox.com/~djb/replyto.html ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 9 23:01:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA19442 for ietf-822-bks; Wed, 9 Jul 1997 23:01:53 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA19437 for ; Wed, 9 Jul 1997 23:01:48 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id XAA14643 for ietf-822@imc.org; Wed, 9 Jul 1997 23:04:25 -0700 From: "Bart Schaefer" Message-Id: <970709230424.ZM14642@candle.brasslantern.com> Date: Wed, 9 Jul 1997 23:04:24 -0700 X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: best name for followups? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk [ I apologize for being unable to properly "thread" this reply. My ISP decided to spend today moving mail to another machine, and broke all the deliveries for my domain in the process. I'm replying by looking at the ietf-822 archive from www.imc.org. ] On 9 Jul 1997, D. J. Bernstein (djb@koobera.math.uic.edu) wrote: } } ... you aren't paying attention. Here's Keith's proposal: } } > > > I don't really think there is a big need to allow a sender to } > > > separately specify "reply to address-list X if you want to just reply } > > > to me", and "reply to address-list Y if you want to followup". Even } > > > for those times when this is needed, the author can use From for the } > > > former, and Reply-to for the latter. (With Sender used to indicate the } > > > author's "real" address) } } For this to work as described, the first function, reply-to-author, has } to use From and ignore Reply-To. I'm not the one not paying attention. For this to work as described, two things are required: First, the author has to change From and leave out the Reply-To when he means "reply to address-list X if you want to just reply to me" and he must put in Reply-To exactly when he means "reply to address-list Y if you want to followup." The fields look like this: Replies to address-list X to reply to me (case 1): From: X Sender: To: Replies to address-list Y to follow up (case 2): From: Reply-To: Y To: The second thing required is that user agents interpret Reply-To in such a way that *neither* `reply' nor `reply-using-destination-fields' takes any addresses from the To field in the event that Reply-To is present. The quote from Keith that explains this second requirement is: >>>I realize that many UAs don't handle "reply-to-all" this way, >>>in particular a lot of UAs use Reply-to only as a replacement for From. >>>But the DRUMS document already clarifies that reply-to is the author's >>>preference as to where replies should be sent. See . So in case 1, you get reply --> To: X (a) reply-using-destination-fields --> To: X, and in case 2 you get reply --> To: Y (b) reply-using-destination-fields --> To: Y The argument, which I acknowledge that you don't accept, is that (b) is not a change from RFC822, 4.4.4, because 4.4.4 never sanctioned (a) in the first place. Regardless of whether it's a change from 822, in both your proposal and Keith's it is reply-using-destination-fields that must change in all user agents. } > other than your willful misrepresentations. } } Idiot. Yet another willful misrepresentation. } [ RFC 822 4.4.4 ] } > However, that undermines your own proposal as much as it does Keith's. } } Don't be ridiculous. Nothing in RFC 822 ``undermines'' the use of new } header fields for extended functions. In fact, extension fields and } user-defined fields are explicitly permitted. Ah, but the effect of your proposal is the same as Keith's -- the reply- using-destination-fields function will no longer use all the possible destination fields. You can't use 4.4.4 against one but not the other. } Keith's proposal is different. He's changing the semantics of Reply-To } and From, with no label to indicate the change. He's not changing the semantics; he's merely asking that the existing semantics be enforced more strictly. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Wed Jul 9 23:30:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA19630 for ietf-822-bks; Wed, 9 Jul 1997 23:30:14 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA19626 for ; Wed, 9 Jul 1997 23:30:09 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id CAA24436; Thu, 10 Jul 1997 02:32:36 -0400 (EDT) Message-Id: <199707100632.CAA24436@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bart Schaefer" cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: best name for followups? In-reply-to: Your message of "Wed, 09 Jul 1997 01:46:14 PDT." <970709014614.ZM10044@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jul 1997 02:32:36 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > I don't think using Reply-To is a viable solution, because: > * It requires UAs to restrict their reply-using-destination-fields > behavior when it is present. Sounds familiar, but in this case > it's worse, because it retroactively changes the interpretation of > reply-using-destination-fields for messages sent long ago. Actually I believe that UAs should encourage people to *select* the recipient list of *every* reply which would otherwise be addressed to more than one recipient. Of course, they should make the recipient (the one issuing the reply) aware of the sender's preference, as expressed through the reply-to field from the subject message. This requires a drastically different user interface than for most existing UAs, but it's the only way I see to address *the* real reply-to problem (as I define it): people don't stop to notice where their email replies are going. It's an open question as to whether UAs that encourage such behavior can be successful in the market...users would probably rather be lazy than aware, even if they occasionally get bitten for being lazy. > * Mailing lists must stop rewriting Reply-To. List managers are not > going to give up control over list policy (direct replies to the > list or away from it) and Reply-To is the only way to influence a > large number of existing user agents. Old mailing lists are unlikely to change their policies, but new ones can adopt new policies. And some list software can provide new defaults for new subscribers, while retaining the same reply-to munging settings for old ones. Both of these have happened before. At any rate, I suspect we're going to end up with some sort of List-Address or List-Reply-To header, along with List-Subscribe, List-Unsubscribe etc. It's easy to do, and there was a lot of support for it at the listhdr BOF at the Memphis IETF. > So it does seem that a new differentiator is necessary, but I don't think > `followup' is the obvious or correct one. > > The claimed benefits of `followup' are: > * Gives control to the original author (but too much so). > * Easy to implement (maybe). > * Existing UAs support the concept (but they don't, really). > * No transition problem from current practice. > > Here's an alternative which I think betters `followup' on every one of > those points: Define a `Reply-Cc' field, with the semantics that the > address(es) in the Reply-Cc field should be copied to the Cc field of > the reply; the semantics of all existing fields remain unchanged, except > of course that the presence of Reply-To does not exclude the Reply-Cc. I don't think this solves the problem Dan was complaining about, which is that people get multiple copies of a reply if multiple addresses that reach them appear in the header of the subject message. [ Apologies if the following proposal is like mail-copies-to. I haven't seen a definition of that header, so I can't evaluate it. If the thing is actually deployed, and someone knows how it works, they might consider sending a description to Jacob Palme for inclusion in the eventual successor to RFC 2076. anyway... ] I thought about proposing a header of the form Dont-Reply-To: if-replying-to which essentially says: if you're sending a reply which would otherwise be addressed to both X@foo.com and address y@bar.com, leave x@foo.com out of the recipient list of that reply. So if person X@foo.com is a member of the list y@bar.com, he could include such a header in his mail to y@bar.com. User agents would then know to omit X@foo.com (from both header and envelope) in any reply containing y@bar.com, and x@foo.com would only get one copy of the reply -- the one from the list. pros/cons/{mis,}features: + It doesn't change the user interface for the guy issuing the reply. He just says 'reply' or "reply to author" or reply to author+to+cc or whatever he says now, and the user agent does this, but leaving out the redundant addresses. - It does require the sender's UA to be smart about when to add the Dont-reply-to header on outgoing mail. - It opens the possibility of loops: what does a UA do if it sees Dont-reply-to: if-replying-to Dont-reply-to: if-replying-to Dont-reply-to: if-replying-to In this case, it's safe to ignore all of the headers. - There's nothing to stop lists from munging this header. Some lists might want to be "smart" and add Dont-Reply-To headers for any message sent from a list member. Some people would like this, since they'd get the benefits of Dont-Reply-To without having to change their UA. Some people (like me) wouldn't want the list to add such a header. Unless the Dont-Reply-To spec clearly stated whether lists could mung the header, some would do so and others would not. (yeech) - It doesn't solve the two-list problem (if you're a member of two lists and a message is addressed to both lists, you'll still get two copies). (Duplicate suppression at the recipient's UA does tend to solve this problem, as long as neither list mungs the message too much.) - It doesn't solve the general reply-to problem: people don't notice or think about where their replies are going. Personally, I don't think it's worth it: there's not enough to be gained for the trouble, and duplicate suppression is more effective (solves the problem in more cases) and easier to deploy (only requires support for the recipient who wants to suppress multiple messages, and that recipient reaps the reward for his own effort). If more UAs had duplicate suppression there would be very minimal additional gain to be had from Dont-Reply-To or similar proposals. (Dan claims that after enough replies from different people, the recipeint lists get so long that mail sofware breaks. While this is true in principle, I've never seen it happen in practice. I've seen software break due to long recipient lists, but never because of a recipient list created by too many replies to too many different people. Even IETF list threads don't go on for that long. And its easier to fix the mailers that break with long recipient lists than it is to fix mailers to support some new header and/or new functionality.) Keith From owner-ietf-822 Wed Jul 9 23:45:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA19783 for ietf-822-bks; Wed, 9 Jul 1997 23:45:33 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA19779 for ; Wed, 9 Jul 1997 23:45:26 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id XAA14787 for ietf-822@imc.org; Wed, 9 Jul 1997 23:48:03 -0700 From: "Bart Schaefer" Message-Id: <970709234802.ZM14786@candle.brasslantern.com> Date: Wed, 9 Jul 1997 23:48:02 -0700 X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Bart's proposal MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk [ Again I'm cutting and pasting from the imc archive. ] On 9 Jul 1997, D. J. Bernstein (djb@koobera.math.uic.edu) wrote: } Your proposal does not solve the fundamental problem: the reply-to-all } addresses always include the reply-to-author addresses. } } Think about the usual case of a subscriber sending a message to a } mailing list. He typically wants reply-to-all to go to the mailing list } alone, while reply-to-author goes to him alone. This is impossible if } the reply-to-author address is included in reply-to-all. I disagree on what the fundamental problem is. The fundamental problem is NOT the behavior of reply-to-all. The *really* fundamental problem is that reply-to-all is the wrong function to be using in the first place. The only reason that reply-to-all gets used, aside from the Berkeley Mail historical baggage of the meanings of `r' and `R' as commands, is because the simple reply function is unable to produce the correct result. Rather than attempting to get all MUAs to redefine reply-to-all to do a less-inclusive thing, which I find unlikely, let's get them to redefine simple reply to do a more inclusive thing, wherein the author of the message being replied to gets to define what is included. Yes, this COULD be done today with Reply-To IF mailing-list servers didn't munge it. But given the reality of mailing-list servers, Reply-To is not a reasonable choice. That is the entirety of my proposal. } I'm talking about convenient _default_ recipient lists. The user is } of course free to send mail wherever he wants. I'm talking about convenient default recipient lists, too. The basic reply command ought to be where one gets those convenient defaults. Reply-to-all ought to be the way the user sends mail wherever he wants (e.g., find all the possible addresses for me, and let me edit some of them out). There is no proposal that solves the reply-to-all problem without requiring a change to MUAs. Keith's proposal (as we're calling it, since he hasn't actually pronounced either of us correct in our interpretations) would change the way MUAs implement reply-to-all, but doesn't introduce new syntax. That is good in some senses, but bad in that it changes the interpretation of old messages. Dan's proposal changes reply-to-all and labels the change with new syntax, but requires knowledge of mailing-list membership on the part of sending MUAs in order to operate conveniently. My proposal extends both reply and reply-to-all, labels the change, and requires no new knowledge in sending MUAs. Both Dan's and Keith's proposals change reply-to-all by limiting it to a subset of possible destination addresses. This is beneficial to recipients who don't want multiple copies, on the assumption that users continue to use reply-to-all. Dan's proposal encourages users to continue using reply-to-all, because a simple reply still won't do the job. I think this is unfortunate. My proposal (I believe) encourages users to switch to simple replies, and encourages MUA implementors to make simple reply be the convenient default. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Thu Jul 10 00:13:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA20068 for ietf-822-bks; Thu, 10 Jul 1997 00:13:23 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id AAA20064 for ; Thu, 10 Jul 1997 00:13:17 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id AAA14878; Thu, 10 Jul 1997 00:15:46 -0700 From: "Bart Schaefer" Message-Id: <970710001545.ZM14877@candle.brasslantern.com> Date: Thu, 10 Jul 1997 00:15:45 -0700 In-Reply-To: <199707100632.CAA24436@spot.cs.utk.edu> Comments: In reply to Keith Moore "Re: best name for followups?" (Jul 10, 2:32am) References: <199707100632.CAA24436@spot.cs.utk.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Keith Moore Subject: Re: best name for followups? Cc: ietf-822@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 10, 2:32am, Keith Moore wrote: } Subject: Re: best name for followups? } } Actually I believe that UAs should encourage people to *select* the } recipient list of *every* reply which would otherwise be addressed to } more than one recipient. Of course, they should make the recipient } (the one issuing the reply) aware of the sender's preference, as } expressed through the reply-to field from the subject message. That's all nice in the abstract, but I was just discussing this today with several of my co-workers, and they all agreed that they hate it when their UA asks them questions or requires that sort of extra action. They don't care that some of the recipients are getting multiple copies; they care that they can process their own mail very quickly with the absolute minimum number of clicks and keystrokes. } It's an open question as to whether UAs that encourage such behavior } can be successful in the market...users would probably rather be lazy } than aware, even if they occasionally get bitten for being lazy. You have the right of it there. The best thing is for UAs to get better at providing a complete, yet minimal, set of "default" addresses. } At any rate, I suspect we're going to end up with some sort of } List-Address or List-Reply-To header, along with List-Subscribe, } List-Unsubscribe etc. It's easy to do, and there was a lot of support } for it at the listhdr BOF at the Memphis IETF. I see how this might solve the multiple-copies problem for those who are on the list. How does it solve the lack-of-any-copy problem for those who are NOT on the list? } I thought about proposing a header of the form } } Dont-Reply-To: if-replying-to I think this is nasty from the user interface point of view, because of the very effect that you give as its first advantage: } + It doesn't change the user interface for the guy issuing the } reply. He just says 'reply' or "reply to author" or reply to } author+to+cc or whatever he says now, and the user agent does } this, but leaving out the redundant addresses. Just because users generally don't notice where replies are going doesn't mean that they never notice. Some user is going to see two messages that appear to be identical -- they have the same To/From/Cc -- but then when he replies to one of them, the To address is NOT included, yet when he replies to the other, that same address in the same field IS included. How does the UA explain that inconsistency? By showing the user that horrible-looking header? Please no. The inconsistency and having that header visible would both be nightmares; I can't decide which is worse. } - There's nothing to stop lists from munging this header. There's also nothing to stop MTAs from munging other headers, so that it becomes necessary to equate with and other such lunacy. I think anything involving address comparisons is doomed to failure. } If more UAs had } duplicate suppression there would be very minimal additional gain to } be had from Dont-Reply-To or similar proposals. But duplicate suppression doesn't solve the lack-of-any-copy problem. There still needs to be a way to say "please DO send me a copy," and to do so without having the list server stomp on it. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Thu Jul 10 03:23:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id DAA23476 for ietf-822-bks; Thu, 10 Jul 1997 03:23:14 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id DAA23472 for ; Thu, 10 Jul 1997 03:23:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA07252 for ; Thu, 10 Jul 1997 03:25:20 -0700 (PDT) Received: from gimp ([205.217.227.11]) by dredd.mcom.com (Netscape Messaging Server 3.0) with SMTP id AAA1745 for ; Thu, 10 Jul 1997 03:25:18 -0700 Message-ID: <33C4B866.26172D75@netscape.com> Date: Thu, 10 Jul 1997 03:24:38 -0700 From: Jamie Zawinski Organization: Netscape Communications Corporation, Mozilla Division X-Mailer: Mozilla 3.02 (X11; U; IRIX 6.2 IP22) MIME-Version: 1.0 To: ietf-822@imc.org Subject: Re: best name for followups? References: <970709230424.ZM14642@candle.brasslantern.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk Bart Schaefer wrote: > > The fundamental problem is NOT the behavior of reply-to-all. The > *really* fundamental problem is that reply-to-all is the wrong > function to be using in the first place. The only reason that > reply-to-all gets used, aside from the Berkeley Mail historical > baggage of the meanings of `r' and `R' as commands, is because the > simple reply function is unable to produce the correct result. Huh? My MUA has two commands, "Reply to author" and "Reply to all". The former sends to (Reply-To -or- From) and the latter sends to ((Reply-To -or- From) -and- To -and- CC). I think this is the universally implemented status quo. I gather that Bart thinks this is wrong behavior, but this is that this is what -every- MUA I've ever seen does. And I really wish, given the vast installed base, the standard spelled this out. > } I'm talking about convenient _default_ recipient lists. The user is > } of course free to send mail wherever he wants. > > I'm talking about convenient default recipient lists, too. The basic > reply command ought to be where one gets those convenient defaults. > Reply-to-all ought to be the way the user sends mail wherever he wants > (e.g., find all the possible addresses for me, and let me edit some of > them out). Uh, I think now you're talking about a disjoint set of commands: "Reply to convenient default recipients" and "Reply to all listed addresses". I gather that you think the former list of addresses would be determined by some as-yet-unstandardized-or-otherwise- agreed-upon mechanism, and the latter would be something like (From + Reply-To + To + CC.) I think that's a monumentally bad idea. Aside from not being even close to the behavior I'd want to see in an MUA I was using (thanks, but reply-to-author and reply-to-recipients is exactly what I like) this would result in a confusing change to every existing MUA: there would still be two reply commands, but they'd be totally different ones than before; or worse, there'd be four distinct reply commands. Ugh! > For this to work as described, two things are required: First, the > author has to change From and leave out the Reply-To when he means > "reply to address-list X if you want to just reply to me" and he must > put in Reply-To exactly when he means "reply to address-list Y if you > want to followup." The fields look like this: > > Replies to address-list X to reply to me (case 1): > > From: X > Sender: > To: > > Replies to address-list Y to follow up (case 2): > > From: > Reply-To: Y > To: In that second case, this message has destroyed my ability to reply to just the author -- because every MUA in existence today has a command that replies to (Reply-To or From), and a command that replies to ((Reply-To -or- From) -and- To -and- CC), but no command that even gives me the *opportunity* to reply to From (if Reply-To is present.): that address would never appear in the defaultly-offered set of headers: one would have to put it there with cut and paste. Perhaps this is what the author of that hypothetical message intended. But if so, the author is a doofus. > The second thing required is that user agents interpret Reply-To in > such a way that *neither* `reply' nor `reply-using-destination-fields' > takes any addresses from the To field in the event that Reply-To is > present. That is already the status quo. Right? (For all four of the possible reply commands that have been mentioned, or at least, the two (possibly three) of them that have ever been implemented in the real world.) Someone, I guess Keith, wrote: > > I realize that many UAs don't handle "reply-to-all" this way, > in particular a lot of UAs use Reply-to only as a replacement for > From. But the DRUMS document already clarifies that reply-to is the > author's preference as to where replies should be sent. I haven't read the referred-to document, but for the sake of argument, I'll take your word for it that it says that a MUA's "reply to all recipients" command should reply to A: (Reply-To -or- (From -and- To -and- CC)) rather than the de-facto standard of B: ((Reply-to -or- From) -and- To -and- CC). But if it says that, then its authors are operating in a delusional fantasy world, because that's *not* going to happen. My reading of RFC 822 (and, I gather, Bart's reading?) is that it does not favor one over the other, as it talks only about the "reply to author" command, and not the "reply to all recipients" command, which it relegates to the status of "extension." Even if 822 *did* say that B was preferred to A, well, that's just too darned bad, because A got implemented and B did not, and if the standard is to mean anything, it should be made to say A. Unimplemented standards are useful as objets d'art, but little else. Any attempt to address either "duplicate suppression" or "default addresses for wide and narrow replies" (which are two totally different problems that people have been (badly) attempting to address using the Reply-To header) has to take this status quo into account if it hopes to get anywhere at all. Me, I'd much rather live with duplicates than have mailing lists fuck up my ability to reply to the author of a message without my "reply to author" command suddenly (and surprisingly) behaving like my "reply to all" command. I just don't see the duplicates problem as being much of a problem, nor do I see much of a need for a third reply-to-some- default-set-of-recipients command. But that's just me; if you want to standardize and implement them, more power to you -- just don't break or invalidate the installed base along the way! (I'm sure that there's a special circle in hell for mailing list managers who set the Reply-To field to point at the list.) -- Jamie Zawinski jwz@netscape.com http://www.netscape.com/people/jwz/ What the world needs now is killfiles that actually kill. -Craig Dickson From owner-ietf-822 Thu Jul 10 09:10:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA27551 for ietf-822-bks; Thu, 10 Jul 1997 09:10:54 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA27547 for ; Thu, 10 Jul 1997 09:10:50 -0700 (PDT) Received: (qmail 25903 invoked by uid 666); 10 Jul 1997 16:22:09 -0000 Date: 10 Jul 1997 16:22:09 -0000 Message-ID: <19970710162209.25901.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Bart's reading comprehension Sender: owner-ietf-822@imc.org Precedence: bulk > I'm not the one not paying attention. Keith said ``allow a sender to separately specify'' the reply-to-author address and the reply-to-all address. ``A sender.'' One sender. One message. ``Separately specify.'' That means specifying both. Keith explained that the author can use From for one and Reply-To for the other. So your examples are completely wrong. Here's what Keith described: From: X (the reply-to-author address) Reply-To: Y (the reply-to-all address) As I said, this requires that reply-to-author ignore the From address. > } > other than your willful misrepresentations. > } Idiot. > Yet another willful misrepresentation. Idiot. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Thu Jul 10 09:19:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA27700 for ietf-822-bks; Thu, 10 Jul 1997 09:19:27 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA27694 for ; Thu, 10 Jul 1997 09:19:24 -0700 (PDT) Received: (qmail 25978 invoked by uid 666); 10 Jul 1997 16:30:43 -0000 Date: 10 Jul 1997 16:30:43 -0000 Message-ID: <19970710163043.25977.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > Dan claims that after enough replies from different people, the > recipeint lists get so long that mail sofware breaks. I pointed out that this, among other problems, happens _by default_. > While this is > true in principle, I've never seen it happen in practice. And you'd understand the reason if you had read my next paragraph: ``Of course, people don't let the header grow so much. They trim it down to just the list address. But this introduces some of the same problems as reply-to munging; for example, it destroys cross-posted discussions.'' ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Thu Jul 10 09:37:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA28076 for ietf-822-bks; Thu, 10 Jul 1997 09:37:11 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA28072 for ; Thu, 10 Jul 1997 09:37:08 -0700 (PDT) Received: (qmail 26091 invoked by uid 666); 10 Jul 1997 16:48:27 -0000 Date: 10 Jul 1997 16:48:27 -0000 Message-ID: <19970710164827.26090.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Bart's proposal Sender: owner-ietf-822@imc.org Precedence: bulk > Keith's proposal (as we're calling it, since he hasn't actually pronounced > either of us correct in our interpretations) would change the way MUAs > implement reply-to-all, but doesn't introduce new syntax. It would also change how MUAs implement reply-to-author, destroying the existing semantics of From and Reply-To. > Dan's proposal changes reply-to-all and labels the change with new syntax, > but requires knowledge of mailing-list membership on the part of sending > MUAs in order to operate conveniently. > My proposal extends both reply and reply-to-all, labels the change, and > requires no new knowledge in sending MUAs. Nonsense. Your proposed field requires the same knowledge to set up as mine does. The difference is that I preserve reply-to-author, while you destroy it. > Dan's proposal encourages users to continue using reply-to-all, because a > simple reply still won't do the job. I think this is unfortunate. Hey, Bart, did you know that your MUA has _two_ response functions? Perhaps you should learn how to use them. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Thu Jul 10 09:43:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA28171 for ietf-822-bks; Thu, 10 Jul 1997 09:43:22 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@ncs-22.nbn.com [199.4.66.22]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA28157 for ; Thu, 10 Jul 1997 09:43:14 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id JAA17214; Thu, 10 Jul 1997 09:44:48 -0700 From: "Bart Schaefer" Message-Id: <970710094448.ZM17213@candle.brasslantern.com> Date: Thu, 10 Jul 1997 09:44:48 -0700 In-Reply-To: <33C4B866.26172D75@netscape.com> Comments: In reply to Jamie Zawinski "Re: best name for followups?" (Jul 10, 3:24am) References: <970709230424.ZM14642@candle.brasslantern.com> <33C4B866.26172D75@netscape.com> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Jamie Zawinski , ietf-822@imc.org Subject: Re: best name for followups? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 10, 3:24am, Jamie Zawinski wrote: } Subject: Re: best name for followups? } } Bart Schaefer wrote: } > } > The fundamental problem is NOT the behavior of reply-to-all. The } > *really* fundamental problem is that reply-to-all is the wrong } > function to be using in the first place. } } My MUA has two commands, "Reply to author" and "Reply to all". } The former sends to (Reply-To -or- From) and the latter sends to } ((Reply-To -or- From) -and- To -and- CC). } } I think this is the universally implemented status quo. I gather } that Bart thinks this is wrong behavior, but this is that this is } what -every- MUA I've ever seen does. No, I don't think this is wrong behavior. I think this is right. What I think is wrong, is that reply-to-all is (a) the "most convenient" reply action in many UAs, and (b) necessary in too many circumstances, because of those headed for that special circle in hell you mentioned. } And I really wish, given the vast installed base, the standard } spelled this out. I agree with that, too. } > } I'm talking about convenient _default_ recipient lists. The user is } > } of course free to send mail wherever he wants. } > } > I'm talking about convenient default recipient lists, too. The basic } > reply command ought to be where one gets those convenient defaults. } > Reply-to-all ought to be the way the user sends mail wherever he wants } > (e.g., find all the possible addresses for me, and let me edit some of } > them out). } } Uh, I think now you're talking about a disjoint set of commands: } "Reply to convenient default recipients" and "Reply to all listed } addresses". I gather that you think the former list of addresses } would be determined by some as-yet-unstandardized-or-otherwise- } agreed-upon mechanism, and the latter would be something like } (From + Reply-To + To + CC.) In a world without mailing lists munging Reply-To, the former would be controlled by the originator with a header like From: Reply-To: To: And you'd get it when you invoke "reply-to-author". The latter would be reply-to-all as it is now, regardless of what the headers look like. I believe this is the correct behavior, and that the right solution is to bypass Reply-To munging in the simplest possible manner. I think the simplest manner is to add a new header that augments Reply-To, rather than adding a header that restricts reply-to-all. } [...] this would result in a confusing change to every } existing MUA: there would still be two reply commands, but they'd be } totally different ones than before; or worse, there'd be four distinct } reply commands. Ugh! No, I don't want the "new" commands to be totally different. I want them to be as nearly identical as possible to the current status quo. In the absence of the field that augments Reply-To, I want them to BE the status quo. } > Replies to address-list Y to follow up (case 2): } > } > From: } > Reply-To: Y } > To: } } In that second case, this message has destroyed my ability to reply to } just the author -- because every MUA in existence today has a command } that replies to (Reply-To or From), and a command that replies to } ((Reply-To -or- From) -and- To -and- CC), but no command that even gives } me the *opportunity* to reply to From (if Reply-To is present.) Actually, both Mush and Z-Mail will let you ignore the Reply-To header if you feel like it. They'll let you reply to the Dogs-Go-To-Heaven header if you tell them to. } Perhaps this is what the author of that hypothetical message intended. } But if so, the author is a doofus. You can call him names if you want, but that's the way RFC822 defines the mechanism for authors to control where replies go. To bad mailing lists made it insufficient. } > The second thing required is that user agents interpret Reply-To in } > such a way that *neither* `reply' nor `reply-using-destination-fields' } > takes any addresses from the To field in the event that Reply-To is } > present. } } That is already the status quo. Right? (For all four of the possible } reply commands that have been mentioned, or at least, the two (possibly } three) of them that have ever been implemented in the real world.) No, it's not the status quo. It's the status quo for `reply'. It is not the status quo for `reply-to-all'. The above describes the status quo for `reply', but (Reply-To -or- (From -and- To -and- CC)) for reply-all. (It describes that because I'm explaining Keith's proposal, which you got right a bit later.) } A: (Reply-To -or- (From -and- To -and- CC)) } B: ((Reply-to -or- From) -and- To -and- CC). } } My reading of RFC 822 (and, I gather, Bart's reading?) is that it does } not favor one over the other, as it talks only about the "reply to } author" command, and not the "reply to all recipients" command, which it } relegates to the status of "extension." Yup, that's my reading. } Even if 822 *did* say that B was preferred to A, well, that's just too } darned bad, because A got implemented and B did not [...] } } Any attempt to address either "duplicate suppression" or "default } addresses for wide and narrow replies" (which are two totally different } problems that people have been (badly) attempting to address using the } Reply-To header) has to take this status quo into account if it hopes to } get anywhere at all. I completely agree. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Thu Jul 10 10:05:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA28608 for ietf-822-bks; Thu, 10 Jul 1997 10:05:16 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@ncs-31.nbn.com [199.4.66.31]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA28598 for ; Thu, 10 Jul 1997 10:05:11 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id KAA17329 for ietf-822@imc.org; Thu, 10 Jul 1997 10:07:51 -0700 From: "Bart Schaefer" Message-Id: <970710100750.ZM17328@candle.brasslantern.com> Date: Thu, 10 Jul 1997 10:07:50 -0700 In-Reply-To: <19970710164827.26090.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Bart's proposal" (Jul 10, 4:48pm) References: <19970710164827.26090.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Bart's proposal MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 10, 4:48pm, D. J. Bernstein wrote: } Subject: Re: Bart's proposal } } > My proposal extends both reply and reply-to-all, labels the change, and } > requires no new knowledge in sending MUAs. } } Nonsense. Your proposed field requires the same knowledge to set up as } mine does. My proposal can be implemented (for example) as a `copy me on replies' toggle in the user interface. Switch it on, a Reply-Cc field is put in; switch it off, no Reply-Cc field is put in. Your proposal requires the UA to identify addresses that are mailing lists and include them in the Reply-Destinations (or whatever you call it) field. Only after that field is properly initialized with the addresses of all the mailing lists can the author be added or removed upon request. } The difference is that I preserve reply-to-author, while you destroy it. Destroy it how? If Reply-Cc contains the author's address but Reply-To does not (because the mailing list munged it), it seems to me that I'm preserving reply-to-author in a case where it presently is not preserved. } Hey, Bart, did you know that your MUA has _two_ response functions? } Perhaps you should learn how to use them. I could start sending you two copies of all these messages, but I thought you'd rather I didn't. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Thu Jul 10 10:41:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA29111 for ietf-822-bks; Thu, 10 Jul 1997 10:41:39 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id KAA29107 for ; Thu, 10 Jul 1997 10:41:36 -0700 (PDT) Received: (qmail 26854 invoked by uid 666); 10 Jul 1997 17:52:55 -0000 Date: 10 Jul 1997 17:52:55 -0000 Message-ID: <19970710175255.26853.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Bart's proposal Sender: owner-ietf-822@imc.org Precedence: bulk > My proposal can be implemented (for example) as a `copy me on replies' > toggle in the user interface. That would work with all of the proposals here. You claim that it is an advantage of your proposal; you are wrong. > Your proposal requires the UA to identify addresses that are mailing lists > and include them in the Reply-Destinations (or whatever you call it) field. Wrong. The correct algorithm is as follows. If the MUA knows that the user has subscribed to a mailing list shown in To+Cc, it automatically excludes him from subsequent followups. Otherwise it leaves him in. This, too, would work with all of the proposals here. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Thu Jul 10 11:22:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA29610 for ietf-822-bks; Thu, 10 Jul 1997 11:22:44 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA29606 for ; Thu, 10 Jul 1997 11:22:30 -0700 (PDT) Received: from black-ice.cc.vt.edu (localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.8.6/8.8.6) with ESMTP id OAA20364 for ; Thu, 10 Jul 1997 14:25:11 -0400 Message-Id: <199707101825.OAA20364@black-ice.cc.vt.edu> To: ietf-822@imc.org Subject: Some vendors Just Dont Get It. From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[; Thu, 10 Jul 1997 12:32:01 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id MAA17882 for ietf-822@imc.org; Thu, 10 Jul 1997 12:34:36 -0700 From: "Bart Schaefer" Message-Id: <970710123435.ZM17881@candle.brasslantern.com> Date: Thu, 10 Jul 1997 12:34:35 -0700 In-Reply-To: <19970710175255.26853.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Bart's proposal" (Jul 10, 5:52pm) References: <19970710175255.26853.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Bart's proposal MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 10, 5:52pm, D. J. Bernstein wrote: } Subject: Re: Bart's proposal } } > My proposal can be implemented (for example) as a `copy me on replies' } > toggle in the user interface. } } That would work with all of the proposals here. You claim that it is an } advantage of your proposal; you are wrong. It's not that specific item that I'm claiming as an advantage of my proposal; I explicitly said that your proposal could support this as well: >>after [Reply-Destinations] is properly initialized with the addresses of >>all the mailing lists [the author can] be added or removed upon request. } > Your proposal requires the UA to identify addresses that are mailing lists } > and include them in the Reply-Destinations (or whatever you call it) field. } } Wrong. The correct algorithm is as follows. If the MUA knows that the } user has subscribed to a mailing list shown in To+Cc, it automatically } excludes him from subsequent followups. Otherwise it leaves him in. And the rest of the algorithm is that every address in To and Cc is also duplicated in Reply-Destinations? Ok. Then the advantage of my proposal is that it doesn't duplicate all that information. That could also be a disadvantage if you assume that the Reply-Destinations field is less likely to be munged in transit than are the To and Cc fields. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Thu Jul 10 13:16:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA01293 for ietf-822-bks; Thu, 10 Jul 1997 13:16:46 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA01288 for ; Thu, 10 Jul 1997 13:16:42 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA27116; Thu, 10 Jul 1997 16:19:02 -0400 (EDT) Message-Id: <199707102019.QAA27116@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bart Schaefer" cc: Keith Moore , ietf-822@imc.org Subject: Re: best name for followups? In-reply-to: Your message of "Thu, 10 Jul 1997 00:15:45 PDT." <970710001545.ZM14877@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jul 1997 16:19:02 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > } Actually I believe that UAs should encourage people to *select* the > } recipient list of *every* reply which would otherwise be addressed to > } more than one recipient. Of course, they should make the recipient > } (the one issuing the reply) aware of the sender's preference, as > } expressed through the reply-to field from the subject message. > > That's all nice in the abstract, but I was just discussing this today > with several of my co-workers, and they all agreed that they hate it > when their UA asks them questions or requires that sort of extra action. Yeah, I hate it too. But I'm not sure that it can't be done in a way which is both convenient and effective. I'm imagining a reply interface where my UA pops up an editing window and shows me every recipient to which the reply might be addressed, with the "selected" recipients in normal text and the "unselected" recipients in dim/gray text. There might also be some sort of indication (color?) as to where the recipient address came from (From, To, Cc, Reply-To). The "reply" button would then pop up an editing window with the default set of recipients selected, but there would be buttons to select other behaviors (like reply-to-sender only), and I could click on any recipient to toggle the selected bit. Guess I'll have to code it up and try it... > } It's an open question as to whether UAs that encourage such behavior > } can be successful in the market...users would probably rather be lazy > } than aware, even if they occasionally get bitten for being lazy. > > You have the right of it there. The best thing is for UAs to get better at > providing a complete, yet minimal, set of "default" addresses. I'm not sure what this would mean. "Complete", for example, is highly dependent on the context in which a message is sent -- something the UA isn't likely to know about. > } At any rate, I suspect we're going to end up with some sort of > } List-Address or List-Reply-To header, along with List-Subscribe, > } List-Unsubscribe etc. It's easy to do, and there was a lot of support > } for it at the listhdr BOF at the Memphis IETF. > > I see how this might solve the multiple-copies problem for those who are > on the list. How does it solve the lack-of-any-copy problem for those > who are NOT on the list? It won't. But we'll probably end up with a List-Address header for other reasons. Once it's there, UAs will probably acquire "reply to list" commands. We should probably specify in the List-Address field defintiion that UAs MUST NOT use the List-Address field for the default reply. > } I thought about proposing a header of the form > } > } Dont-Reply-To: if-replying-to > > I think this is nasty from the user interface point of view, because of > the very effect that you give as its first advantage: > > } + It doesn't change the user interface for the guy issuing the > } reply. He just says 'reply' or "reply to author" or reply to > } author+to+cc or whatever he says now, and the user agent does > } this, but leaving out the redundant addresses. > > Just because users generally don't notice where replies are going doesn't > mean that they never notice. Some user is going to see two messages that > appear to be identical -- they have the same To/From/Cc -- but then when > he replies to one of them, the To address is NOT included, yet when he > replies to the other, that same address in the same field IS included. > > How does the UA explain that inconsistency? By showing the user that > horrible-looking header? Please no. The inconsistency and having that > header visible would both be nightmares; I can't decide which is worse. The only way to know is to test it. But the confusion doesn't seem (to me) to be any worse than that which would result from Followup-To or Reply-Cc. I agree that reply generation should be based on simple rules that a user can understand. Ideally they should be the same for most UAs. > } - There's nothing to stop lists from munging this header. > > There's also nothing to stop MTAs from munging other headers, so that > it becomes necessary to equate with and > other such lunacy. I think anything involving address comparisons is > doomed to failure. Good point. The rewriting situation is better than it used to be, (not so many sendmails rewrite addresses anymore), but it's common for firewalls to rewrite addresses to hide internal domains. > } If more UAs had > } duplicate suppression there would be very minimal additional gain to > } be had from Dont-Reply-To or similar proposals. > > But duplicate suppression doesn't solve the lack-of-any-copy problem. > There still needs to be a way to say "please DO send me a copy," and to > do so without having the list server stomp on it. By that logic, we can't solve the problem by adding a new header. There is almost no header that some list server or gateway won't stop on. Each of the following behaviors is, I believe, quite common: + adding or changing the sender header + adding a reply-to header + changing a sender-supplied reply-to header + removing certain headers (e.g. received) + removing all headers except those in a stop-list + adding headers (comments, x-list-*, precedence, errors-to) + rewriting header addresses (in to, from, cc headers) + munging the subject header + don't send me a copy of the list mail if I'm already in the to/cc header. On the other hand, if we can discourage certain of these behaviors, then it becomes reasonable to say something like "lists SHOULD NOT mung a sender-supplied Reply-To header", which in turn provides a way for a sender to say "please DO send me a copy of the reply" which is compatible with existing UAs. Keith From owner-ietf-822 Thu Jul 10 22:05:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA06343 for ietf-822-bks; Thu, 10 Jul 1997 22:05:43 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id WAA06339 for ; Thu, 10 Jul 1997 22:05:40 -0700 (PDT) Received: (qmail 1449 invoked by uid 666); 11 Jul 1997 05:17:03 -0000 Date: 11 Jul 1997 05:17:03 -0000 Message-ID: <19970711051703.1448.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Bart's reading comprehension Sender: owner-ietf-822@imc.org Precedence: bulk Correcting typo: : As I said, this requires that reply-to-author ignore the From address. That should say ``Reply-To address.'' ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Mon Jul 14 15:28:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA22048 for ietf-822-bks; Mon, 14 Jul 1997 15:28:24 -0700 (PDT) Received: from dkuug.dk (dkuug.dk [193.88.44.89]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA22043 for ; Mon, 14 Jul 1997 15:28:19 -0700 (PDT) Received: (from keld@localhost) by dkuug.dk (8.6.12/8.6.12) id AAA03562; Tue, 15 Jul 1997 00:30:54 +0200 Message-Id: <199707142230.AAA03562@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Tue, 15 Jul 1997 00:30:52 +0200 In-Reply-To: "Bart Schaefer" "Re: best name for followups?" (Jul 9, 9:48) X-Charset: ISO-8859-1 X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: "Bart Schaefer" , ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk "Bart Schaefer" writes: > On Jul 8, 11:54pm, D. J. Bernstein wrote: > } Subject: Re: best name for followups? My 2 cents: make a new command in UAs that replies to the to: field and the cc: field, (but not the from field) thus avoiding two messages sent to the author of the From: message. Keld From owner-ietf-822 Mon Jul 14 15:54:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA22314 for ietf-822-bks; Mon, 14 Jul 1997 15:54:01 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA22310 for ; Mon, 14 Jul 1997 15:53:57 -0700 (PDT) Received: (qmail 4103 invoked by uid 666); 14 Jul 1997 23:05:33 -0000 Date: 14 Jul 1997 23:05:33 -0000 Message-ID: <19970714230533.4102.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > My 2 cents: make a new command in UAs that replies to the > to: field and the cc: field, (but not the from field) > thus avoiding two messages sent to the author of the From: message. What if the author isn't included in To/Cc? For example, what if To is a mailing list, and From is a non-subscriber? How is a user supposed to decide whether to use the old reply-to-all command or your new reply-to-recipients command? ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Mon Jul 14 15:57:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA22343 for ietf-822-bks; Mon, 14 Jul 1997 15:57:10 -0700 (PDT) Received: from dkuug.dk (dkuug.dk [193.88.44.89]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA22339 for ; Mon, 14 Jul 1997 15:57:04 -0700 (PDT) Received: (from keld@localhost) by dkuug.dk (8.6.12/8.6.12) id AAA04230; Tue, 15 Jul 1997 00:59:47 +0200 Message-Id: <199707142259.AAA04230@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Tue, 15 Jul 1997 00:59:45 +0200 In-Reply-To: "Bart Schaefer" "Re: best name for followups?" (Jul 10, 8:17) X-Charset: ISO-8859-1 X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: "Bart Schaefer" , Keith Moore Subject: Re: best name for followups? Cc: ietf-822@imc.org Sender: owner-ietf-822@imc.org Precedence: bulk Further ideas to avoid looking at more than one copy of the same mail sent to multiple email exploders: 1. the MTA should look at all headers in the to: and cc: fields and if there is duplicates, then only send it once. 2. The MUA could look at messages and remove those occurring more than once. Keld From owner-ietf-822 Mon Jul 14 16:57:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA22876 for ietf-822-bks; Mon, 14 Jul 1997 16:57:28 -0700 (PDT) Received: from dkuug.dk (dkuug.dk [193.88.44.89]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA22872 for ; Mon, 14 Jul 1997 16:57:23 -0700 (PDT) Received: (from keld@localhost) by dkuug.dk (8.6.12/8.6.12) id CAA05927; Tue, 15 Jul 1997 02:00:16 +0200 Message-Id: <199707150000.CAA05927@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Tue, 15 Jul 1997 02:00:14 +0200 In-Reply-To: "D. J. Bernstein" "Re: best name for followups?" (Jul 14, 23:59) X-Charset: ISO-8859-1 X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: "D. J. Bernstein" , ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk "D. J. Bernstein" writes: > > My 2 cents: make a new command in UAs that replies to the > > to: field and the cc: field, (but not the from field) > > thus avoiding two messages sent to the author of the From: message. > > What if the author isn't included in To/Cc? > > For example, what if To is a mailing list, and From is a non-subscriber? > > How is a user supposed to decide whether to use the old reply-to-all > command or your new reply-to-recipients command? Well, if you know the author, and want to relieve him/her from getting extra mail, then you use the new command. Keld From owner-ietf-822 Mon Jul 14 17:09:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA23013 for ietf-822-bks; Mon, 14 Jul 1997 17:09:34 -0700 (PDT) Received: from glaucus.cso.uiuc.edu (glaucus.cso.uiuc.edu [128.174.81.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA23009 for ; Mon, 14 Jul 1997 17:09:31 -0700 (PDT) Received: from resnick1.isdn.uiuc.edu (resnick1.isdn.uiuc.edu [192.17.16.67]) by glaucus.cso.uiuc.edu (AIX4.2/UCB 8.7/8.7) with ESMTP id TAA11456 for ; Mon, 14 Jul 1997 19:09:17 -0500 (CDT) X-Sender: (Unverified) Message-Id: In-Reply-To: <199707100632.CAA24436@spot.cs.utk.edu> References: Your message of "Wed, 09 Jul 1997 01:46:14 PDT." <970709014614.ZM10044@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0a11-9.97] Date: Mon, 14 Jul 1997 19:09:27 -0500 To: ietf-822@imc.org From: Pete Resnick Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk On 7/10/97 at 1:32 AM -0500, Keith Moore wrote: >I thought about proposing a header of the form > >Dont-Reply-To: if-replying-to > >which essentially says: if you're sending a reply which would >otherwise be addressed to both X@foo.com and address y@bar.com, leave >x@foo.com out of the recipient list of that reply. I actually like this idea a bit better than a Followup-To field. It seems to me that Dont-Reply-To would be a bit easier to automate. We're talking about putting a feature into our mailer which keeps track of mailing lists to which the user is subscribed. With a Dont-Reply-To field, we could generate one of those if any of the recipients of the message were in the list of subscribed mailing lists. With the Followup-To, it's almost certainly going to have to be hand-edited by the sender: If the user replies to a message that *doesn't* have this header and there are some recipients who don't belong to the mailing list, it's not clear to me how to figure out whether or not it is a good thing to copy them into the Followup-To field or not. With Dont-Reply-To, you're giving explicit instruction to the remote mailer about what to do with a reply-to-all command. It just seems a little cleaner. It clearly doesn't have the fine-grained control to be able to redirect the thread to somewhere else, but I get the feeling that the more likely reason to use any of these headers is to say "don't send an extra copy to me". >- It does require the sender's UA to be smart about when to add the > Dont-reply-to header on outgoing mail. It could always be added by hand, but it makes it somewhat easier to add in an automated fashion. >- It opens the possibility of loops: what does a UA do if it sees > > Dont-reply-to: if-replying-to > Dont-reply-to: if-replying-to > Dont-reply-to: if-replying-to > > In this case, it's safe to ignore all of the headers. (*Shrug*) People can generate crappy headers all the time that screw up remote UAs. I know what a reasonable one of these is supposed to do. >- There's nothing to stop lists from munging this header. Some > lists might want to be "smart" and add Dont-Reply-To headers for > any message sent from a list member. Some people would like this, > since they'd get the benefits of Dont-Reply-To without having > to change their UA. Some people (like me) wouldn't want the list > to add such a header. I think this is less of a concern. Unlike current Reply-To munging, where the purpose is to be "helpful" to get discussion on the list, this header is "helpful" in the opposite direction. I'm not convinced list-admins are going to be as motivated to do this. >- It doesn't solve the two-list problem Neither does any other solution as far as I can tell. >Personally, I don't think it's worth it: there's not enough to be >gained for the trouble, and duplicate suppression is more effective >(solves the problem in more cases) and easier to deploy (only requires >support for the recipient who wants to suppress multiple messages, and >that recipient reaps the reward for his own effort). If more UAs had >duplicate suppression there would be very minimal additional gain to >be had from Dont-Reply-To or similar proposals. I don't think it's a bad idea, actually. Duplicate suppression is fine, but you still have to spend the time and resources receiving the duplicate messages. This way, the duplicate never even gets sent. I think it's worth thinking about. pr -- Pete Resnick QUALCOMM Incorporated Work: (217)337-6377 / Fax: (217)337-1980 From owner-ietf-822 Mon Jul 14 18:02:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA23395 for ietf-822-bks; Mon, 14 Jul 1997 18:02:50 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id SAA23391 for ; Mon, 14 Jul 1997 18:02:47 -0700 (PDT) Received: (qmail 5428 invoked by uid 666); 15 Jul 1997 01:14:18 -0000 Date: 15 Jul 1997 01:14:18 -0000 Message-ID: <19970715011418.5427.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > With the Followup-To, it's almost > certainly going to have to be hand-edited by the sender: http://pobox.com/~djb/replyto.html says how an MUA can automatically create this field. The only prerequisite is that your MUA know what mailing lists you're subscribed to. (The fundamental problem is obviously insoluble without this information.) > It seems to me that Dont-Reply-To would be a bit easier to automate. It would require substantially more code for the common case. I haven't seen any examples where the extra flexibility would be useful. KISS. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Mon Jul 14 18:12:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA23544 for ietf-822-bks; Mon, 14 Jul 1997 18:12:19 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id SAA23540 for ; Mon, 14 Jul 1997 18:12:15 -0700 (PDT) Received: (qmail 5812 invoked by uid 666); 15 Jul 1997 01:23:56 -0000 Date: 15 Jul 1997 01:23:56 -0000 Message-ID: <19970715012356.5811.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > Well, if you know the author, and want to relieve him/her from > getting extra mail, then you use the new command. What if the author isn't a subscriber? Now you've eliminated him from the recipient list. What if he wanted to receive a copy? The discussion is about how the author can express his wishes in a form that your MUA can use automatically. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Tue Jul 15 01:40:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA27389 for ietf-822-bks; Tue, 15 Jul 1997 01:40:15 -0700 (PDT) Received: from dkuug.dk (dkuug.dk [193.88.44.89]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA27379 for ; Tue, 15 Jul 1997 01:40:09 -0700 (PDT) Received: (from keld@localhost) by dkuug.dk (8.6.12/8.6.12) id KAA12257; Tue, 15 Jul 1997 10:42:58 +0200 Message-Id: <199707150842.KAA12257@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Tue, 15 Jul 1997 10:42:56 +0200 In-Reply-To: "D. J. Bernstein" "Re: best name for followups?" (Jul 15, 2:17) X-Charset: ISO-8859-1 X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: "D. J. Bernstein" , ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk "D. J. Bernstein" writes: > > Well, if you know the author, and want to relieve him/her from > > getting extra mail, then you use the new command. > > What if the author isn't a subscriber? Now you've eliminated him from > the recipient list. What if he wanted to receive a copy? Then you use the reply-all > The discussion is about how the author can express his wishes in a form > that your MUA can use automatically. I understand. But I am saying that with two simple MUA commands you may obtain much of the same results - given that you know as a user what you are doing and you know what the recipients are on each list. This is just based on my own experiences and irritations: 1. a MUA command responding to the To: and Cc: fields: "reply-receivers" "reply-recievers" is useful whan you know that the the sender is on the recievers-list too. 2. a MUA command responding to the To: field: "reply-to" The "reply-to" command is useful when you think that the cc-list is only for initial awareness, and further discussion is only for the people on the To: list Keld From owner-ietf-822 Tue Jul 15 01:42:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA27431 for ietf-822-bks; Tue, 15 Jul 1997 01:42:00 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id BAA27426 for ; Tue, 15 Jul 1997 01:41:56 -0700 (PDT) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.6/8.8.6) with ESMTP id EAA18346; Tue, 15 Jul 1997 04:44:38 -0400 Message-Id: <199707150844.EAA18346@black-ice.cc.vt.edu> To: keld@dkuug.dk (Keld J|rn Simonsen) cc: "Bart Schaefer" , Keith Moore , ietf-822@imc.org, valdis@black-ice.cc.vt.edu Subject: Re: best name for followups? In-reply-to: Your message of "Tue, 15 Jul 1997 00:59:45 +0200." <199707142259.AAA04230@dkuug.dk> From: Valdis.Kletnieks@vt.edu Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="" X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20900.868956277.1@black-ice.cc.vt.edu> Date: Tue, 15 Jul 1997 04:44:37 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk On Tue, 15 Jul 1997 00:59:45 +0200, Keld J|rn Simonsen said: > 1. the MTA should look at all headers in the to: and cc: fields > and if there is duplicates, then only send it once. Keld: How does the MTA distinguish duplicates for this message, which is going to dkuug.dk, brasslantern.com, utk.edy, imc.org, and a local copy to myself? To *my* MTA they all look distinct. And by the time it reaches any other MTA, it's too late. > 2. The MUA could look at messages and remove those occurring > more than once. Of course, we'd rather avoid having the MUA having to suppress 57 copies, after having *received* 57 copies over a possibly slow link, etc etc. ;) Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech From owner-ietf-822 Tue Jul 15 02:00:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id CAA27653 for ietf-822-bks; Tue, 15 Jul 1997 02:00:36 -0700 (PDT) Received: from dkuug.dk (dkuug.dk [193.88.44.89]) by mail.proper.com (8.8.5/8.7.3) with SMTP id CAA27649 for ; Tue, 15 Jul 1997 02:00:30 -0700 (PDT) Received: (from keld@localhost) by dkuug.dk (8.6.12/8.6.12) id LAA12570; Tue, 15 Jul 1997 11:03:06 +0200 Message-Id: <199707150903.LAA12570@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Tue, 15 Jul 1997 11:03:05 +0200 In-Reply-To: Valdis.Kletnieks@vt.edu "Re: best name for followups?" (Jul 15, 9:44) X-Charset: ISO-8859-1 X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Valdis.Kletnieks@vt.edu Subject: Re: best name for followups? Cc: "Bart Schaefer" , Keith Moore , ietf-822@imc.org, valdis@black-ice.cc.vt.edu Sender: owner-ietf-822@imc.org Precedence: bulk Valdis.Kletnieks@vt.edu writes: > On Tue, 15 Jul 1997 00:59:45 +0200, Keld J|rn Simonsen said: > > 1. the MTA should look at all headers in the to: and cc: fields > > and if there is duplicates, then only send it once. > > Keld: How does the MTA distinguish duplicates for this message, > which is going to dkuug.dk, brasslantern.com, utk.edy, imc.org, > and a local copy to myself? To *my* MTA they all look distinct. > And by the time it reaches any other MTA, it's too late. Of cause you cannot do it in that case, but if you see for example my address on the explicit From: or To: list, and later see the same address in the list data, you can avoid sending the latter. > > 2. The MUA could look at messages and remove those occurring > > more than once. > > Of course, we'd rather avoid having the MUA having to suppress > 57 copies, after having *received* 57 copies over a possibly slow link, > etc etc. ;) My time is much more expensive than the line costs. My proposals are not something that removes all problems, but they can make life easier, actually much easier, if employed. Keld From owner-ietf-822 Tue Jul 15 02:45:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id CAA29237 for ietf-822-bks; Tue, 15 Jul 1997 02:45:14 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id CAA29233 for ; Tue, 15 Jul 1997 02:45:10 -0700 (PDT) Received: (qmail 9437 invoked by uid 666); 15 Jul 1997 09:56:48 -0000 Date: 15 Jul 1997 09:56:48 -0000 Message-ID: <19970715095648.9436.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > But I am saying that with two simple MUA commands > you may obtain much of the same results My MUA already makes it very easy to manually edit the recipient list. But this completely misses the point. I _do not want_ to manually edit the recipient list. I want my MUA to provide the right list by default. The reason my MUA doesn't do this is much more basic than a mere matter of user interface design. There is a fundamental problem: _the necessary information is not available_. How does the MUA figure out the list? Saying ``make the choice manually''---putting the burden on me instead of my MUA---begs the question. How do _I_ figure out the list? Your proposal makes no progress towards an answer. > you know what the recipients are on each list. For large lists this is an unreasonable assumption. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Tue Jul 15 08:44:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA04243 for ietf-822-bks; Tue, 15 Jul 1997 08:44:50 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA04236 for ; Tue, 15 Jul 1997 08:44:45 -0700 (PDT) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.6/8.8.6) with ESMTP id LAA16100; Tue, 15 Jul 1997 11:47:37 -0400 Message-Id: <199707151547.LAA16100@black-ice.cc.vt.edu> To: keld@dkuug.dk (Keld J|rn Simonsen) Cc: ietf-822@imc.org Subject: Re: best name for followups? In-Reply-To: Your message of "Tue, 15 Jul 1997 11:03:05 +0200." <199707150903.LAA12570@dkuug.dk> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1011704128P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 15 Jul 1997 11:47:36 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_-1011704128P Content-Type: text/plain; charset=us-ascii On Tue, 15 Jul 1997 11:03:05 +0200, Keld J|rn Simonsen said: > Of cause you cannot do it in that case, but if you see > for example my address on the explicit From: or To: list, and later > see the same address in the list data, you can avoid sending the latter. Hmm.. I see Keld, I see Bart, I see Keith, I see some guy named ietf-822. I certainly don't see 'keld' *inside* the ietf-822 list, since I don't expand it. On Tue, 15 Jul 1997 10:42:56 +0200, Keld J|rn Simonsen said: >> What if the author isn't a subscriber? Now you've eliminated him from >> the recipient list. What if he wanted to receive a copy? >Then you use the reply-all This doesn't work if you don't have a *clue* who is on the list. Citing the mail for ietf-822 in the last few days (or rather, some that's in that folder), I know I'm on the list, I can be pretty sure that Keld Simonsen, D.J. Bernstein, and Keith Moore are on the list. However, I posted a note last week about "some vendors just don't get it", and I have *no* idea if Doug Strauss and Larry Osterman (both of Microsoft(*)) are on the list, or were merely forwarded a copy of my mail. In any case, there's something that everybody has overlooked (perhaps intentionally as a "we don't need to bother", or intentionally because it's a can of worms, or just oversight ;) What is the desired behavior if person A posts to a mailing list, and person B follows up, etc etc - and then person G replies to F, trims out persons A through E, and does a *BCC:* to the mailing list? (or vice versa - sending to the list, and a bcc: to the author because his list membership is unknown) Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech (*) Incidentally, the people at Microsoft were quite helpful in tracking down when/how the bug I commented on originated, and I assume that it is being chased down by their software teams. --==_Exmh_-1011704128P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM8ubl9QBOOoptg9JAQGpwQQAmHBxTXkr8L16veGyAaCSQ9kTsdSkZICt ci4L0LhwAOR/qSmzxyZZMOoitR5hNq6uH28zjyXi/11s7CCFd1Q9rTfSwoYuHBfR JztC664CDpuVL/A3AWqu4iGDF8QjhHcQkU0VleBeQkpugOYYk96Z4F+PW9D2Y2d5 3bkFjhWn+hE= =fek8 -----END PGP MESSAGE----- --==_Exmh_-1011704128P-- From owner-ietf-822 Tue Jul 15 14:28:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA10641 for ietf-822-bks; Tue, 15 Jul 1997 14:28:18 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA10635 for ; Tue, 15 Jul 1997 14:28:14 -0700 (PDT) Received: (qmail 16660 invoked by uid 666); 15 Jul 1997 21:39:58 -0000 Date: 15 Jul 1997 21:39:58 -0000 Message-ID: <19970715213958.16659.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > What is the desired behavior if person A posts to a mailing list, and person > B follows up, etc etc - and then person G replies to F, trims out persons > A through E, and does a *BCC:* to the mailing list? People do this as a crude way to control followups. Given widespread support for a followup field, why would someone do such a Bcc? The normal use of a blind copy is to add someone to the envelope recipient list, without affecting what the (non-blind) recipients see. So, in general, a Bcc isn't relevant to the rest of the header. > a bcc: to the author because his list membership is unknown That's arrogant behavior. Your followup is important enough to get to him, but subsequent followups aren't? Given widespread support for a followup field, you won't have to do this sort of guesswork. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 16 01:48:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA18019 for ietf-822-bks; Wed, 16 Jul 1997 01:48:33 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id BAA18015 for ; Wed, 16 Jul 1997 01:48:29 -0700 (PDT) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.6/8.8.6) with ESMTP id EAA23420 for ; Wed, 16 Jul 1997 04:51:32 -0400 Message-Id: <199707160851.EAA23420@black-ice.cc.vt.edu> To: ietf-822@imc.org Subject: Re: best name for followups? In-reply-to: Your message of "15 Jul 1997 21:39:58 -0000." <19970715213958.16659.qmail@koobera.math.uic.edu> From: Valdis.Kletnieks@vt.edu Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="" X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17782.869043091.1@black-ice.cc.vt.edu> Date: Wed, 16 Jul 1997 04:51:31 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk (Warning: 4:30Am rambling ahead ;) On 15 Jul 1997 21:39:58 -0000, you said: > > What is the desired behavior if person A posts to a mailing list, and person > > B follows up, etc etc - and then person G replies to F, trims out persons > > A through E, and does a *BCC:* to the mailing list? > > People do this as a crude way to control followups. Given widespread > support for a followup field, why would someone do such a Bcc? That's not the question I meant to ask. What I *meant* to ask was: Assuming even 90% of the MUAs are updated to support a followup field, how robust will it be if somebody in the 10% uses the bcc chainsaw instead? I see any algorithm that basically merges the from/to/cc's (with poissibly additional local knowledge) as being very crippled if a bcc attack occurs. On the other hand, a Followup: header will be a bit more robust - if the user's MUA doesn't support followup:, the header will likely not even be displayed by default, so naive users can nuke and bcc: to heart's content (at least in regards to "forward"ing a piece of mail. How robust does it *need* to be? Is "95% effective duplicate suppression" good enough? Or do we want to be hard-line, and design it so people can get the followup correct even after significant user mangling of headers? A few more random thoughts: (a) has anybody considered reply/forward and the difference between them for followups? Is the usual "Just add soem Resent- tags" scheme the Right Way to do this, or does forwarding require fixing up the Followup:? (b) what are the semantics of followups for an email that ends up encapsulated as a message/rfc822 in a digest or similar? Note that the digest itself may have no followups, but you can then proceed to cite more than one posting (possibly with divergent followups). What about a message/partial if the parts have disagreeing Followup:s? (c) we also need to think about if we *do* create a new Followup: header, what its interactions with bcc: and disclosing the recipient list really are (yes, I know different MTAs handle concealing bcc: differenty - this just has the potential of making it even worse). (Why would someobdy want to do that? I can easily see somebody sending out something "official", and bcc:ing his boss, and adding the boss to the Followup: so that the boss can lurk in the subsequent discussion. Bad move if the boss wanted to *really* lurk. Yes, better handled in other ways. Yes, users will do it anyhow ;) /Valdis (who is just awake enough to think of boundary conditions that he can't solve ;) From owner-ietf-822 Wed Jul 16 03:13:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id DAA20684 for ietf-822-bks; Wed, 16 Jul 1997 03:13:09 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id DAA20680 for ; Wed, 16 Jul 1997 03:13:06 -0700 (PDT) Received: (qmail 25295 invoked by uid 666); 16 Jul 1997 10:24:54 -0000 Date: 16 Jul 1997 10:24:54 -0000 Message-ID: <19970716102454.25294.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > Assuming even 90% of the MUAs are updated to support a followup field, > how robust will it be if somebody in the 10% uses the bcc chainsaw > instead? If you leave out the new field, you get the same response from new MUAs as you do from old MUAs. > (a) has anybody considered reply/forward and the difference between > them for followups? It's always annoying when you want to retroactively change the recipient list in a message. You can send a new message, but that's annoying for the recipients, and some klutz will respond to the old message anyway. The same problem arises now if you make a typo in your recipient list. One solution is to add a level of indirection---hide all the recipients behind a mailing list---but this is often inconvenient. > more than one posting (possibly with divergent followups). Some MUAs let you reply or follow up to several messages at once. They simply merge the recipient lists. > (c) we also need to think about if we *do* create a new Followup: > header, what its interactions with bcc: and disclosing the recipient > list really are The first question is what the visible RFC 822 header should contain. A _blind_ carbon copy has no effect here. The second question is who the user wants to send blind copies to. He can decide that for himself. What's the problem? ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Wed Jul 16 23:46:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA05406 for ietf-822-bks; Wed, 16 Jul 1997 23:46:36 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA05402 for ; Wed, 16 Jul 1997 23:46:32 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id CAA21653; Thu, 17 Jul 1997 02:49:19 -0400 (EDT) Message-Id: <199707170649.CAA21653@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: keld@dkuug.dk (Keld J|rn Simonsen) cc: "Bart Schaefer" , Keith Moore , ietf-822@imc.org Subject: Re: best name for followups? In-reply-to: Your message of "Tue, 15 Jul 1997 00:59:45 +0200." <199707142259.AAA04230@dkuug.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 02:49:19 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > Further ideas to avoid looking at more than one copy of the same > mail sent to multiple email exploders: > > 1. the MTA should look at all headers in the to: and cc: fields > and if there is duplicates, then only send it once. This has some interesting consequences. Let's say I want to send a note to this list but to keep you from getting a copy. I compose a message with both ietf-822@imc.org and keld@dkuug.dk in the To field, but with only one recipient in the envelope: ietf-822@imc.org. The list gets the message, looks at the To: line, decides that you are getting a copy of the message by another path, and so doesn't send you a copy. Since I didn't send you a copy either, you don't get one. > 2. The MUA could look at messages and remove those occurring > more than once. This more-or-less works, but implementation is tricky. A simple comparison of message-ids does not suffice; it creates an interesting security hole. Again assume I want to send a message to the list, but I don't want you to receive it. So I create two different messages with the same message-id. One of them I send to you. The other one I send to the list. When your MUA gets the second message, it discards it, because it's already seen a message with that message-id. So you want something that compares not just message-ids, but messages. (message-ids can be used as a key to find potential duplicates) The top few received headers will of course be different, so remove them from the comparison. Also remove headers commonly added by lists like Precedence and Errors-To. If none of the message paths munged the content, the UA can easily detect duplicates. But if one path munged the reply-to field, or rewrote to "moore" or changed 8bit mime to 7bit, or changed boundary markers, or changed content-transfer-encodings, or translated character sets, or converted plain text to html (yeech), it becomes more difficult to recognize two messages as the same. For my personal message store, a simple comparison (not counting a few well-chosen top-level headers) seems to work quite well. But this would vary considerably from one user to another. It would not work for lists that do extensive header munging. ( other approaches at duplicate suppression also fail in the presence of some kinds of list munging.) Keith From owner-ietf-822 Thu Jul 17 17:17:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA23568 for ietf-822-bks; Thu, 17 Jul 1997 17:17:08 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA23564 for ; Thu, 17 Jul 1997 17:17:05 -0700 (PDT) Received: (qmail 20421 invoked by uid 666); 18 Jul 1997 00:28:50 -0000 Date: 18 Jul 1997 00:28:50 -0000 Message-ID: <19970718002850.20420.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > A simple comparison of message-ids does not suffice; it creates > an interesting security hole. People here may not realize that noted security expert Perry Metzger disagrees. Excerpted from his DRUMS commentary in March 1996: ``It is not a security hole, Mr. Bernstein. ... Don't teach granpaw to suck eggs. I make my bread and butter as a security consultant.'' ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Fri Jul 18 08:32:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA03536 for ietf-822-bks; Fri, 18 Jul 1997 08:32:15 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA03532 for ; Fri, 18 Jul 1997 08:32:10 -0700 (PDT) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.6/8.8.6) with ESMTP id LAA16708; Fri, 18 Jul 1997 11:35:20 -0400 Message-Id: <199707181535.LAA16708@black-ice.cc.vt.edu> To: "D. J. Bernstein" Cc: ietf-822@imc.org Subject: Re: best name for followups? In-Reply-To: Your message of "18 Jul 1997 00:28:50 -0000." <19970718002850.20420.qmail@koobera.math.uic.edu> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1921422892P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 18 Jul 1997 11:35:19 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_1921422892P Content-Type: text/plain; charset=us-ascii On 18 Jul 1997 00:28:50 -0000, you said: > > A simple comparison of message-ids does not suffice; it creates > > an interesting security hole. > People here may not realize that noted security expert Perry Metzger > disagrees. Excerpted from his DRUMS commentary in March 1996: ``It is > not a security hole, Mr. Bernstein. ... Don't teach granpaw to suck > eggs. I make my bread and butter as a security consultant.'' Actually, there *is* a boundary condition that is problematic (and which I've seen the scenario happen *quite* often). Assume the following: 1) A large mailing list (1000+ or so people, perhaps) 2) A malicious user towards the front of the list 3) Your entry is towards the bottom of the list. The following can happen: a) Poster Fred sends something to the mailing list b) Malicious user gets his copy, and sends you *directly* something altered, but with the same message-id. Your copy is still in the queue at the mailing list site. c) Your *real* copy arrives, and is tossed because the same Message-ID: has been seen before. How do I know this scenario can happen? Because I quite regularly receive replies to my postings on some lists before I see my posting come back from the list. Obviously, the person replying has gotten his copy long before I get mine back. Of the last 9,704 e-mail messages I've received, procmail discarded 399 as having duplicate message-id: headers. And as I wrote this, I found a bug in my procmailrc which greatly reduced the effectiveness of the duplicate checking (explaining why I was still often seeing what looked like things I've seen before). Putting it all together is left as an excersize for the reader.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1921422892P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM8+NNtQBOOoptg9JAQEfmgP+O6aORJIPf6IIY9q8M+MGQOsbBY4l4Mhc eo2eEQwu9RP+mEwff0Ecm7nqaWQcEOYQUJEs7Apg4GFGCYW+El4LoMhsBcDTsV7E rKJv9AJLe53n2YdzxTJcfy81H8yZw2kI258qhB9643Oiwc7Tot3jsaL8v5z0vu2+ 42l1nMDR6eU= =pCyb -----END PGP MESSAGE----- --==_Exmh_1921422892P-- From owner-ietf-822 Fri Jul 18 17:05:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA10337 for ietf-822-bks; Fri, 18 Jul 1997 17:05:06 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA10327 for ; Fri, 18 Jul 1997 17:04:53 -0700 (PDT) Received: (qmail 4186 invoked by uid 666); 19 Jul 1997 00:16:28 -0000 Date: 19 Jul 1997 00:16:28 -0000 Message-ID: <19970719001628.4185.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk Sorry if my sarcasm wasn't obvious. I don't agree with Metzger; I think Metzger is an idiot. > b) Malicious user gets his copy, and sends you *directly* something altered, > but with the same message-id. A different attack, less commonly exploitable but much more reliable, is in the following situation: From: you@isp.net To: attacker@host.edu, mailing-list@host.edu If both isp.net and host.edu are running sendmail, the attacker can run a program that sends a prepared message to mailing-list, copying your Message-ID, and then pauses for a few seconds. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Wed Jul 30 11:14:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA00459 for ietf-822-bks; Wed, 30 Jul 1997 11:14:18 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA00453 for ; Wed, 30 Jul 1997 11:14:13 -0700 (PDT) Received: from eleanor.innosoft.com ("port 50959"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with ESMTP id <01ILUGMWBXOK8WXF9O@INNOSOFT.COM> for ietf-822@imc.org; Wed, 30 Jul 1997 11:17:07 PDT X-Received: from ietf.org ("port 46856"@ietf.org) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILUAIVCMVW8WX4XL@INNOSOFT.COM>; Wed, 30 Jul 1997 08:22:05 PDT X-Received: from ietf.org by ietf.org id aa07525; Wed, 30 Jul 1997 09:42 -0400 (EDT) X-Received: from ietf.ietf.org by ietf.org id aa06992; Wed, 30 Jul 1997 09:36 -0400 (EDT) Date: Wed, 30 Jul 1997 09:36:22 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-newman-msgheader-originfo-01.txt X-Orig-sender: cclark@ietf.org To: IETF-Announce@ietf.org Reply-to: Internet-Drafts@ietf.org Message-id: <9707300936.aa06992@ietf.org> MIME-version: 1.0 Content-type: Multipart/Mixed; Boundary="NextPart" Sender: owner-ietf-822@imc.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Originator-Info Message Header Author(s) : C. Newman Filename : draft-newman-msgheader-originfo-01.txt Pages : 6 Date : 07/29/1997 This proposal is an attempt to provide a standard header to indicate information about the message originator without implying that there is a deliverable mailbox or mandating that internal network information be revealed. The "Originator-Info" header is intended to make the "X-Sender" and "X-X-Sender" headers obsolete. Internet-Drafts are 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-newman-msgheader-originfo-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-newman-msgheader-originfo-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-newman-msgheader-originfo-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970729135315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-newman-msgheader-originfo-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-newman-msgheader-originfo-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970729135315.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-822 Wed Jul 30 11:18:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA00533 for ietf-822-bks; Wed, 30 Jul 1997 11:18:29 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA00528 for ; Wed, 30 Jul 1997 11:18:25 -0700 (PDT) Received: from eleanor.innosoft.com ("port 50962"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILUGQC1EIO8WX4XL@INNOSOFT.COM> for ietf-822@imc.org; Wed, 30 Jul 1997 11:19:54 PDT Date: Wed, 30 Jul 1997 11:21:43 -0700 (PDT) From: Chris Newman Subject: Originator-Info header To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk I've had the spec for Originator-Info around for just over 6 months. I just forwarded the announcement for the slightly revised version to this list. I'm inclined to ask for a four-week last call on the proposal. Anyone on this list have any comments? - Chris From owner-ietf-822 Wed Jul 30 11:14:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA00464 for ietf-822-bks; Wed, 30 Jul 1997 11:14:22 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA00456 for ; Wed, 30 Jul 1997 11:14:15 -0700 (PDT) Received: from eleanor.innosoft.com ("port 50960"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with ESMTP id <01ILUGN2T2LO8WXF9O@INNOSOFT.COM> for ietf-822@imc.org; Wed, 30 Jul 1997 11:17:16 PDT X-Received: from ietf.org ("port 46341"@ietf.org) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILUACC42C48WX4XL@INNOSOFT.COM>; Wed, 30 Jul 1997 08:16:49 PDT X-Received: from ietf.org by ietf.org id aa07534; Wed, 30 Jul 1997 09:42 -0400 (EDT) X-Received: from ietf.ietf.org by ietf.org id aa06966; Wed, 30 Jul 1997 09:36 -0400 (EDT) Date: Wed, 30 Jul 1997 09:36:17 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-newman-email-subaddr-00.txt X-Orig-sender: cclark@ietf.org To: IETF-Announce@ietf.org Reply-to: Internet-Drafts@ietf.org Message-id: <9707300936.aa06966@ietf.org> MIME-version: 1.0 Content-type: Multipart/Mixed; Boundary="NextPart" Sender: owner-ietf-822@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Email Subaddressing Author(s) : C. Newman Filename : draft-newman-email-subaddr-00.txt Pages : 7 Date : 07/29/1997 It is often useful for a single user to have multiple email addresses which can be used to assist categorizing incoming email. One way of doing this is to divide the local-part of an email address into a primary address and a subaddress. The primary address is used to route the message within the specified domain and the subaddress is used to route the message according to a particular user's wishes. This specification formalizes the de-facto standard for subaddressing in use today and includes advice and requirements for final delivery agents, MUAs and mail list servers which wish to support subaddressing. Internet-Drafts are 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-newman-email-subaddr-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-newman-email-subaddr-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-newman-email-subaddr-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970729132821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-newman-email-subaddr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-newman-email-subaddr-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970729132821.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-822 Wed Jul 30 11:19:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA00550 for ietf-822-bks; Wed, 30 Jul 1997 11:19:47 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA00546 for ; Wed, 30 Jul 1997 11:19:44 -0700 (PDT) Received: from eleanor.innosoft.com ("port 50963"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILUGU8DJTM8WX4XL@INNOSOFT.COM> for ietf-822@imc.org; Wed, 30 Jul 1997 11:23:02 PDT Date: Wed, 30 Jul 1997 11:24:52 -0700 (PDT) From: Chris Newman Subject: Email Subaddressing To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk I've written a spec for the subaddressing format which many people use. I'd very much appreciate discussion/feedback for the draft. I re-sent the announcement to this list. - Chris From owner-ietf-822 Wed Jul 30 13:12:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA02018 for ietf-822-bks; Wed, 30 Jul 1997 13:12:48 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA02014 for ; Wed, 30 Jul 1997 13:12:44 -0700 (PDT) Received: (qmail 24926 invoked by uid 666); 30 Jul 1997 20:16:40 -0000 Date: 30 Jul 1997 20:16:40 -0000 Message-ID: <19970730201640.24925.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > I've written a spec for the subaddressing format which many people use. Objections: 1. ``+'' is not the de facto standard; qmail's ``-'' is in wider use by several measures. (The separator is configurable by the sysadmin, but most people stick to dash, which I recommend for a variety of reasons.) 2. The requirement that foo-bar be delivered to foo ``by default'' is violated by qmail. Of course, I make it easy to set that up; but I think that bouncing is the right default. 3. The requirement that foo-bar be delivered to foo ``by default'' is violated by any delivery agent that doesn't support subaddressing. What is the point of a requirement that nobody can rely on? 4. The requirement that foo-bar be delivered to foo ``by default'' is a violation of the as-if principle. Again, what is the point of a requirement that nobody can rely on? 5. The ``canonically quoted'' section confuses content with encoding. Any delivery agent that uses your syntax is almost certainly violating RFC 822, section 3.4.4. The correct rule is very simple: any nonempty string of ASCII characters is a valid local part. RFC 821 and RFC 822 specify encodings of those strings for SMTP and mail headers. 6. Your restrictions on MUA quoting outlaw some valid addresses. 7. Your restrictions on MUA quoting produce incorrect results for _all_ quoted addresses when the MTA handles quoting correctly. MMDF and qmail handle quoting correctly. 8. ``MUST ignore subaddresses for the purposes of such validation'' is bizarre. If an MUA understands subaddresses, why shouldn't it validate them? 9. The requirement that list servers ignore subaddresses effectively prohibits the use of cryptographic cookies in return-path addresses for sender authentication. 10. ``Delivered to that primary address'' is unclear. 11. ``Owner of that primary address'' is unclear. 12. ``Rewriting'' is unclear. 13. ``Folder'' is unclear. 14. ``Command line interpretor'' is unclear. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Wed Jul 30 14:44:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA03169 for ietf-822-bks; Wed, 30 Jul 1997 14:44:48 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA03163 for ; Wed, 30 Jul 1997 14:44:44 -0700 (PDT) Received: from eleanor.innosoft.com ("port 51260"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILUO0NBU7K8WX0DN@INNOSOFT.COM> for ietf-822@imc.org; Wed, 30 Jul 1997 14:48:15 PDT Date: Wed, 30 Jul 1997 14:50:03 -0700 (PDT) From: Chris Newman Subject: Re: Email Subaddressing In-reply-to: <19970730201640.24925.qmail@koobera.math.uic.edu> To: "D. J. Bernstein" Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Wed, 30 Jul 1997, D. J. Bernstein wrote: > 1. ``+'' is not the de facto standard; qmail's ``-'' is in wider use by > several measures. (The separator is configurable by the sysadmin, but > most people stick to dash, which I recommend for a variety of reasons.) This is the first I've heard of using "-". I've seen "=" used before. We have to pick a single character, and I picked "+" because it is already supported or partially supported by several vendors including: sendmail, CMU Cyrus IMAP server, AMS, PMDF, and Pine. I'll replace the words "de-facto standard" with "one common practice for" in the intro since that's more accurate. I also think "-" is a poor choice since it is already used for "-list", "-owner", and "-request" primary addresses (the latter of which is a proposed standard). Overloading symbols is bad. > 3. The requirement that foo-bar be delivered to foo ``by default'' is > violated by any delivery agent that doesn't support subaddressing. What > is the point of a requirement that nobody can rely on? The idea is if my MUA and final delivery MTA are "subaddressing compliant", then everything works as expected without sysadmin intervention. The idea is to create a new level of conformance (subaddress conformance) which users will find valuable. > 5. The ``canonically quoted'' section confuses content with encoding. > Any delivery agent that uses your syntax is almost certainly violating > RFC 822, section 3.4.4. The correct rule is very simple: any nonempty > string of ASCII characters is a valid local part. RFC 821 and RFC 822 > specify encodings of those strings for SMTP and mail headers. The choice is either to require "canonically quoted" form which is what users see currently in their user interfaces (unfortunately), or to require "raw form" and define the mapping algorithm to RFC 821 and RFC 822 addressing. As users never see "raw form" and it can't be left-to-right parsed, I'm not comfortable using it at this point. I'd certainly welcome suggested text which makes it clear that the quoting is part of the encoding rather than the content. > 6. Your restrictions on MUA quoting outlaw some valid addresses. It does prevent the use of subaddresses with local parts that use or contain control characters or NUL. Is this a problem? It also doesn't "outlaw" -- it only forbids generation of such addresses and subaddress processing of such addresses in subaddress compliant software. > 8. ``MUST ignore subaddresses for the purposes of such validation'' is > bizarre. If an MUA understands subaddresses, why shouldn't it validate > them? Good point. How about "MUST ignore subaddresses for the purpose of user validation"? > 9. The requirement that list servers ignore subaddresses effectively > prohibits the use of cryptographic cookies in return-path addresses for > sender authentication. I don't understand what you're saying. Is there an RFC or Internet Draft I can read on this topic? Is there some reason cookies can't be computed only on the primary address? > 10. ``Delivered to that primary address'' is unclear. > > 11. ``Owner of that primary address'' is unclear. > > 12. ``Rewriting'' is unclear. > > 13. ``Folder'' is unclear. > > 14. ``Command line interpretor'' is unclear. Ok, I'll work on clarifying those in the next draft. If this is all you disagree with, then I gather this isn't a bad start on the problem? - Chris From owner-ietf-822 Wed Jul 30 16:10:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA03951 for ietf-822-bks; Wed, 30 Jul 1997 16:10:09 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA03946 for ; Wed, 30 Jul 1997 16:10:04 -0700 (PDT) Received: (qmail 28050 invoked by uid 666); 30 Jul 1997 23:13:51 -0000 Date: 30 Jul 1997 23:13:51 -0000 Message-ID: <19970730231351.28049.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > We have to pick a single character, Why? What interoperability problems are you trying to solve? One of the reasons for qmail's growing popularity is its simple user interface for subaddresses. But what does this have to do with the IETF? Why should the IETF be trying to control user interface competition? Throw away all the user interface stuff, and your document appears to collapse down to a single requirement: Mailing list managers must disregard foo in deciding whether joe+foo@host can send messages to the mailing list. But that's a bad requirement. It prohibits cryptographic uses of the subaddress string. It also ignores the fact that joe+37@host might be a different user, with no right to use the mailing list; you have no way to tell whether the subscriber's delivery agent supports subaddresses. > I've seen "=" used before. MMDF. > I also think "-" is a poor choice since it is already used for "-list", > "-owner", and "-request" primary addresses This is one of the reasons that dash is a _good_ choice: it continues the tradition of a dash-separated address hierarchy. Using a different character for the top level is a pointless inconsistency. For example, the main mailing list for a project commonly coincides with the project's account name. Is the owner's address project-owner or project+owner? > The idea is if my MUA and final delivery MTA are "subaddressing compliant", If you simply want to define ``subaddressing compliant,'' go take it to some group that publishes standards for user interfaces. (Maybe Apple.) > The choice is either to require "canonically quoted" form which is what > users see currently Again you're confusing content with encoding. The address a,b,c@heaven.af.mil is perfectly valid. It is _encoded_ as RCPT TO:<"a,b,c"@heaven.af.mil> in SMTP. It may be _encoded_ in some way for user display. (Some people use addresses with commas for spam control.) The more basic question here is why you're bothering to talk about quoting in a document about subaddresses. > I don't understand what you're saying. Envelope sender addresses are easily forged. One solution is to have each sender use Return-Path: where ``cookie'' is some sort of secret string---for example, a subscriber-specific secret supplied by the MLM. This obviously doesn't work if the MLM is required to ignore the cookie. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Wed Jul 30 17:00:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA04461 for ietf-822-bks; Wed, 30 Jul 1997 17:00:09 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA04457 for ; Wed, 30 Jul 1997 17:00:05 -0700 (PDT) Received: from eleanor.innosoft.com ("port 51355"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILUSPR9CWW8WX0DN@INNOSOFT.COM> for ietf-822@imc.org; Wed, 30 Jul 1997 17:03:01 PDT Date: Wed, 30 Jul 1997 17:04:52 -0700 (PDT) From: Chris Newman Subject: Re: Email Subaddressing In-reply-to: <19970730231351.28049.qmail@koobera.math.uic.edu> To: "D. J. Bernstein" Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Wed, 30 Jul 1997, D. J. Bernstein wrote: > > We have to pick a single character, > > Why? > > What interoperability problems are you trying to solve? Interoperability between MUAs, final delivery agents and mailing list servers from different vendors. I want to be able to subscribe to list foo as and have it delivered to me. In order for this to work, I need user agents which let me type the "+foo" in the from and envelope sender address, I need mailing list software which doesn't reject postings from if I'm subscribed as , and I need a final delivery agent which won't reject "+foo" addresses. If this isn't a need for multi-vendor interoperability, what is? > Mailing list managers must disregard foo in deciding whether > joe+foo@host can send messages to the mailing list. > > But that's a bad requirement. It prohibits cryptographic uses of the > subaddress string. It also ignores the fact that joe+37@host might be a > different user, with no right to use the mailing list; you have no way > to tell whether the subscriber's delivery agent supports subaddresses. I don't consider this a big deal. People don't use "+" in addresses most of the time, unless they're using it as a subaddress separator. The failure mode is to allow someone to post who otherwise might not be able to -- not a big deal given how rarely + is used in addresses for other reasons. > > I also think "-" is a poor choice since it is already used for "-list", > > "-owner", and "-request" primary addresses > > This is one of the reasons that dash is a _good_ choice: it continues > the tradition of a dash-separated address hierarchy. Using a different > character for the top level is a pointless inconsistency. > > For example, the main mailing list for a project commonly coincides with > the project's account name. Is the owner's address project-owner or > project+owner? I'd argue that current uses of "-" do not have subaddress semantics. The "foo-list-request" address is not under management control of the entity with the address "foo-list". The common use of "+" is to separate address management hierarchy. Addresses before "+" are managed by the sysadmin, addresses after the "+" are managed by the entity before the plus. I think most current uses of "-" are simply naming hierarchy and not subaddressing. > Again you're confusing content with encoding. The address No I'm not. I understand the distinction well. But the distinction is not clear to implementors of 821/822 and most Internet mail users so I see little point in making the proposal more complex in order to make the distinction clear. The "raw" format for a mail address doesn't really exist anywhere, except possibly as an internal aid to certain implementation strategies. > The more basic question here is why you're bothering to talk about > quoting in a document about subaddresses. Because a good standard needs complete formal grammar for what it's discussing. > > I don't understand what you're saying. > > Envelope sender addresses are easily forged. One solution is to have > each sender use > > Return-Path: > > where ``cookie'' is some sort of secret string---for example, a > subscriber-specific secret supplied by the MLM. This obviously doesn't > work if the MLM is required to ignore the cookie. This is another case where MUA, final delivery agent and list exploder need to interoperate. There's also no reason this has to use the same delimiter. But in order to be practical for wide deployment, this would have to be standards track. - Chrsi From owner-ietf-822 Wed Jul 30 17:55:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA04986 for ietf-822-bks; Wed, 30 Jul 1997 17:55:10 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA04981 for ; Wed, 30 Jul 1997 17:55:05 -0700 (PDT) Received: (qmail 29587 invoked by uid 666); 31 Jul 1997 00:59:02 -0000 Date: 31 Jul 1997 00:59:02 -0000 Message-ID: <19970731005902.29586.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > In order for > this to work, I need user agents which let me type the "+foo" in the from > and envelope sender address, Chris, there's a huge difference between ``this is good'' and ``this is the IETF's bailiwick.'' One piece of _advice_ that I give to MUA authors is to allow complete configurability of every outgoing message, including Return-Path. But I'm disgusted at the thought of the IETF _requiring_ this. > I need a final delivery agent which won't reject "+foo" addresses. Surely every MTA supports aliases. If you don't like the user interface, talk to the vendor, or switch to an MTA with a better user interface. > I think most current uses of "-" are simply naming hierarchy and not > subaddressing. You didn't answer my question. Is it project-owner, or project+owner? Are you going to prohibit mailing list names that match account names? A uniform hierarchy doesn't have this problem. [ requiring mailing lists to incorrectly accept messages from joe+37 ] > I don't consider this a big deal. You are requiring a failure mode in a security mechanism. You are also prohibiting a superior security mechanism. This is unacceptable. It is up to the mailing list owner to decide which messages he will distribute and which ones he won't. If you don't like the security mechanisms in current MLM software, you should complain to the MLM authors, not the IETF. > Because a good standard needs complete formal grammar for what it's > discussing. ``Standard''? ``Good''? If you weren't confusing content and encoding, you could simply say ``a structured address consists of user-part, sep-char, and sub-part, where user-part does not contain sep-char.'' ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Wed Jul 30 18:41:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA05360 for ietf-822-bks; Wed, 30 Jul 1997 18:41:28 -0700 (PDT) Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA05355 for ; Wed, 30 Jul 1997 18:41:23 -0700 (PDT) Received: from tp7.jck.com ("port 1421"@[166.35.80.202]) by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0EE5U7EA10070M@a4.jck.com> for ietf-822@imc.org; Wed, 30 Jul 1997 21:45:15 -0400 (EDT) Date: Wed, 30 Jul 1997 21:43:57 -0400 (EDT) From: John C Klensin Subject: Re: Email Subaddressing In-reply-to: To: Chris Newman Cc: ietf-822@imc.org Reply-to: John C Klensin Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.2 Build (22a) Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Authentication: none Sender: owner-ietf-822@imc.org Precedence: bulk On Wed, 30 Jul 1997 17:04:52 -0700 (PDT) Chris Newman wrote: > I want to be able to subscribe to list foo as > and have it delivered to me. In order for > this to work, I need user agents which let me type the "+foo" in the from >... Chris, I think you are right, and that it is probably worth giving up the availability "+" for anything else to get where we need to be. But, logically speaking, most of your argument evaporates if either of two courses is taken: (1) We went through a long and difficult period in which we eventually convinced most of those who develop list management software that it was rational to permit people to set a "list target" address that was different from the "from:" header field address. One could adopt a model in which, logically, there were three addresses From: List distro (defaults to from, but can be changed) List posting (defaults to from --not list distro-- but can be changed) (2) We go where, because of spam and spoofing issues, I think we are headed anyway, which is not accepting material for posting to a list unless a digital signature can be verified. Then the "subscribe" operation somehow has to register a public key (or pointer to one). But then "right to post" is a key identifier/ signature verification issue, not a matter of matching return address strings; the latter becomes largely superfluous. If this logic is correct, can you make the case that it is worth a possibly-significant risk to the infrastructure (yes, there really are addresses -- especially in mappings to and from strange gateways to LAN mail systems -- in which "+" is a delimiter character, but not for subaddressing, and several of them may appear in a local-part) for what may be a short-term gain? john From owner-ietf-822 Wed Jul 30 19:26:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA05775 for ietf-822-bks; Wed, 30 Jul 1997 19:26:46 -0700 (PDT) Received: from casita.houston.tx.us (troth@casita.houston.tx.us [204.253.212.193]) by mail.proper.com (8.8.5/8.7.3) with SMTP id TAA05771 for ; Wed, 30 Jul 1997 19:26:40 -0700 (PDT) Received: (from troth@localhost) by casita.houston.tx.us (8.6.11/8.6.9) id VAA09139; Wed, 30 Jul 1997 21:32:00 -0500 Date: Wed, 30 Jul 1997 21:31:55 -0500 (CDT) From: Rick Troth To: "D. J. Bernstein" cc: ietf-822@imc.org Subject: Re: Email Subaddressing In-Reply-To: <19970730201640.24925.qmail@koobera.math.uic.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-822@imc.org Precedence: bulk > 1. ``+'' is not the de facto standard; qmail's ``-'' is in wider use by > several measures. (The separator is configurable by the sysadmin, but > most people stick to dash, which I recommend for a variety of reasons.) IFF subaddressing were to come to pass, then ... I would second the use of dash because I use it, and have seen others use it regularly, as a delimiter between application name or ID and the version or release. That is, there is precedent for dash to be used as a marker between specific and non-specific: bash bash-1.14 bash-2.0 looks visibly like troth troth-dnrc But should I accept these? troth-vmesa-l troth-ietf-822 I would NOT like to see a slash used here, but there's near precedent for that too. (HP's OpenMail; others?) Period (dot) and underscore seem right out and comma would be difficult. Maybe it should be list!user ... ;-) -- Rick Troth at La Casita, Houston, Texas, USA From owner-ietf-822 Wed Jul 30 22:34:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA06969 for ietf-822-bks; Wed, 30 Jul 1997 22:34:10 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id WAA06964 for ; Wed, 30 Jul 1997 22:34:04 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id WAA24644 for ietf-822@imc.org; Wed, 30 Jul 1997 22:37:55 -0700 From: "Bart Schaefer" Message-Id: <970730223754.ZM24643@candle.brasslantern.com> Date: Wed, 30 Jul 1997 22:37:54 -0700 In-Reply-To: Comments: In reply to Chris Newman "Email Subaddressing" (Jul 30, 11:24am) References: X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk All the discussion so far about this draft hinges on one question: Is it necessary for anyone other than the "Final MTA" and "Final Delivery Agent" to understand the semantics of subaddresses? Put another way, is there ever a case where a sending agent needs to start from a primary address, compute a subaddress by some means other than user input, and direct the message to the concatenation of the two? If so, then there's a good reason to standardize the format of the primary and sub-addresses, and to standardize the way they're concatenated. If there is not, then failure to standardize is only an inconvenience. It means that a sub-addressing scheme that worked when the user received mail at domain X may stop working when he moves to domain Y, even if both claim to support sub-addressing. Some inconveniences are severe enough to warrant a standard to mitigate them; I suspect there'll be dissention over whether this is such a case. At this point I don't find the arguments for standardizing to be strong enough, though an informational document might be nice. I'm willing to be convinced otherwise, though, because I do get mail via several domains and do feel the inconvenience of inconsistent or absent subaddressing schemes. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Wed Jul 30 23:44:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA07411 for ietf-822-bks; Wed, 30 Jul 1997 23:44:21 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA07407 for ; Wed, 30 Jul 1997 23:44:17 -0700 (PDT) Received: from eleanor.innosoft.com ("port 51419"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILV6TXZY8Y8WXMII@INNOSOFT.COM> for ietf-822@imc.org; Wed, 30 Jul 1997 23:47:15 PDT Date: Wed, 30 Jul 1997 23:49:06 -0700 (PDT) From: Chris Newman Subject: Re: Email Subaddressing In-reply-to: To: John C Klensin Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Wed, 30 Jul 1997, John C Klensin wrote: > I think you are right, and that it is probably worth giving > up the availability "+" for anything else to get where we > need to be. But, logically speaking, most of your argument > evaporates if either of two courses is taken: I'm much less convinced. I use subaddresses for non-mailing list things. I believe they're generally useful regardless of alternative solutions to the list subscription/restriction problems. > If this logic is correct, can you make the case that it is > worth a possibly-significant risk to the infrastructure > (yes, there really are addresses -- especially in mappings > to and from strange gateways to LAN mail systems -- in > which "+" is a delimiter character, but not for > subaddressing, and several of them may appear in a > local-part) for what may be a short-term gain? More than one deployed product already manages subaddresses as the spec mentions and I've heard of no infrastructure problems other than the occasional product which rejects all addresses containing "+". Of course such products are clearly in violation of RFC822 already. I also don't view this as a short term gain. From owner-ietf-822 Wed Jul 30 23:51:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA07481 for ietf-822-bks; Wed, 30 Jul 1997 23:51:28 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA07476 for ; Wed, 30 Jul 1997 23:51:24 -0700 (PDT) Received: from eleanor.innosoft.com ("port 51421"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILV72RI6O28WXMII@INNOSOFT.COM> for ietf-822@imc.org; Wed, 30 Jul 1997 23:54:22 PDT Date: Wed, 30 Jul 1997 23:56:12 -0700 (PDT) From: Chris Newman Subject: Re: Email Subaddressing In-reply-to: To: Rick Troth Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Wed, 30 Jul 1997, Rick Troth wrote: > IFF subaddressing were to come to pass, then ... > > I would second the use of dash because I use it, and have > seen others use it regularly, as a delimiter between application name > or ID and the version or release. That is, there is precedent for > dash to be used as a marker between specific and non-specific: Besides the fact that I only know of one product which uses "-" as a subaddress separator and several which use "+", there's a show-stopper for using "-". Many sites use the firstname.lastname@host naming convention and many people have "-" in their last names. - Chris From owner-ietf-822 Thu Jul 31 00:10:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA07739 for ietf-822-bks; Thu, 31 Jul 1997 00:10:59 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id AAA07732 for ; Thu, 31 Jul 1997 00:10:55 -0700 (PDT) Received: from eleanor.innosoft.com ("port 51424"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILV7RF92AC8WXMII@INNOSOFT.COM> for ietf-822@imc.org; Thu, 31 Jul 1997 00:14:15 PDT Date: Thu, 31 Jul 1997 00:16:05 -0700 (PDT) From: Chris Newman Subject: Re: Email Subaddressing In-reply-to: <970730223754.ZM24643@candle.brasslantern.com> To: Bart Schaefer Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Wed, 30 Jul 1997, Bart Schaefer wrote: > Put another way, is there ever a case where a sending agent needs to start > from a primary address, compute a subaddress by some means other than user > input, and direct the message to the concatenation of the two? A lot of sites have a requirement that the from address not be editable in their MUAs. Such sites do this because they don't want realistic-looking spoofing to be easy. I can't think of anything the IETF could do to change this. We can jump up and down and say "you must be able to edit the from address" all we want and it simply won't happen. So I'm looking for the ability to enter just the subaddress for the From header and envelope from without any requirement that the rest of the from address be editable. I bet MUA authors would go along with that (or a special list-subscription command which added a subaddress) and it wouldn't violate site policy for most sites which don't want the from address editable. > At this point I don't find the arguments for standardizing to be strong > enough, though an informational document might be nice. I'm willing to be > convinced otherwise, though, because I do get mail via several domains and > do feel the inconvenience of inconsistent or absent subaddressing schemes. There are two cases where MUAs need to cooperate with subaddresses: 1) MUAs which don't allow from to be edited otherwise. 2) MUAs which validate local addresses against a white pages or authdb service. There is one case where a list server needs to cooperate with subaddresses: 1) List server restricts posting to subscribers. There are several cases where a final delivery agent needs to cooperate with subaddresses: 1) alias or forwarding address (especially for centralized mail hubs which route delivery to other nodes) 2) validation of local addresses against locally deliverable address list 3) Any final delivery filtering/filing rules. I believe this demonstrates the need for standards-level interoperability between the three components. From owner-ietf-822 Thu Jul 31 01:11:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA08378 for ietf-822-bks; Thu, 31 Jul 1997 01:11:24 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA08373 for ; Thu, 31 Jul 1997 01:11:19 -0700 (PDT) Received: (qmail 2938 invoked by uid 666); 31 Jul 1997 08:15:18 -0000 Date: 31 Jul 1997 08:15:18 -0000 Message-ID: <19970731081518.2937.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > there's a show-stopper for using "-". No, there isn't. But thanks for reminding me of this issue---it turns out to be a show-stopper for your proposal. > Many sites use the firstname.lastname@host naming convention > and many people have "-" in their last names. So what? The software handles this just fine. It supports a more advanced address hierarchy than your naive ``jean-marc MUST be delivered to jean'' idea. What do you suggest someone do with existing usernames that contain +? How will your wonderful new software handle this situation? Does it start throwing away mail for those users? With qmail, if + is the separator, those users will still receive mail. Of course, this is incompatible with your delusion that local addresses can be parsed by other hosts. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Thu Jul 31 01:27:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA08551 for ietf-822-bks; Thu, 31 Jul 1997 01:27:00 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA08547 for ; Thu, 31 Jul 1997 01:26:55 -0700 (PDT) Received: (qmail 3081 invoked by uid 666); 31 Jul 1997 08:30:54 -0000 Date: 31 Jul 1997 08:30:54 -0000 Message-ID: <19970731083054.3080.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk (Please don't send me duplicates, Chris.) > There are two cases where MUAs need to cooperate with subaddresses: > 1) MUAs which don't allow from to be edited otherwise. This is a purely local configuration problem. > 2) MUAs which validate local addresses against a white pages or authdb > service. A service that claims to check mail addresses obviously has to understand subaddresses. This is a purely local configuration problem. > 1) List server restricts posting to subscribers. You have no right to demand that list owners accept your mail. > There are several cases where a final delivery agent needs to cooperate > with subaddresses: All of those cases are purely local configuration problems. I suppose next we're going to see a document explaining how sendmail interacts with procmail, and requiring that all MTAs and LDAs work the same way. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Thu Jul 31 08:34:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA14861 for ietf-822-bks; Thu, 31 Jul 1997 08:34:45 -0700 (PDT) Received: from transarc.com (transarc.com [192.54.226.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA14857 for ; Thu, 31 Jul 1997 08:34:41 -0700 (PDT) Received: by transarc.com (5.54/3.15) id for ietf-822@imc.org; Thu, 31 Jul 97 11:38:35 EDT Received: via switchmail; Thu, 31 Jul 1997 11:38:34 -0400 (EDT) Received: from bigbend.transarc.com via qmail ID ; Thu, 31 Jul 1997 11:36:50 -0400 (EDT) Received: from bigbend.transarc.com via qmail ID ; Thu, 31 Jul 1997 11:36:46 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.bigbend.transarc.com.sun4c.53 via MS.5.6.bigbend.transarc.com.sun4_51; Thu, 31 Jul 1997 11:36:43 -0400 (EDT) Message-Id: Date: Thu, 31 Jul 1997 11:36:43 -0400 (EDT) From: Craig_Everhart@transarc.com To: ietf-822@imc.org Subject: Re: Email Subaddressing In-Reply-To: References: Sender: owner-ietf-822@imc.org Precedence: bulk Independently of all the concerns about who is mandating what, there are a few informational points that are interesting even for sites that implement subaddressing locally--i.e. that can serve as advice for some kinds of new implementations. For purposes of this presentation I'm going to assume that the locally-interpreted subaddressing scheme is based on a ``addr+subaddr'' form of local-part. Point one: Copy the incoming address to a Received: header, perhaps in a ``for'' clause. Generally, I want to be able to put my addr+subaddr@domain address in a distribution list and retain the fact that it was sent to addr+subaddr. If the +subaddr text is to be interpreted by some post-delivery process, it has to be recorded somewhere at delivery time, and a Received: header is a reasonable candidate. Point two: Use the entire addr+subaddr for any duplicate elimination. If an MTA attempts to eliminate the delivery of duplicate messages, it will often do so by refusing to send the SAME MESSAGE to the SAME ADDRESS. Thus, it can make some record of having sent a given message to a given address, and future delivery attempts can check for such a record. While I could offer some advice about what constitutes an adequate record of the SAME MESSAGE, at this point I'd just remark that the entire addr+subaddr information is important to be considered for purposes of duplicate elimination; thus, sending message A to addresses foo+bar and foo+baz is not an instance of duplicate delivery. Point three: Raise the issue of copying the +subaddr annotation. Suppose mail to local user user1 is forwarded to local user user2. If mail arrives for user1+foo, should it be forwarded to user2 or to user2+foo? Perhaps the MTA's notion of mail forwarding needs to be able to allow the user or administrator who sets the mail forwarding to make the choice. Needless to say, these fine points arose from real-life use of addr+subaddr notation over a few years. Craig From owner-ietf-822 Thu Jul 31 09:02:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA15177 for ietf-822-bks; Thu, 31 Jul 1997 09:02:56 -0700 (PDT) Received: from postman.opengroup.org (postman.opengroup.org [130.105.1.152]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA15173 for ; Thu, 31 Jul 1997 09:02:51 -0700 (PDT) Received: from opengroup.org (mule.camb.opengroup.org [130.105.3.45]) by postman.opengroup.org (8.8.6/8.8.6) with ESMTP id MAA13242; Thu, 31 Jul 1997 12:06:22 -0400 (EDT) Message-Id: <199707311606.MAA13242@postman.opengroup.org> To: Craig_Everhart@transarc.com Cc: ietf-822@imc.org Subject: Re: Email Subaddressing In-reply-to: Message from Craig_Everhart@transarc.com . X-Face: "UZ!}1W2N?eJdN(`1%|/OOPqJ).Idk?UyvWw'W-%`Gto8^IkEm>.g1O$[.;~}8E=Ire0|lO .o>:NlJS1@vO9bVmswRoq3j DdX9YGSeJ5a(mfX[1u>Z63G5_^+'8LVqjqvn X-Url: http://www.osf.org/~loverso/ Date: Thu, 31 Jul 1997 12:06:18 -0400 From: John Robert LoVerso Sender: owner-ietf-822@imc.org Precedence: bulk > Point three: Raise the issue of copying the +subaddr annotation. > Suppose mail to local user user1 is forwarded to local user user2. If > mail arrives for user1+foo, should it be forwarded to user2 or to > user2+foo? Perhaps the MTA's notion of mail forwarding needs to be able Isn't this a function of the mail delivery agent rather than the MTA? Certainly many MTAs attempt to be both (sendmail), but truly the MTA doesn't need to know about aliasing or forwarding. John From owner-ietf-822 Thu Jul 31 10:00:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA15969 for ietf-822-bks; Thu, 31 Jul 1997 10:00:40 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA15965 for ; Thu, 31 Jul 1997 10:00:34 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id KAA27376 for ietf-822@imc.org; Thu, 31 Jul 1997 10:04:29 -0700 From: "Bart Schaefer" Message-Id: <970731100429.ZM27375@candle.brasslantern.com> Date: Thu, 31 Jul 1997 10:04:29 -0700 In-Reply-To: Comments: In reply to Chris Newman "Re: Email Subaddressing" (Jul 31, 12:16am) References: X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk Dan B. dismisses MUA and final delivery agent processing of subaddresses as local configuration problems and asserts that list server behavior is up to the list maintainer. I agree that there's no need to mandate list server behavior; documenting the possible usages of subaddresses is more than enough in that case. However, I'd like to know the solution to the local configuration problem. If the ability to mix and match MUAs and delivery agents is important, then it would seem that they need some common set of rules for interpreting the local-part of the addresses. What's the alternative? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Thu Jul 31 10:07:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA16090 for ietf-822-bks; Thu, 31 Jul 1997 10:07:39 -0700 (PDT) Received: from transarc.com (transarc.com [192.54.226.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id KAA16086 for ; Thu, 31 Jul 1997 10:07:35 -0700 (PDT) Received: by transarc.com (5.54/3.15) id for ietf-822@imc.org; Thu, 31 Jul 97 13:08:57 EDT Received: via switchmail; Thu, 31 Jul 1997 13:08:56 -0400 (EDT) Received: from bigbend.transarc.com via qmail ID ; Thu, 31 Jul 1997 13:07:48 -0400 (EDT) Received: from bigbend.transarc.com via qmail ID ; Thu, 31 Jul 1997 13:07:44 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.bigbend.transarc.com.sun4c.53 via MS.5.6.bigbend.transarc.com.sun4_51; Thu, 31 Jul 1997 13:07:43 -0400 (EDT) Message-Id: Date: Thu, 31 Jul 1997 13:07:43 -0400 (EDT) From: Craig_Everhart@transarc.com To: John Robert LoVerso Subject: Re: Email Subaddressing Cc: ietf-822@imc.org In-Reply-To: <199707311606.MAA13242@postman.opengroup.org> References: <199707311606.MAA13242@postman.opengroup.org> Sender: owner-ietf-822@imc.org Precedence: bulk Gee, is mail forwarding part of the MTA or the ``mail delivery agent''? I'm sorry that I'm not up on the distinction; perhaps it comes from being X.500-free for so long. Think of the consideration about copying +subaddr stuff as part of the mail forwarding process, whether that's part of the mail delivery agent or the MTA; the consideration still applies. In fact, it applies to the general notion of ``mail forwarding,'' whether that is done at MTA, delivery-agent, or MUA time. Thanks, Craig From owner-ietf-822 Thu Jul 31 12:41:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA00713 for ietf-822-bks; Thu, 31 Jul 1997 12:41:33 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA00708 for ; Thu, 31 Jul 1997 12:41:30 -0700 (PDT) Received: (qmail 8106 invoked by uid 666); 31 Jul 1997 19:45:14 -0000 Date: 31 Jul 1997 19:45:14 -0000 Message-ID: <19970731194514.8105.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > If the ability to mix and match MUAs and delivery agents is important, In practice the interface is the mailbox. The delivery agent writes the message to the mailbox in some standard format, and the MUA reads it. MUAs don't generally seem to care about the envelope, except possibly for displaying the return-path. It would be possible to do something different. Many delivery agents record the envelope recipient in a usable format. The MUA could read the subaddress and use it for sorting. Chris, would it violate your ``MUST NOT automatically create new folders'' requirement if the MUA showed the user a list of the subaddresses that had been shown up, and allowed the user to browse each subaddress as a folder? Does your answer depend on how the messages are physically stored on disk? ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Thu Jul 31 13:45:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA01478 for ietf-822-bks; Thu, 31 Jul 1997 13:45:54 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA01474 for ; Thu, 31 Jul 1997 13:45:41 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id NAA28105 for ietf-822@imc.org; Thu, 31 Jul 1997 13:49:34 -0700 From: "Bart Schaefer" Message-Id: <970731134934.ZM28104@candle.brasslantern.com> Date: Thu, 31 Jul 1997 13:49:34 -0700 In-Reply-To: <19970731194514.8105.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Jul 31, 7:45pm) References: <19970731194514.8105.qmail@koobera.math.uic.edu> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 31, 7:45pm, D. J. Bernstein wrote: > Subject: Re: Email Subaddressing > > If the ability to mix and match MUAs and delivery agents is important, > > In practice the interface is the mailbox. The delivery agent writes the > message to the mailbox in some standard format, and the MUA reads it. That's true upon receipt, but you included as a local configuration problem the case where the MUA needs to supply a return address. In this case the delivery agent is presumably going to interpret that address when the reply comes back, so the interface is the address itself. What's the mechanism for ensuring that they agree on what such a return address should look like? From owner-ietf-822 Thu Jul 31 14:32:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA02014 for ietf-822-bks; Thu, 31 Jul 1997 14:32:59 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA02010 for ; Thu, 31 Jul 1997 14:32:55 -0700 (PDT) Received: (qmail 9287 invoked by uid 666); 31 Jul 1997 21:36:43 -0000 Date: 31 Jul 1997 21:36:43 -0000 Message-ID: <19970731213643.9286.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > but you included as a local configuration problem > the case where the MUA needs to supply a return address. MUAs typically pass a partially formed message to a submission agent supplied with the MTA. The submission agent figures out From, Return-Path, etc., from a combination of sysadmin configuration and user configuration. See, e.g., http://www.qmail.org/qmail-manual-html/man8/qmail-inject.html. > What's the mechanism for ensuring that they agree on what such a return > address should look like? They don't have to. I use VERPs for my outgoing messages---e.g., Return-Path: ---so that a program can reliably associate bounce messages with original messages. The VERPs are created by qmail-inject, not the MUA. The delivery of djb-dsn-* is handled by qmail-local, not the MUA. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Thu Jul 31 14:44:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA02131 for ietf-822-bks; Thu, 31 Jul 1997 14:44:17 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA02126 for ; Thu, 31 Jul 1997 14:44:14 -0700 (PDT) Received: from eleanor.innosoft.com ("port 51688"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILW2A9MMAG8WXMBW@INNOSOFT.COM> for ietf-822@imc.org; Thu, 31 Jul 1997 14:47:39 PDT Date: Thu, 31 Jul 1997 14:49:29 -0700 (PDT) From: Chris Newman Subject: Re: Email Subaddressing In-reply-to: <19970731194514.8105.qmail@koobera.math.uic.edu> To: "D. J. Bernstein" Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Thu, 31 Jul 1997, D. J. Bernstein wrote: > It would be possible to do something different. Many delivery agents > record the envelope recipient in a usable format. The MUA could read the > subaddress and use it for sorting. Chris, would it violate your ``MUST > NOT automatically create new folders'' requirement if the MUA showed the > user a list of the subaddresses that had been shown up, and allowed the > user to browse each subaddress as a folder? Not as long as the MUA also allows browsing them in a single interface. The requirement stems from the security issue of not wanting to unintentially cede control of one's folder namespace to others. It probably should be a "SHOULD NOT" with clearer explaination. - Chris From owner-ietf-822 Thu Jul 31 15:06:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA02393 for ietf-822-bks; Thu, 31 Jul 1997 15:06:55 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA02389 for ; Thu, 31 Jul 1997 15:06:44 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id PAA28363; Thu, 31 Jul 1997 15:09:40 -0700 From: "Bart Schaefer" Message-Id: <970731150939.ZM28362@candle.brasslantern.com> Date: Thu, 31 Jul 1997 15:09:39 -0700 In-Reply-To: <19970731213643.9286.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Jul 31, 9:36pm) References: <19970731213643.9286.qmail@koobera.math.uic.edu> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.820 20aug96) To: "D. J. Bernstein" , ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 31, 9:36pm, D. J. Bernstein wrote: > Subject: Re: Email Subaddressing > > but you included as a local configuration problem > > the case where the MUA needs to supply a return address. > > MUAs typically pass a partially formed message to a submission agent > supplied with the MTA. > > The submission agent figures out From, Return-Path, etc., from a > combination of sysadmin configuration and user configuration. All this does is push the question off a level. Is it desirable to be able to mix and match MTA, delivery agent, and submission agent? From owner-ietf-822 Thu Jul 31 16:16:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA03261 for ietf-822-bks; Thu, 31 Jul 1997 16:16:37 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA03257 for ; Thu, 31 Jul 1997 16:16:33 -0700 (PDT) Received: (qmail 10057 invoked by uid 666); 31 Jul 1997 23:20:21 -0000 Date: 31 Jul 1997 23:20:21 -0000 Message-ID: <19970731232021.10056.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > All this does is push the question off a level. Is it desirable to be able > to mix and match MTA, delivery agent, and submission agent? qmail was designed to support multiple delivery agents and submission agents. qmail-local can invoke a variety of delivery agents. Submission agents can run as /usr/lib/sendmail and pass messages to qmail-queue. sendmail can also invoke a variety of delivery agents, and it'd be easy to write a qmail-queue clone for sendmail if there were any interest. When a delivery agent supports subaddresses---as, e.g., procmail does--- both qmail and (recent versions of) sendmail can straightforwardly pass the necessary information to it. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Thu Jul 31 16:47:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA03616 for ietf-822-bks; Thu, 31 Jul 1997 16:47:59 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA03607 for ; Thu, 31 Jul 1997 16:47:51 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id QAA28690 for ietf-822@imc.org; Thu, 31 Jul 1997 16:51:46 -0700 From: "Bart Schaefer" Message-Id: <970731165145.ZM28689@candle.brasslantern.com> Date: Thu, 31 Jul 1997 16:51:45 -0700 In-Reply-To: <19970731232021.10056.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Jul 31, 11:20pm) References: <19970731232021.10056.qmail@koobera.math.uic.edu> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 31, 11:20pm, D. J. Bernstein wrote: > Subject: Re: Email Subaddressing > > All this does is push the question off a level. Is it desirable to be > > able to mix and match MTA, delivery agent, and submission agent? > > qmail was designed to support multiple delivery agents and submission > agents. [...] > > sendmail can also invoke a variety of delivery agents [...] > > When a delivery agent supports subaddresses---as, e.g., procmail does--- > both qmail and (recent versions of) sendmail can straightforwardly pass > the necessary information to it. That's nice, but that's not the question. The question is whether I can take qmail or sendmail or any other MTA, use arbitary delivery agent X and arbitrary submission agent Y, and expect that both X and Y understand the same format of subaddresses. The present-day answer is obviously "no." Is there any way to make the answer be "yes" other than standardizing the format subaddresses? From owner-ietf-822 Thu Jul 31 17:25:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA03905 for ietf-822-bks; Thu, 31 Jul 1997 17:25:58 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA03901 for ; Thu, 31 Jul 1997 17:25:54 -0700 (PDT) Received: (qmail 10446 invoked by uid 666); 1 Aug 1997 00:29:53 -0000 Date: 1 Aug 1997 00:29:53 -0000 Message-ID: <19970801002953.10445.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > Is there any way to make the answer be "yes" MTAs and LDAs that don't support what the users want are thrown away. Mailing list owners want per-recipient VERPs, for example. sendmail doesn't support per-recipient VERPs. So they switch to qmail. This is called competition. It's how the real world makes progress. > other than standardizing the format subaddresses? It's none of your business how a host interprets its local addresses. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Fri Aug 1 07:48:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA11884 for ietf-822-bks; Fri, 1 Aug 1997 07:48:48 -0700 (PDT) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.5/8.7.3) with SMTP id HAA11875 for ; Fri, 1 Aug 1997 07:48:43 -0700 (PDT) Received: by callandor.cybercash.com; id KAA25954; Fri, 1 Aug 1997 10:41:04 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma025934; Fri, 1 Aug 97 10:40:48 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA25771; Fri, 1 Aug 97 10:46:29 EDT Date: Fri, 1 Aug 1997 10:46:28 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: ietf-822@imc.org Subject: Re: Email Subaddressing In-Reply-To: <19970731083054.3080.qmail@koobera.math.uic.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-822@imc.org Precedence: bulk Dan, I'm not sure if the benefits warrant standardization but I don't accept your arguments by dogmatic assertion: On 31 Jul 1997, D. J. Bernstein wrote: > Date: 31 Jul 1997 08:30:54 -0000 > From: D. J. Bernstein > > > There are two cases where MUAs need to cooperate with subaddresses: > > 1) MUAs which don't allow from to be edited otherwise. > > This is a purely local configuration problem. If agents wish to constrain from addresses to fight spoofing or whatever but allow subaddress editing, they can't do it because there is no uniformity of subadressing. If there were a standard, they could. I believe this would be a benefit. Standarizing things has benefits and costs. The benefits are not eliminated by you enormous distaste for the particular standarization or your failure to acknowledge the benefits. > > 2) MUAs which validate local addresses against a white pages or authdb > > service. > > A service that claims to check mail addresses obviously has to > understand subaddresses. This is a purely local configuration problem. > > > 1) List server restricts posting to subscribers. > > You have no right to demand that list owners accept your mail. The closest thing I've seen to a demand is your demand that this not be standardized. Most list owners want to accept mail and if subaddressing were standardized, I believe many list servers would adapt to the standard. If it is not standardized, some sort of informal consensus might develop but it would be much slower. > > There are several cases where a final delivery agent needs to cooperate > > with subaddresses: > > All of those cases are purely local configuration problems. > > I suppose next we're going to see a document explaining how sendmail > interacts with procmail, and requiring that all MTAs and LDAs work the > same way. I don't know where you get this idea that IETF standards are requirements. I supose you could say that of the tiny handful that are classified as "mandatory", but that certainly doens't include *any* of the email standards most of which are in the "recommended" or "elective" categories of IETF standards. See RFC 2200. > ---Dan > Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-ietf-822 Fri Aug 1 10:39:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA15093 for ietf-822-bks; Fri, 1 Aug 1997 10:39:04 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA15088 for ; Fri, 1 Aug 1997 10:38:57 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id KAA32104 for ietf-822@imc.org; Fri, 1 Aug 1997 10:42:55 -0700 From: "Bart Schaefer" Message-Id: <970801104254.ZM32103@candle.brasslantern.com> Date: Fri, 1 Aug 1997 10:42:54 -0700 In-Reply-To: <19970801002953.10445.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Aug 1, 12:29am) References: <19970801002953.10445.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Aug 1, 12:29am, D. J. Bernstein wrote: } Subject: Re: Email Subaddressing } } > Is there any way to make the answer be "yes" } } MTAs and LDAs that don't support what the users want are thrown away. That's very nice in theory, but in the "real world" the MTAs and LDAs are more often chosen on the basis of what the MTA administrator wants. } This is called competition. It's how the real world makes progress. So somebody who wants to create and market *only* an LDA or *only* a submission agent should be shut out of the competitive process because there's no way to interoperate? I'd rather see competition on quality and versatility than on proprietary data formats. } > other than standardizing the format subaddresses? } } It's none of your business how a host interprets its local addresses. It's certainly the business of the users of that host. In the "real world" an awful lot of those users are sitting on the far side of POP or IMAP and SMTP connections, with control over how their personal MUA is configured but absolutely no control over the host that interprets their local addresses. How can those remote users obtain the benefits of subaddressing? (BTW, I tried to follow http://pobox.com/~djb/ezmlm.html and got "http://pobox.com/nobodyezmlm.html - 404 file not found".) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Fri Aug 1 11:29:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA15626 for ietf-822-bks; Fri, 1 Aug 1997 11:29:06 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA15622 for ; Fri, 1 Aug 1997 11:29:03 -0700 (PDT) Received: (qmail 16938 invoked by uid 666); 1 Aug 1997 18:33:04 -0000 Date: 1 Aug 1997 18:33:04 -0000 Message-ID: <19970801183304.16937.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > If agents wish to constrain from addresses to fight spoofing or whatever but > allow subaddress editing, they can't do it because there is no uniformity of > subadressing. Sorry, but you're wrong. The agent can rely on local configuration to decide which addresses are permitted for each user. My ``addalias'' program, published in 1993, does exactly this. An MUA that reads the addalias configuration file for From control will follow the same rules. > I'm not sure if the benefits warrant standardization but I don't accept > your arguments by dogmatic assertion: And I don't accept yours. The difference is that my arguments are supported by facts. > Standarizing things has benefits and costs. But standardizing user interfaces, no matter how beneficial, is none of the IETF's business. > I don't know where you get this idea that IETF standards are requirements. What are you talking about? I said ``document... requiring that all MTAs and LDAs work the same way.'' ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Fri Aug 1 11:51:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA15814 for ietf-822-bks; Fri, 1 Aug 1997 11:51:36 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA15810 for ; Fri, 1 Aug 1997 11:51:33 -0700 (PDT) Received: (qmail 17267 invoked by uid 666); 1 Aug 1997 18:55:34 -0000 Date: 1 Aug 1997 18:55:34 -0000 Message-ID: <19970801185534.17266.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > So somebody who wants to create and market *only* an LDA or *only* a > submission agent should be shut out of the competitive process because > there's no way to interoperate? I specifically pointed out that submission agents in qmail are interchangeable, and that delivery agents are interchangeable even across qmail and sendmail. > How can those remote users obtain the benefits of subaddressing? They select software that can easily be configured to handle their local subaddresses. > (BTW, I tried to follow http://pobox.com/~djb/ezmlm.html and got > "http://pobox.com/nobodyezmlm.html - 404 file not found".) Thanks. Looks like pobox screwed up their forwarding for FTP URLs. You can use ftp://koobera.math.uic.edu/www/ezmlm.html for now. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Fri Aug 1 12:06:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA15908 for ietf-822-bks; Fri, 1 Aug 1997 12:06:38 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA15904 for ; Fri, 1 Aug 1997 12:06:34 -0700 (PDT) Received: from eleanor.innosoft.com ("port 52856"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILXB1MCDSM8WX9VK@INNOSOFT.COM> for ietf-822@imc.org; Fri, 1 Aug 1997 12:09:34 PDT Date: Fri, 01 Aug 1997 12:11:24 -0700 (PDT) From: Chris Newman Subject: Re: Email Subaddressing In-reply-to: <19970801183304.16937.qmail@koobera.math.uic.edu> To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Fri, 1 Aug 1997, D. J. Bernstein wrote: > But standardizing user interfaces, no matter how beneficial, is none of > the IETF's business. Most of RFC 822 impacts the user interface. In fact, you were recently suggesting that a Wide-Reply-To header be standardized -- thereby mandating a user interface to that header. The IETF's job is to promote multi-vendor interoperability by defining standardized protocols. While it's good to avoid unnecessary constraints on the user interface, almost every application protocol has a profound impact on the way a user interface works. Standardizing one subaddress format means that any product which chooses to use the standard subaddress format (and this choice is by no means mandatory) will interoperate with subaddress support in other products implementing the standard. - Chris From owner-ietf-822 Fri Aug 1 12:29:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA16111 for ietf-822-bks; Fri, 1 Aug 1997 12:29:46 -0700 (PDT) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA16107 for ; Fri, 1 Aug 1997 12:29:42 -0700 (PDT) Received: by callandor.cybercash.com; id PAA17867; Fri, 1 Aug 1997 15:22:06 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma017833; Fri, 1 Aug 97 15:21:40 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA02500; Fri, 1 Aug 97 15:27:21 EDT Date: Fri, 1 Aug 1997 15:27:21 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: ietf-822@imc.org Subject: Re: Email Subaddressing In-Reply-To: <19970801183304.16937.qmail@koobera.math.uic.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-822@imc.org Precedence: bulk On 1 Aug 1997, D. J. Bernstein wrote: > Date: 1 Aug 1997 18:33:04 -0000 > From: D. J. Bernstein > > > If agents wish to constrain from addresses to fight spoofing or whatever but > > allow subaddress editing, they can't do it because there is no uniformity of > > subadressing. > > Sorry, but you're wrong. The agent can rely on local configuration to > decide which addresses are permitted for each user. "can" does not mean it is the best way. >... > > Standarizing things has benefits and costs. > > But standardizing user interfaces, no matter how beneficial, is none of > the IETF's business. Nonsense. The IETF has zillions of standards that effect user interface. How 822 heaers and domain names and IP addresses are formed and parsed for example. Although, from another point of view, these are actually standards for the wire format. Just as a "+" separator for subaddressing would, in principle, only effect the wire format. A UI could have separate text boxes for the pieces of the local part, for example. > > I don't know where you get this idea that IETF standards are requirements. > > What are you talking about? I said ``document... requiring that all MTAs > and LDAs work the same way.'' We'rem talking about an effort to create a standard for email subaddressing. > ---Dan Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-ietf-822 Fri Aug 1 12:42:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA16209 for ietf-822-bks; Fri, 1 Aug 1997 12:42:24 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA16205 for ; Fri, 1 Aug 1997 12:42:18 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id MAA32498 for ietf-822@imc.org; Fri, 1 Aug 1997 12:46:17 -0700 From: "Bart Schaefer" Message-Id: <970801124616.ZM32497@candle.brasslantern.com> Date: Fri, 1 Aug 1997 12:46:16 -0700 In-Reply-To: <19970801183304.16937.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Aug 1, 6:33pm) References: <19970801183304.16937.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Aug 1, 6:33pm, D. J. Bernstein wrote: } Subject: Re: Email Subaddressing } } > Standarizing things has benefits and costs. } } But standardizing user interfaces, no matter how beneficial, is none of } the IETF's business. I'm wondering if we have two separate points of dispute getting mixed into the same argument. The draft as Chris wrote it consists of two major parts: A syntax for subaddresses in local parts, and rules for how various agents should treat local-parts that include subaddresses. I agree that some of the rules for the semantics of subaddressing could intrude on user interface and host policy. The one and only rule that is necessary is that the primary address always identifies the same entity regardless of what subaddress is attached. (If that primary entity wants to dispatch certain subadresses to other entities, that's entirely up to the primary entity or its representative.) Further, the interpretation of local-parts as address plus subaddress can be limited entirely to the host identified by the domain-part; it's neither necessary to require nor necessary to prohibit interpretation by intermediaries like mailing list managers. The syntax, however, is entirely a data format, not a user interface. I think Dan's remark above is directed at the semantics of local-parts; but it's not clear whether the "benefits and costs" remark (sorry, don't remember who wrote it) is referring to the entire draft or only to the syntax dispute. I want to stick to the syntax for now. Even if that syntax is opaque to relays and other intermediaries, it is necessary for it to be transparent to LDAs and submission agents within the interpreting domain. One way to make the syntax transparent is to standardize it; I've been asking for alternatives, but the only suggestion so far is that we throw away combinations of agents that don't already understand one another. Not very helpful either to those who'd like to change existing agents to be able to understand, nor to those who want to write new agents. One alternative that I've thought of is to make it possible to discover the syntax. This is effectively what Dan's ``addalias'' program does by sharing its configuration file. It would certainly be possible to create a simple protocol, possibly as part of the ietf-submit work already in progress, for remote clients to learn the local-part syntax of their server host. However, we've already seen how well such a discovery mechanism works with hierarchy separators in the IMAP4 protocol: To wit, badly, if at all. Nearly everyone agrees that it would have been preferable to pick a hierarchy separator and standardize it, even if that means restricting the mailbox names that the server can present. The situation here is no different; standardizing a character to separate primary address from subaddress is far more workable than standardizing a discovery mechanism, even if it means restricting the primary addresses that a server can support. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Fri Aug 1 12:46:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA16259 for ietf-822-bks; Fri, 1 Aug 1997 12:46:19 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA16255 for ; Fri, 1 Aug 1997 12:46:16 -0700 (PDT) Received: (qmail 17847 invoked by uid 666); 1 Aug 1997 19:50:18 -0000 Date: 1 Aug 1997 19:50:17 -0000 Message-ID: <19970801195017.17846.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > In fact, you were recently > suggesting that a Wide-Reply-To header be standardized Absolutely not. I have suggested that the IETF _define_ useful ``reply'' concepts. I have repeatedly emphasized that the relation between those ``reply'' concepts and the user interface is none of the IETF's business. I have also pointed out several times that ``Wide-Reply-To'', being new functionality, is not ready for standardization. > almost every application protocol has a profound > impact on the way a user interface works. Most protocols have at most a superficial effect on user interfaces. The occasional protocols designed for human use as well as computer use, such as RFC 822, are interoperability disasters, certainly not something to be imitated. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Fri Aug 1 13:02:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA16411 for ietf-822-bks; Fri, 1 Aug 1997 13:02:27 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA16407 for ; Fri, 1 Aug 1997 13:02:22 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id NAA32568 for ietf-822@imc.org; Fri, 1 Aug 1997 13:06:21 -0700 From: "Bart Schaefer" Message-Id: <970801130620.ZM32567@candle.brasslantern.com> Date: Fri, 1 Aug 1997 13:06:20 -0700 In-Reply-To: <19970801185534.17266.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Aug 1, 6:55pm) References: <19970801185534.17266.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Aug 1, 6:55pm, D. J. Bernstein wrote: } Subject: Re: Email Subaddressing } } > So somebody who wants to create and market *only* an LDA or *only* a } > submission agent should be shut out of the competitive process because } > there's no way to interoperate? } } I specifically pointed out that submission agents in qmail are } interchangeable, and that delivery agents are interchangeable even } across qmail and sendmail. There must be some set of rules for how submission and delivery agents have to behave in order to be interchanged. Isn't what Chris suggests (at the syntactic level) simply a standardization of one of those rules? } > How can those remote users obtain the benefits of subaddressing? } } They select software that can easily be configured to handle their local } subaddresses. Isn't one of the IETF's goals to help make a wider variety of such software available? Doesn't knowing what kinds of configuration are expected help developers to write configurable software? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Fri Aug 1 15:11:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA21859 for ietf-822-bks; Fri, 1 Aug 1997 15:11:16 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA21847 for ; Fri, 1 Aug 1997 15:11:12 -0700 (PDT) Received: (qmail 18920 invoked by uid 666); 1 Aug 1997 22:15:13 -0000 Date: 1 Aug 1997 22:15:13 -0000 Message-ID: <19970801221513.18919.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > A syntax for subaddresses in local parts, Sensible definitions such as The ``plus-terminated prefix'' of an address is everything up to and not including the first "+" character, or the entire address if it does not contain a "+" character. or The ``dash-separated components'' of an address are its maximal substrings not containing "-" characters. For example, the dash-separated components of "jean-marc-sos-request" are the strings "jean", "marc", "sos", and "request". are fine with me. Such definitions might be useful in, e.g., an informational document surveying common address formats and their uses. > The one and only rule that > is necessary is that the primary address always identifies the same > entity regardless of what subaddress is attached. What does this mean? What is an ``entity''? Why is this rule necessary? More importantly, that rule is inconsistent with reality. There are a+b@host and a+c@host addresses that are _not_ the same entity. > I've been asking for alternatives, but the only > suggestion so far is that we throw away combinations of agents that > don't already understand one another. Not very helpful either to those > who'd like to change existing agents to be able to understand, nor to > those who want to write new agents. On the contrary. Someone who wants to write (e.g.) a UNIX delivery agent that supports qmail's address hierarchy simply has to use the variables supplied by qmail-local: LOCAL, USER, EXT, EXT2, EXT3, etc. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Fri Aug 1 18:27:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA28626 for ietf-822-bks; Fri, 1 Aug 1997 18:27:04 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA28622 for ; Fri, 1 Aug 1997 18:27:00 -0700 (PDT) Received: from eleanor.innosoft.com ("port 52970"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILXOCCJ6VY8WXF8Q@INNOSOFT.COM> for ietf-822@imc.org; Fri, 1 Aug 1997 18:30:03 PDT Date: Fri, 01 Aug 1997 18:31:54 -0700 (PDT) From: Chris Newman Subject: Re: Email Subaddressing In-reply-to: <19970801221513.18919.qmail@koobera.math.uic.edu> To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Fri, 1 Aug 1997, D. J. Bernstein wrote: > What does this mean? What is an ``entity''? Why is this rule necessary? > > More importantly, that rule is inconsistent with reality. There are > a+b@host and a+c@host addresses that are _not_ the same entity. The important point here is that a@host controls where mail to a+b@host and a+c@host is routed. That's what I mean by subaddress as distinct from a simple naming hierarchy. - Chris From owner-ietf-822 Fri Aug 1 19:18:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA28980 for ietf-822-bks; Fri, 1 Aug 1997 19:18:19 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id TAA28976 for ; Fri, 1 Aug 1997 19:18:16 -0700 (PDT) Received: (qmail 20719 invoked by uid 666); 2 Aug 1997 02:22:08 -0000 Date: 2 Aug 1997 02:22:08 -0000 Message-ID: <19970802022208.20718.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > > More importantly, that rule is inconsistent with reality. There are > > a+b@host and a+c@host addresses that are _not_ the same entity. > The important point here is that a@host controls where mail to a+b@host > and a+c@host is routed. I explicitly said that I'm talking about reality, not your proposal. In the real world, what you're saying is simply not true. For example, there's no ``info-g'' user controlling the info-g++ mailing list. If you want to document what people do at CMU, fine. But please give it an honest label that reflects your limited experience: e.g., ``The AFS Mail Addressing System.'' Don't pretend that it's a de facto standard. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Fri Aug 1 22:38:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA29809 for ietf-822-bks; Fri, 1 Aug 1997 22:38:25 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id WAA29805 for ; Fri, 1 Aug 1997 22:38:19 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id WAA01674 for ietf-822@imc.org; Fri, 1 Aug 1997 22:42:17 -0700 From: "Bart Schaefer" Message-Id: <970801224217.ZM1673@candle.brasslantern.com> Date: Fri, 1 Aug 1997 22:42:16 -0700 In-Reply-To: <19970801221513.18919.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Aug 1, 10:15pm) References: <19970801221513.18919.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Aug 1, 10:15pm, D. J. Bernstein wrote: } Subject: Re: Email Subaddressing } } > The one and only rule that } > is necessary is that the primary address always identifies the same } > entity regardless of what subaddress is attached. } } What does this mean? What is an ``entity''? It doesn't matter what an entity is. An entity is whatever the local-part would refer to if the subaddress were ignored. Could be a user account, could be an alias, could be anything. Up to the interpreting domain. } Why is this rule necessary? So that new subaddresses can be created without having to create new primary addresses. Without that rule, all you have is flat aliasing. It's certainly possible to implement equivalent behavior by using flat aliasing, but then you need rules to prevent name collisions. } More importantly, that rule is inconsistent with reality. There are } a+b@host and a+c@host addresses that are _not_ the same entity. Note that I avoided saying what the separator character is. But it really doesn't matter; if a domain that already has a+b and a+c local- parts wants to begin using "+" as a subaddress separator, it can set up a psuedo-user "a" whose only purpose is to redirect mail for the "a+b" and "a+c" local-parts to the right real places. Nobody outside that domain should be counting on the final interpretation of "a+b" and "a+c". The idea is that entities *inside* the domain can count on it, *if* the domain claims to support subaddressing. } > I've been asking for alternatives, but the only } > suggestion so far is that we throw away combinations of agents that } > don't already understand one another. Not very helpful either to those } > who'd like to change existing agents to be able to understand, nor to } > those who want to write new agents. } } On the contrary. Someone who wants to write (e.g.) a UNIX delivery agent } that supports qmail's address hierarchy simply has to use the variables } supplied by qmail-local: LOCAL, USER, EXT, EXT2, EXT3, etc. That's wonderful if all I want to write is a new agent that interoperates with qmail and other qmail agents. What if I want to write an agent that I can expect to interoperate with any of a large number of other MTAs and LDAs or submission agents? Are you going to convince Netscape and MS and Software.com and Innosoft etc. all to adopt your scheme on all platforms they support? This discussion has now reached the point of arguing only for the sake of arguing, so I'm bailing out until some other people have had a say. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Sat Aug 2 00:13:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA00290 for ietf-822-bks; Sat, 2 Aug 1997 00:13:48 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id AAA00286 for ; Sat, 2 Aug 1997 00:13:44 -0700 (PDT) Received: (qmail 22324 invoked by uid 666); 2 Aug 1997 07:17:47 -0000 Date: 2 Aug 1997 07:17:47 -0000 Message-ID: <19970802071747.22323.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk The IETF is the Internet Engineering Task Force, not the UNIX MTA-LDA Interface Engineering Task Force. I have neither the time nor the patience to explain operating system design, or my users' needs, to a parade of inexperienced IETF nitwits. The burden is on the aforementioned nitwits to read RFC 2119, section 6, and to butt out of areas where they don't belong. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Sat Aug 2 12:54:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA05132 for ietf-822-bks; Sat, 2 Aug 1997 12:54:43 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA05128 for ; Sat, 2 Aug 1997 12:54:38 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id MAA05173 for ietf-822@imc.org; Sat, 2 Aug 1997 12:58:40 -0700 From: "Bart Schaefer" Message-Id: <970802125839.ZM5172@candle.brasslantern.com> Date: Sat, 2 Aug 1997 12:58:39 -0700 In-Reply-To: <19970802071747.22323.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Aug 2, 7:17am) References: <19970802071747.22323.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Aug 2, 7:17am, D. J. Bernstein wrote: } Subject: Re: Email Subaddressing } } The IETF is the Internet Engineering Task Force, not the UNIX MTA-LDA } Interface Engineering Task Force. I don't give a damn how a Unix MTA and LDA interface to one another, and certainly if that were all that's involved here there'd be no need for a spec. I am interested in how the submission agent that comes with my Mac MUA interfaces with the MTA and LDA on the Win/NT host that's my ISP's IMAP server. Oh, and by the way, the ISP that's my IMAP server is not the same one to which my Mac makes its PPP connection; in fact, there are three different ISPs through which I send and recieve mail, but only one submission agent on my Mac. One ISP doesn't do subaddressing, and the other two don't do it the same way. As I said quite some while before, this is mainly an inconvenience; it means I just don't use subaddressing anywhere, even though I'd like to. Is it a bad enough inconvenience that a standard is needed to eliminate it? I'm not sure. But I certainly haven't seen anything to convince me that it'll go away by itself without one. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Sat Aug 2 15:10:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA05912 for ietf-822-bks; Sat, 2 Aug 1997 15:10:48 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA05908 for ; Sat, 2 Aug 1997 15:10:45 -0700 (PDT) Received: (qmail 29257 invoked by uid 666); 2 Aug 1997 22:15:11 -0000 Date: 2 Aug 1997 22:15:11 -0000 Message-ID: <19970802221511.29256.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > I just don't use subaddressing anywhere, What exactly is the problem? Are you having trouble receiving messages? Are you having trouble sending messages? Many other people use subaddresses without trouble. You've told us that one of your ISPs doesn't support subaddressing. Has it occurred to you that mail receipt isn't free? Some ISPs charge for subaddresses; some of them don't have appropriate software. Some ISPs won't give you _any_ addresses. If you don't like that, use a different ISP. Where is the interoperability problem? You've told us that your two other ISPs use different subaddressing systems. So what? Why should they match? Different domains have different address spaces. Where is the interoperability problem? > I am interested in how the submission agent that comes with my Mac MUA > interfaces with the MTA and LDA on the Win/NT host that's my ISP's IMAP > server. What are you talking about? Submission agents don't talk to LDAs, or to IMAP servers. Your MUA probably doesn't even include a submission agent; instead it uses SMTP (incorrectly, but by bilateral agreement) to relay what you typed to a submission agent on the server. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Sat Aug 2 16:28:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA06205 for ietf-822-bks; Sat, 2 Aug 1997 16:28:57 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA06200 for ; Sat, 2 Aug 1997 16:28:52 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id QAA05838 for ietf-822@imc.org; Sat, 2 Aug 1997 16:32:54 -0700 From: "Bart Schaefer" Message-Id: <970802163254.ZM5837@candle.brasslantern.com> Date: Sat, 2 Aug 1997 16:32:54 -0700 In-Reply-To: <19970802221511.29256.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Aug 2, 10:15pm) References: <19970802221511.29256.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Aug 2, 10:15pm, D. J. Bernstein wrote: } Subject: Re: Email Subaddressing } } > I just don't use subaddressing anywhere, } } What exactly is the problem? As I said, it's inconvenience. } You've told us that one of your ISPs doesn't support subaddressing. Has } it occurred to you that mail receipt isn't free? That's irrelevant. I'm not interested in forcing the ISP to support subaddressing if it's too expensive for some strange reason. I am interested in encouraging MTA and LDA writers to include subaddressing support so that ISPs could more easily find MTAs that support whatever features led them to pick the one they have now, and subaddressing too. But that's a reason for an informational document, not a standard. } You've told us that your two other ISPs use different subaddressing } systems. So what? Why should they match? Different domains have } different address spaces. Where is the interoperability problem? The interoperability problem is that the software on my Mac has to support both schemes. It's much easier to write software if there is only one scheme to support. So if there's a standard scheme, more MTA software will support it and more MUA software will support it, and it'll be easier for me to find software that works for multiple ISPs. } > I am interested in how the submission agent that comes with my Mac MUA } > interfaces with the MTA and LDA on the Win/NT host that's my ISP's IMAP } > server. } } What are you talking about? Submission agents don't talk to LDAs, or to } IMAP servers. No, but if I'm going to put the right thing in my Reply-To or From header, I need to know what format the MTA and LDA are willing to accept when my recipients send mail back to me. And if the submission agent is in charge of filling in those headers, as you suggested it should be, then it has to interoperate with the LDA, albeit by a very circuitous route. } Your MUA probably doesn't even include a submission agent; } instead it uses SMTP (incorrectly, but by bilateral agreement) to relay } what you typed to a submission agent on the server. That's true, but the server (also incorrectly but by bilateral agreement) doesn't have a submission agent either. I simply adopted your terminology because you refused to discuss the real-world situation of MUAs talking directly to MTAs. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Sat Aug 2 17:52:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA06547 for ietf-822-bks; Sat, 2 Aug 1997 17:52:10 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA06543 for ; Sat, 2 Aug 1997 17:52:06 -0700 (PDT) Received: (qmail 230 invoked by uid 666); 3 Aug 1997 00:56:43 -0000 Date: 3 Aug 1997 00:56:42 -0000 Message-ID: <19970803005642.229.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > As I said, it's inconvenience. _What_ is inconvenient? Chris's proposed mailing-list rule, though dangerously naive, at least made it obvious what problem he was worried about. Your proposal is so vague that I have no idea what it's supposed to accomplish. > The interoperability problem is that the software on my Mac has to > support both schemes. What for? I know people using subaddresses with a variety of MUAs. The MUAs all deal with incoming _mailboxes_, not incoming addresses. Why should an MUA care which addresses are owned by the user? Why don't you skip the vague generalities and give some specific examples? Yes or no: Are you having trouble sending messages? If yes, what is an example of a message that you wanted to send? How did the system stop you from sending that message? Yes or no: Are you having trouble receiving messages? If yes, what is an example of a message that you wanted to receive? How did the system stop you from receiving that message? > No, but if I'm going to put the right thing in my Reply-To or From header, > I need to know what format the MTA and LDA are willing to accept when my > recipients send mail back to me. Huh? The sysadmin gives the user an e-mail address. The user types it into his MUA. Millions of users have successfully accomplished this feat. Why should the MUA care about internal structure in the user's address? All it does is copy the address. > That's true, but the server (also incorrectly but by bilateral agreement) > doesn't have a submission agent either. False. The server (most commonly sendmail; sometimes qmail with qmail-inject) includes a submission agent. Have you already forgotten what ``submission agent'' means? I said two days ago what submission agents do. > I simply adopted your terminology > because you refused to discuss the real-world situation of MUAs talking > directly to MTAs. False. The real-world situation is that MUAs talk to submission agents. Many MTAs do not provide submission services by default. When MUAs talk to those MTAs directly, malformed messages escape onto the Internet. In some cases recipients can't respond since the From field is unqualified. This problem is, as I said, solved by bilateral agreement: the MTA is configured to provide submission services for certain IP addresses. sendmail includes both a submission agent and an MTA, and currently treats every message as a submission, but sendmail's author has been adding options to change this. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Sat Aug 2 21:34:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA07403 for ietf-822-bks; Sat, 2 Aug 1997 21:34:19 -0700 (PDT) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.5/8.7.3) with SMTP id VAA07399 for ; Sat, 2 Aug 1997 21:34:16 -0700 (PDT) Received: by callandor.cybercash.com; id AAA26122; Sun, 3 Aug 1997 00:26:39 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma026120; Sun, 3 Aug 97 00:26:28 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA17117; Sun, 3 Aug 97 00:32:13 EDT Date: Sun, 3 Aug 1997 00:32:12 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: ietf-822@imc.org Subject: Re: Email Subaddressing In-Reply-To: <19970802071747.22323.qmail@koobera.math.uic.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-822@imc.org Precedence: bulk On 2 Aug 1997, D. J. Bernstein wrote: > Date: 2 Aug 1997 07:17:47 -0000 > From: D. J. Bernstein > To: ietf-822@imc.org > Subject: Re: Email Subaddressing > > ... > > I have neither the time nor the patience to explain operating system > design, or my users' needs, to a parade of inexperienced IETF nitwits. Well, you do seem to have plenty of time to post messages showing how incapable you are of communicating with anyone having a different viewpoint. > The burden is on the aforementioned nitwits to read RFC 2119, section 6, > and to butt out of areas where they don't belong. Sorry, that section has almost nothing to do with it. For example, people can interoperate fine at the IP level with no domain name service. And someone who wanted to could keep jumping up and down and arguing primarily by dogmantic assertion, as you do, that IP numbers are all you really need to interoperate and that symbolic names are a purely private issue. After all, if people don't like a particular symbolic naming scheme, surely the product will fail in the market place. No need for standards here. That's about what you are saying about subaddressing. In fact, almost all IETF standards are of the form, if you want to do X, here is how you should do it. The fact that not everyone wants to do X and can thus interoperate without any X, standard or not, is not very relevant. And the fact that people can interoperate doing X by using various ad hoc non-standarized ways, while a factor of varying strength against standardization, is by no means a bar to it. > ---Dan > Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html Like most of the nitwits out here, I would like to see some sort of rough consensus on a syntax for subaddress for quite a few reasons including some I have mentioned previously and as a way to bring a bit more pressure on product vendors to include such a feature. Are you putting up such exaggerated and overblown resistence to this idea because you want to minimize the probability of the inclusion of such a feature in competing product? Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-ietf-822 Sat Aug 2 23:09:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA07748 for ietf-822-bks; Sat, 2 Aug 1997 23:09:54 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA07743 for ; Sat, 2 Aug 1997 23:09:47 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id XAA07072 for ietf-822@imc.org; Sat, 2 Aug 1997 23:13:51 -0700 From: "Bart Schaefer" Message-Id: <970802231350.ZM7071@candle.brasslantern.com> Date: Sat, 2 Aug 1997 23:13:50 -0700 In-Reply-To: <19970803005642.229.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Aug 3, 12:56am) References: <19970803005642.229.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Aug 3, 12:56am, D. J. Bernstein wrote: } Subject: Re: Email Subaddressing } } > As I said, it's inconvenience. } } _What_ is inconvenient? Not using subaddressing to categorize my incoming mail. } > The interoperability problem is that the software on my Mac has to } > support both schemes. } } What for? So it can put the right ones in the Reply-To and/or From headers based on which ISP I'm sending through. } I know people using subaddresses with a variety of MUAs. The MUAs all } deal with incoming _mailboxes_, not incoming addresses. Why should an } MUA care which addresses are owned by the user? To provide additional mail management features for the user. It's not necessary, but it's convenient. } Yes or no: Are you having trouble sending messages? No, but not really relevant. } Yes or no: Are you having trouble receiving messages? Also not relevant. The question is not whether the message arrives, but what happens to it after it does. } Why should the MUA care about internal structure in the user's address? } All it does is copy the address. It is true that this is all that many MUAs do today. That doesn't mean it's the best behavior, especially for a user who has multiple addresses. Example situations: ISP "A" supports both subaddressing and IMAP. I can FTP to the server and set up a configuration file so that messages with different incoming subaddresses end up in different mailboxes, which I can then access via IMAP. This is as close as things get to your model. But my MUA can't see the configuration file; it has to have the matching subaddresses to fill in submitted From and/or Reply-To in its own separate configuration. ISP "B" supports subaddressing but only POP. All messages are delivered to the POP mailbox of the primary address; it's up to the POP client to spot the subaddress and categorize the messages after downloading them. The ISP assigns only the primary address; the subaddresses are up to me to make up. They don't use the same format as ISP "A" subaddresses. There's no LDA configuration file, because the subaddresses are ignored for purposes of delivery; everything has to be configured at the MUA. (An additional annoyance about "B" is that it doesn't give me a hook on the envelope address, only what appears in the headers, but that doesn't have anything to do with the address formats.) ISP "C" supports only POP and not subaddressing, but it's where I have my low-cost internet connection. The goal I'm trying to attain is that messages that pass through all three ISPs are categorized by incoming address into local mailboxes on my home machine. I can actually do this most easily with ISP "B"; one remote mailbox is opened, and my MUA sorts out the messages as they are downloaded. (Unfortunately, it doesn't work as well as it could because the envelope information is gone by that time.) I can do it with ISP "A" if I do more sophisticated remote access, opening one remote mailbox for every corresponding local one. I can't do it with ISP "C" at all. In a better world, I'd have *one* subaddress configuration for both "A" and "B", which is either part of my MUA or at least is tied to my home machine. I might choose to take advantage of the configuration on "A", but I wouldn't have to. I'd download and categorize mail from both "A" and "B" exactly the same way, via my MUA. And I'd contact "C" and ask them to add support for this same common format. As it is today, I don't make use of any of it, except for a couple of cases on "A" that get used only when I want to send mail to my own home address from my work. I probably would use more if I had the envelope address hooks on "B", because my MUA is configurable enough to support both "A" and "B" formats; but it's still inconvenient to keep the two configurations (MUA and "A") in sync, and that still doesn't give me anything new in the way of leverage with "C". And my MUA's interface on configuring and selecting among subaddresses could be improved if there were only one format to support, as well. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Sun Aug 3 00:40:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA08260 for ietf-822-bks; Sun, 3 Aug 1997 00:40:20 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id AAA08256 for ; Sun, 3 Aug 1997 00:40:17 -0700 (PDT) Received: (qmail 2024 invoked by uid 666); 3 Aug 1997 07:44:50 -0000 Date: 3 Aug 1997 07:44:50 -0000 Message-ID: <19970803074450.2023.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: objections, again Sender: owner-ietf-822@imc.org Precedence: bulk > Are you putting up such exaggerated and overblown resistence to this idea Obviously it's time to refresh your memory: * Software following Chris's proposal can't handle mail for existing names that contain plus signs. (In contrast, qmail automatically handles usernames that contain the separator.) * Chris's delivered-to-owner default violates RFC 2119, section 6. * Chris's syntax requirements prohibit MUAs from sending mail to some valid addresses. * Chris's syntax requirements produce misdirected mail for _all_ quoted addresses when the MTA handles quoting correctly (as, e.g., MMDF does). * Chris's validation restriction is bizarre. * Chris's MLM requirement creates a new security problem when a+b is subscribed to a mailing list and a+c is a different user. * Chris's MLM requirement prohibits cryptographic applications of subaddresses. * The point of Chris's proposal is to solve an MLM problem that is already solved by a separation between posting addresses and subscription addresses---a feature needed by many users anyway. * Chris's other requirements are so unclear as to be useless. In several cases, I suspect the clear versions will be objectionable. * Chris's proposal is not the de facto standard for address hierarchies. * Chris's proposal is inconsistent with the de facto ``-request'' standard when account names are used as mailing lists. Finally, and most importantly, MY USERS DO NOT WANT THESE RESTRICTIONS. Even the ones who prefer + as the usual separator sometimes want more flexibility than Chris's proposal allows. In short, Chris's proposal is a disaster. Now, it's vaguely amusing to see you drawing stupid analogies, accusing me of exaggeration, and blaming me for your failure to communicate; but I'd prefer to see you discuss the specifics. > because you want to minimize the probability of the inclusion of such a > feature in competing product? In fact, users have recently pressured the authors of several other MTAs to imitate qmail's subaddressing. And, of course, some MTAs had the feature years before qmail, though most users were scared away by the poorly designed user interfaces. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Sun Aug 3 01:20:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA08613 for ietf-822-bks; Sun, 3 Aug 1997 01:20:16 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA08608 for ; Sun, 3 Aug 1997 01:20:12 -0700 (PDT) Received: (qmail 2204 invoked by uid 666); 3 Aug 1997 08:24:50 -0000 Date: 3 Aug 1997 08:24:50 -0000 Message-ID: <19970803082450.2203.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Email Subaddressing Sender: owner-ietf-822@imc.org Precedence: bulk > Not using subaddressing to categorize my incoming mail. What I'm asking is for you to explain the link between (1) address hierarchy variability, which you claim is inconvenient, and (2) your failure to use subaddresses, which surely is inconvenient. You keep repeating the claim in #1, and the fact in #2. I don't see the connection. Many users who are faced with address hierarchy variability nevertheless use subaddresses. What makes you different from them? > So it can put the right ones in the Reply-To and/or From headers based > on which ISP I'm sending through. Why do you want to do that? I know many multi-ISP users. They all stick to a single From address. What makes you different? And what does this have to do with subaddressing? [ MUA retrieving messages from several mailboxes by IMAP ] > has to have the matching subaddresses to > fill in submitted From and/or Reply-To in its own separate configuration. Why? This is getting tiresome. Do you know what ``specific example'' means? > it's up to the POP client to > spot the subaddress and categorize the messages after downloading them. I've seen one (experimental) POP client that does this. It doesn't care which addresses the user controls. It simply follows the patterns configured by the user. > In a better world, I'd have *one* subaddress configuration for both "A" > and "B", Details! Details! Details! Show us which addresses A supports. Show us which addresses B supports. Show us which addresses you'd send where. And explain why the variability between subaddress formats in A and B is the crucial factor preventing you from setting this up. > And my MUA's interface on > configuring and selecting among subaddresses could be improved if there > were only one format to support, as well. Which MUA is that? Start giving names. Stop being the sort of useless person that support technicians have nightmares about. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Sun Aug 3 11:10:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA13345 for ietf-822-bks; Sun, 3 Aug 1997 11:10:37 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@ncs-34.nbn.com [199.4.66.34]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA13341 for ; Sun, 3 Aug 1997 11:10:32 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id LAA10009 for ietf-822@imc.org; Sun, 3 Aug 1997 11:13:58 -0700 From: "Bart Schaefer" Message-Id: <970803111358.ZM10008@candle.brasslantern.com> Date: Sun, 3 Aug 1997 11:13:57 -0700 In-Reply-To: <19970803082450.2203.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: Email Subaddressing" (Aug 3, 8:24am) References: <19970803082450.2203.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: Email Subaddressing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Aug 3, 8:24am, D. J. Bernstein wrote: } Subject: Re: Email Subaddressing } } This is getting tiresome. Do you know what ``specific example'' means? A specific example is not relevant. I'm not asking anyone to give me "technical support" with my existing situation; I'd certainly not ask that of someone with your attitude. The question is not "what can I do with my current ISPs?" The question is "how can I avoid having to do something different every time I get a new ISP?" and secondarily "how could I write a program to help other people do the same thing regardless of their ISP?" } > So it can put the right ones in the Reply-To and/or From headers } } Why do you want to do that? Think of the subaddresses as sender-supplied keywords that respondents automatically include in their replies. When I send a message for reason "X", I want the reply address to have a subaddress of "X". Then I know that when I get back a message with "X" in the address, the sender got my address however indirectly from my original with "X" in it. Ideally, I'd make up each new "X" on the fly, without having to tell the LDA or MTA anything about it, yet the response would still end up in the primary address mailbox. I can do this with, for example, sendmail 8.x with the procmail local delivery agent option included in the .cf. Less ideal would be that I have to tell the LDA and/or MTA about "X", in which case it would be nice if I could tell every LDA or MTA exactly the same thing and have it understood in the same way. Since I'd like to invent "X" on the fly, I'd like to limit the number of variables imposed by the domain to the right of the "@". A reasonable limitation seems to me to be either "supports this and does so the same way as every other domain that supports it" vs. "doesn't support it." I can certainly treat all existing MTAs this way, by lumping everybody who employs a different scheme into the "doesn't" camp, but I'd prefer to increase the number of "supports it" domains. If you really can't grasp that without a specific example: Suppose I send a message with "schaefer+party-4-july" in the From field local-part. Now I can filter the responses on "party-4-july". But in order to do that, I had to know that "+" is a separator and "-" is not. } > based on which ISP I'm sending through. } } Why do you want to do that? Actually, I don't want to do that, but I have no choice when the syntax for using subaddresses differs from one ISP to the next. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Sun Aug 3 12:04:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA13615 for ietf-822-bks; Sun, 3 Aug 1997 12:04:06 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA13611 for ; Sun, 3 Aug 1997 12:04:02 -0700 (PDT) Received: from eleanor.innosoft.com ("port 53482"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IM03JD27GK8WXZEU@INNOSOFT.COM> for ietf-822@imc.org; Sun, 3 Aug 1997 12:07:11 PDT Date: Sun, 03 Aug 1997 12:09:01 -0700 (PDT) From: Chris Newman Subject: Re: objections, again In-reply-to: <19970803074450.2023.qmail@koobera.math.uic.edu> To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Sun, 3 Aug 1997, D. J. Bernstein wrote: > * Software following Chris's proposal can't handle mail for > existing names that contain plus signs. (In contrast, qmail > automatically handles usernames that contain the separator.) There are few such names and it can still be configured to handle them. Therefore this is a non-issue. > * Chris's delivered-to-owner default violates RFC 2119, section 6. The keywords are used to get interoperation between MUAs, final delivery agents and mailing list servers with respect to subaddresses as transmitted on the wire. Thus the proposal is entirely within IETF domain and your complaint has no merit. > * Chris's syntax requirements prohibit MUAs from sending mail to > some valid addresses. Only when using subaddresses. This is a minor point which I could be convinced to change and has no bearing on the primary proposal. > * Chris's syntax requirements produce misdirected mail for _all_ > quoted addresses when the MTA handles quoting correctly (as, e.g., > MMDF does). I see no reason why. Please explain. > * Chris's validation restriction is bizarre. This is not a technical complaint and thus has no merit. > * Chris's MLM requirement creates a new security problem when a+b is > subscribed to a mailing list and a+c is a different user. No. In that rare case, a subaddress-aware MLM would allow email with addresses from "a" to manage "a+b" and "a+c"'s subscription. But this is not a real security issue as anyone can generate email from "a", "a+b" or "a+c" regardless. RFC 2015 provides real security. Therefore this cliam has no merit. > * Chris's MLM requirement prohibits cryptographic applications of > subaddresses. How does the MLM requirement conflict with RFC 2015? Or is there another standard you're using? If you're just doing something by private agreement you can use a separator other than "+". Therefore this is a non-issue. > * The point of Chris's proposal is to solve an MLM problem that is > already solved by a separation between posting addresses and > subscription addresses---a feature needed by many users anyway. That is not the sole point of the proposal. However, this claim has merit otherwise. Therefore I will include this as an alternate acceptable solution in the next draft. > * Chris's other requirements are so unclear as to be useless. This claim has merit. I will work to clarify them. It's quite common for a first draft to have unclear sections. > * Chris's proposal is not the de facto standard for address > hierarchies. This cliam has merit. It may be implemented by more different vendors than other formats, but that does not make it de facto. Thus I have previously agreed to alter the wording. Please don't waste our time by repeating an objection I have already agreed to address. > * Chris's proposal is inconsistent with the de facto ``-request'' > standard when account names are used as mailing lists. "-request" is a proposed IETF standard, not just a de facto standard. However, it is naming hierarchy rather than subaddressing and it uses a different separator. Therefore there is no inconsistancy. > Finally, and most importantly, MY USERS DO NOT WANT THESE RESTRICTIONS. > Even the ones who prefer + as the usual separator sometimes want more > flexibility than Chris's proposal allows. Perhaps if you forwarded a user's statement to that effect we'd be more inclined to listen and address the specifics of that complaint. > In fact, users have recently pressured the authors of several other MTAs > to imitate qmail's subaddressing. And, of course, some MTAs had the > feature years before qmail, though most users were scared away by the > poorly designed user interfaces. Out of curiosity, which MTAs other than qmail support your flavor of subaddressing? Here's the deployed support for the "+" style which I'm simply documenting: Interestingly enough, PMDF had support for subaddresses before I started working at Innosoft. CMU's systems had support for subaddresses before I got there. And I was surprised to find that Pine supported the user-validation subaddressing feature. Sendmail supports it (although that may be due to lobbying by CMU) as well. From owner-ietf-822 Sun Aug 3 13:15:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA13943 for ietf-822-bks; Sun, 3 Aug 1997 13:15:36 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA13939 for ; Sun, 3 Aug 1997 13:15:32 -0700 (PDT) Received: (qmail 5544 invoked by uid 666); 3 Aug 1997 20:20:12 -0000 Date: 3 Aug 1997 20:20:12 -0000 Message-ID: <19970803202012.5543.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: finally, an example Sender: owner-ietf-822@imc.org Precedence: bulk > Suppose I > send a message with "schaefer+party-4-july" in the From field local-part. > Now I can filter the responses on "party-4-july". But in order to do > that, I had to know that "+" is a separator and "-" is not. Apparently the sysadmin has told you that you can receive e-mail at schaefer+*. So you type ``schaefer+party-4-july'' into your MUA. If he says schaefer-*, you type ``schaefer-party-4-july'' instead. Or, given appropriate MUA support, you type the ``schaefer+'' or ``schaefer-'' exactly once; then you type exactly the same ``party-4-july'' either way. I don't see the inconvenience here. This all looks very straightforward. How else would you expect this example to work? > A specific example is not relevant. Specific examples are everything. Thank you for providing one. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Sun Aug 3 14:16:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA14232 for ietf-822-bks; Sun, 3 Aug 1997 14:16:24 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA14226 for ; Sun, 3 Aug 1997 14:16:16 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id OAA11070 for ietf-822@imc.org; Sun, 3 Aug 1997 14:20:22 -0700 From: "Bart Schaefer" Message-Id: <970803142021.ZM11069@candle.brasslantern.com> Date: Sun, 3 Aug 1997 14:20:21 -0700 In-Reply-To: <19970803202012.5543.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "finally, an example" (Aug 3, 8:20pm) References: <19970803202012.5543.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: finally, an example MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Aug 3, 8:20pm, D. J. Bernstein wrote: } Subject: finally, an example } } > Suppose I } > send a message with "schaefer+party-4-july" in the From field local-part. } > Now I can filter the responses on "party-4-july". But in order to do } > that, I had to know that "+" is a separator and "-" is not. } } Apparently the sysadmin has told you that you can receive e-mail at } schaefer+*. So you type ``schaefer+party-4-july'' into your MUA. } } If he says schaefer-*, you type ``schaefer-party-4-july'' instead. It's not "schaefer+*" and "schaefer-*". I told you the specifics are not relevant. If you really think its worthwile to pursue this, take it as "schaefer+[^+]*" on one ISP, and "schaefer-[^-+]*" on another. } Or, given appropriate MUA support, you type the ``schaefer+'' or } ``schaefer-'' exactly once; then you type exactly the same } ``party-4-july'' either way. If the intended destination for replies is the first ISP, I have to type "+party-4-july". If the second, I have to type "-party_4_july" or some other permutation. The reason for wanting different reply destinations is irrelevant. } I don't see the inconvenience here. This all looks very straightforward. } How else would you expect this example to work? It'd be much easier if both ISPs accepted one format or the other (I don't care which) and if any more ISPs that I might encounter would also use the same format. Why is that so difficult to comprehend? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Sun Aug 3 15:10:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA14594 for ietf-822-bks; Sun, 3 Aug 1997 15:10:38 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA14590 for ; Sun, 3 Aug 1997 15:10:34 -0700 (PDT) Received: (qmail 6244 invoked by uid 666); 3 Aug 1997 22:15:14 -0000 Date: 3 Aug 1997 22:15:14 -0000 Message-ID: <19970803221514.6243.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: finally, an example Sender: owner-ietf-822@imc.org Precedence: bulk > If the intended destination for replies is the first ISP, I have to type > "+party-4-july". If the second, I have to type "-party_4_july" or some > other permutation. Oh, c'mon, surely you can imagine a better user interface than that. You configure your three ISPs into the MUA, following ISP instructions: SMTP: 1.2.3.4 user: schaefer separator: + domain: isp1.net SMTP: 5.6.7.8 user: schaefer separator: - domain: isp2.net SMTP: 9.10.11.12 user: bs domain: isp3.net Now the MUA gives you a ``subaddress'' box with either ISP 1 or ISP 2. You can type ``party-4-july'' either way. With ISP 3, since you didn't configure a separator, the MUA tells you that subaddressing isn't supported. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Sun Aug 3 15:52:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA14805 for ietf-822-bks; Sun, 3 Aug 1997 15:52:54 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA14801 for ; Sun, 3 Aug 1997 15:52:49 -0700 (PDT) Received: (qmail 6451 invoked by uid 666); 3 Aug 1997 22:57:24 -0000 Date: 3 Aug 1997 22:57:24 -0000 Message-ID: <19970803225724.6450.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: objections, again Sender: owner-ietf-822@imc.org Precedence: bulk > it can still be configured to handle them. How? Consider, for example, the following two accounts (names changed to protect the innocent): widget@foo.com widget+x@foo.com These are project accounts for completely different groups. According to your proposal, mail for widget+x MUST be delivered to widget by default, except that widget MAY be allowed to reconfigure the delivery. Now you seem to be claiming that software can be configured to do widget+(x+*) -> (widget+x)+* Is that capability required by your document? Yes, qmail could pull this sort of trick even if it didn't do the right thing by default, but what about other MTAs? More importantly, your rules violate foo.com's security policy. It is unacceptable for the widget people to receive the widget+x mail. It is unacceptable for the widget people to control the widget+x mail. Do these people have to change their e-mail addresses when they install your ``compliant'' software? [ -request vs. the artificially inconsistent ``+'' separator ] > However, it is naming hierarchy rather than subaddressing and it uses a > different separator. I'm still waiting for an answer to my question on this topic: Is it widget-request or widget+request? > Therefore there is no inconsistancy. Answer the question. > The keywords are used to get interoperation between How can ``MUST do X by default'' be required for interoperation? X isn't even required! It's indistinguishable from ``MUST NOT do X by default'' from an interoperability perspective. Other software can't rely on X and can't rely on not-X. > > * Chris's syntax requirements prohibit MUAs from sending mail to > > some valid addresses. > Only when using subaddresses. The point remains: Your rules prohibit MUAs from sending mail to some valid addresses. > > * Chris's syntax requirements produce misdirected mail for _all_ > > quoted addresses when the MTA handles quoting correctly (as, e.g., > > MMDF does). > I see no reason why. Please explain. When your MUA replies to From: "a,b+c"@d.e it will incorrectly pass "a,b+c"@d.e to the MTA. The address is actually a,b+c@d.e. It can be _encoded_ as "a,b+c"@d.e under RFC 821 and RFC 822, but the quotes are not part of the address. The incorrect address will work with sendmail, but that doesn't make it right. sendmail violates the quoting rules in RFC 821 and RFC 822. It's much better in practice for the MUA to avoid address parsing. The MTA's submission agent can take care of it. > > * Chris's validation restriction is bizarre. > This is not a technical complaint and thus has no merit. Amusing---your previous response to this criticism was ``good point.'' Let me rephrase. Your validation restriction has so many obviously wrong effects that it can't possibly be what you meant. It is, like your many unclear requirements, a result of bad writing; the fact that it's clear is merely an accident. > But this is > not a real security issue as anyone can generate email from "a", "a+b" or > "a+c" regardless. Wrong. I've seen a list that, before calling the MLM software, invokes PGP to verify that the message is PGP-signed by the sender. The MLM then checks the sender address against the subscription list. Subscribers have to be preapproved (though there are some open sublists for lurkers). Your requirement destroys this security mechanism. An attacker takes an approved ``joe@isp.net'' address and registers a ``joe+haha@isp.net'' PGP key; PGP is satisfied; but an MLM following your rules has to ignore the +haha when it's checking the address. Your denial of this security issue is despicable. > > * Chris's MLM requirement prohibits cryptographic applications of > > subaddresses. > How does the MLM requirement conflict with RFC 2015? I said ``cryptographic applications of subaddresses,'' not ``RFC 2015.'' I already gave cookies as an example. It's a _different_ mechanism, see? [ proposal is not the de facto standard ] > Thus I have previously agreed to alter the wording. Inadequate. Your use of the term ``subaddressing'' is still deceptive. Choose a phrase that accurately identifies your subaddressing system, such as ``The AMS Subaddressing System.'' > Out of curiosity, which MTAs other than qmail support your flavor of > subaddressing? Do you mean using dash as a separator, or the more advanced features? Reportedly both sendmail and exim can be configured to handle dash. MMDF, the only popular MTA that has had this feature for a long time, appears to break addresses at "=", "/", or "|"; not configurable. On the MUA side, apparently mutt, elm, trn, slrn, nn, gnus, knews, and mh allow the user to configure arbitrary From addresses. (Of course, qmail can set the From even if the MUA doesn't.) > And I was surprised to find that Pine > supported the user-validation subaddressing feature. Which version? Where is this documented? Are you sure you haven't been surprised by a local hack? ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Sun Aug 3 20:58:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA16784 for ietf-822-bks; Sun, 3 Aug 1997 20:58:58 -0700 (PDT) Received: from mailhub.iag.net (www2.iag.net [204.27.210.7]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA16780 for ; Sun, 3 Aug 1997 20:58:54 -0700 (PDT) Received: from duh.org (root@like.duh.org [207.30.92.21]) by mailhub.iag.net (8.8.6/8.8.6) with ESMTP id BAA01468; Mon, 4 Aug 1997 01:12:25 -0400 (EDT) Received: from localhost ([[UNIX: localhost]]) by duh.org (8.8.6/8.8.6) with SMTP id AAA00649; Mon, 4 Aug 1997 00:02:43 -0400 (EDT) X-Authentication-Warning: like.duh.org: tv owned process doing -bs Date: Mon, 4 Aug 1997 00:02:42 -0400 (EDT) From: Todd Vierling X-Sender: tv@like.duh.org To: Chris Newman cc: ietf-822@imc.org Subject: Re: objections, again In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-822@imc.org Precedence: bulk On Sun, 3 Aug 1997, Chris Newman wrote: : > * Chris's delivered-to-owner default violates RFC 2119, section 6. : : The keywords are used to get interoperation between MUAs, final delivery : agents and mailing list servers with respect to subaddresses as : transmitted on the wire. Thus the proposal is entirely within IETF domain : and your complaint has no merit. Then let me clarify his point a little. Under RFC 2119, section 6, Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. I run a mail server that accepts mail for duh.org. YOU HAVE NO AUTHORITY to control how mail is handled once it enters my system, or the validity or equality of addresses before the @. THAT IS MY MTA'S CHOICE, not yours. B Not even a 'VRFY' or 'EXPN' SMTP command gives any kind of assurance on deliverability or identity of addressing. Only an actual attempt at mail delivery does. I don't use qmail. I'm using your run-of-the-mill Sendmail 8.8.7. I do use subaddressing on a minor basis. My mail transfer agent has sole authority about addressing mail in the @duh.org domain. I do interoperate quite well with every single SMTP compliant MTA out there, thankyouverymuch. SMTP says nothing about subaddressing, and the interoperability requirement above is already satisfied. You just don't have a ground to walk on by forcing us to standardize addresses before the @ sign. As long as we don't use a well-known metacharacter defined by RFC, we can put just about anything before the @ sign and expect it to remain untouched and unique. Defining a new metacharacter is not only sloppy at this point, but it should also only affect routing of mail *outside* the destination host/domain (see the use of % and !). In short, subaddresses DO NOT EXIST unless my MTA says they do (and only within the local delivery ability of my MTA). Outside my domain, you have no authority to tell me how to deliver mail addressed to the @duh.org domain. Anything to the contrary simply makes no sense. : > * Chris's MLM requirement creates a new security problem when a+b is : > subscribed to a mailing list and a+c is a different user. : : No. In that rare case, a subaddress-aware MLM would allow email with : addresses from "a" to manage "a+b" and "a+c"'s subscription. But this is : not a real security issue as anyone can generate email from "a", "a+b" or : "a+c" regardless. RFC 2015 provides real security. Therefore this cliam : has no merit. RFC 2015 provides real security via PGP et. al., sure. So how does validation of a sender's identity, based on e-mail addressing, have any _usability_ whatsoever? Therefore the _restriction_ of delivery/identity to a "primary user" has no merit. : Perhaps if you forwarded a user's statement to that effect we'd be more : inclined to listen and address the specifics of that complaint. I'm not a casual user (I have contributed source code and patchwork to several *BSD variants and Sendmail itself) but I don't write the core "stuff"; I primarily just use it all. So this was my statement. Oh, one off-hand note: I cannot recall which, but there is a MTA out there that separates first and last names of a person with a +. This package is not widely used, but it _is_ used by a couple Fortune 500s, and you'd probably infuriate many more unknowing users of that package and others by imposing some sort of authentication and identity mechanism on them that ruffles existing e-mail addresses. ===== == Todd Vierling (Personal tv@pobox.com; Alternate tv@duh.org) == I'm glad you like the Internet, Bobby. Now go eat your Frosted Flakes. From owner-ietf-822 Sun Aug 3 22:06:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA17122 for ietf-822-bks; Sun, 3 Aug 1997 22:06:33 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id WAA17118 for ; Sun, 3 Aug 1997 22:06:30 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01ILVP3JAP5C8WXGZ9@INNOSOFT.COM> for ietf-822@imc.org; Sun, 3 Aug 1997 22:09:39 PDT Date: Sun, 03 Aug 1997 21:36:08 -0700 (PDT) From: Ned Freed Subject: Re: objections, again In-reply-to: "Your message dated Mon, 04 Aug 1997 00:02:42 -0400 (EDT)" To: Todd Vierling Cc: Chris Newman , ietf-822@imc.org Message-id: <01IM0OLAEFO88WXGZ9@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: Sender: owner-ietf-822@imc.org Precedence: bulk > Under RFC 2119, section 6, > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > I run a mail server that accepts mail for duh.org. YOU HAVE NO AUTHORITY to > control how mail is handled once it enters my system, or the validity or > equality of addresses before the @. THAT IS MY MTA'S CHOICE, not yours. B > Not even a 'VRFY' or 'EXPN' SMTP command gives any kind of assurance on > deliverability or identity of addressing. Only an actual attempt at mail > delivery does. On the contrary, the IETF has had standards in place for a long time that impose mandatory requirements on the namespace to the left of the @. In fact not only is this done, one case where it is done is at full standard status. I'm referring, of course, to the mandate in RFC1123 that any host that supports a receiver-SMTP also support a mailbox called "postmaster". And there's also a requirement that "postmaster" be supported in a case-insensitive fashion (a pain to implement, BTW, and the source of at least one round of standards incompliancy in sendmail). And this isn't the only example of such a specification. There's also RFC2142, now a proposed standard, which mandates a wide variety of mailbox names for hosts offering various classes of service. Now, you use the term "authority" above. And in this sense you're absolutely right, the IETF doesn't have any authority to force you to comply with IETF standards. You are completely free to comply with none, some, or all IETF standards. You don't have to have a "postmaster" mailbox on your system (and in fact an unfortunately large number of systems don't), in which case you aren't in compliance with RFC1123. Or you can implement subaddressing in an entirely different way than what a standards-track specifaction says, in which case you woult not be in compliance with it. But all this means is that you are not in compliance. Nobody is going to arrest you for either action. You may get in trouble with someone somewhere because they expected you to conform to some set of IETF standards but you did not, of course. However, such contractural arrangements are outside the scope of the IETF. But this doesn't mean we cannot write standards that impose certain syntactic and semantic requirements on what appears to the left of the @ in an email address. We can. We have done so in the past and I'm sure we'll do so again in the future. In fact not only have we imposed such requirements in the past, we've done something worse -- we have in fact let prose slip into standards-track specifications that says certain mailbox name forms be interpreted in particular ways even when they appear in conjunction with a domain that isn't your own! This last is hard to believe I know, but you'll find that RFC1327 can be read this way. Note that RFC1327 will soon be replaced with MIXER, where I believe the problem to be corrected.) Please note that I'm not commenting on the subaddress proposal either pro or con. I'm only addressing the procedural issue of whether or not such a proposal is in scope for the IETF to produce. Ned From owner-ietf-822 Mon Aug 4 04:07:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id EAA21368 for ietf-822-bks; Mon, 4 Aug 1997 04:07:09 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id EAA21363 for ; Mon, 4 Aug 1997 04:07:06 -0700 (PDT) Received: (qmail 11582 invoked by uid 666); 4 Aug 1997 11:11:48 -0000 Date: 4 Aug 1997 11:11:48 -0000 Message-ID: <19970804111148.11581.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Innosoft interoperability Sender: owner-ietf-822@imc.org Precedence: bulk > What if I want to write an agent that > I can expect to interoperate with any of a large number of other MTAs and > LDAs or submission agents? Are you going to convince Netscape and MS and > Software.com and Innosoft Speaking of Innosoft... A user just asked whether the latest version of pine---presumably this is the famous Innosoft pine-with-subaddresses---works with PMDF 5.0-6. Here's Ned Freed's answer: ``The answer is no, it won't work. There are countless version dependencies thoughout -- we routinely change all sorts of interfaces and data structures during the development of new releases of the product.'' So Innosoft's MUA doesn't even work with two versions of their own MTA. Now, Bart, what were you saying about interoperability? ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Mon Aug 4 09:30:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA25087 for ietf-822-bks; Mon, 4 Aug 1997 09:30:49 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA25083 for ; Mon, 4 Aug 1997 09:30:45 -0700 (PDT) Received: from eleanor.innosoft.com ("port 53633"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IM1CH8HWQ08WXTMJ@INNOSOFT.COM> for ietf-822@imc.org; Mon, 4 Aug 1997 09:33:34 PDT Date: Mon, 04 Aug 1997 09:35:25 -0700 (PDT) From: Chris Newman Subject: Re: objections, again In-reply-to: To: Todd Vierling Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Mon, 4 Aug 1997, Todd Vierling wrote: > I run a mail server that accepts mail for duh.org. YOU HAVE NO AUTHORITY to > control how mail is handled once it enters my system, or the validity or > equality of addresses before the @. THAT IS MY MTA'S CHOICE, not yours. B > Not even a 'VRFY' or 'EXPN' SMTP command gives any kind of assurance on > deliverability or identity of addressing. Only an actual attempt at mail > delivery does. You are right that I have no authority to control how mail is routed at your site. Nor does the IETF. You can run any MTA you want which does whatever you want. The point of the spec I wrote is to standardize one subaddressing format which had been implemented by multiple vendors. If you want subaddressing to interoperate between your final delivery agent and MUA, then you can use this spec. Otherwise you can ignore it -- the intention is certainly not to require all Internet mail systems to do this. > I don't use qmail. I'm using your run-of-the-mill Sendmail 8.8.7. I do use > subaddressing on a minor basis. My mail transfer agent has sole authority > about addressing mail in the @duh.org domain. I do interoperate quite well > with every single SMTP compliant MTA out there, thankyouverymuch. SMTP says > nothing about subaddressing, and the interoperability requirement above is > already satisfied. But with a POP/IMAP client and a remote final delivery agent, there is no subaddressing interoperability. That's the point of this spec -- if you want subaddressing to interoperate between POP/IMAP and the final delivery agent, use this spec. Otherwise don't. > You just don't have a ground to walk on by forcing us to standardize > addresses before the @ sign. As long as we don't use a well-known > metacharacter defined by RFC, we can put just about anything before the @ > sign and expect it to remain untouched and unique. Defining a new > metacharacter is not only sloppy at this point, but it should also only > affect routing of mail *outside* the destination host/domain (see the use of > % and !). I strongly disagree. The left hand side is reserved only for routing *inside* the local domain. > In short, subaddresses DO NOT EXIST unless my MTA says they do (and only > within the local delivery ability of my MTA). Outside my domain, you have > no authority to tell me how to deliver mail addressed to the @duh.org > domain. Anything to the contrary simply makes no sense. Agreed. Did someone mislead you into thinking I was doing otherwise? > RFC 2015 provides real security via PGP et. al., sure. So how does > validation of a sender's identity, based on e-mail addressing, have any > _usability_ whatsoever? Therefore the _restriction_ of delivery/identity to > a "primary user" has no merit. In practice it does reduce the amount of spam even if it provides no security. The requirement in the draft prevents this spam control measure from interfering with legitimate subaddress users. > Oh, one off-hand note: I cannot recall which, but there is a MTA out there > that separates first and last names of a person with a +. This package is > not widely used, but it _is_ used by a couple Fortune 500s, and you'd > probably infuriate many more unknowing users of that package and others by > imposing some sort of authentication and identity mechanism on them that > ruffles existing e-mail addresses. Interesting case. But I'm not imposing anything on them, nor could I if I tried. - Chris From owner-ietf-822 Mon Aug 4 10:40:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA25651 for ietf-822-bks; Mon, 4 Aug 1997 10:40:42 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA25647 for ; Mon, 4 Aug 1997 10:40:38 -0700 (PDT) Received: from eleanor.innosoft.com ("port 53647"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IM1EYJEBB88WWQDA@INNOSOFT.COM> for ietf-822@imc.org; Mon, 4 Aug 1997 10:44:47 PDT Date: Mon, 04 Aug 1997 10:46:38 -0700 (PDT) From: Chris Newman Subject: Re: objections, again In-reply-to: <19970803225724.6450.qmail@koobera.math.uic.edu> To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Sun, 3 Aug 1997, D. J. Bernstein wrote: > > it can still be configured to handle them. > > Do these people have to change their e-mail addresses when they install > your ``compliant'' software? If they choose to use this variety of subaddressing, then they'd have to change those addresses or configure in a special MTA alias. > I'm still waiting for an answer to my question on this topic: Is it > widget-request or widget+request? If it is an administrative mailbox name for a mailing list "widget", then then RFC 2142 clearly requires that it be "widget-request". > How can ``MUST do X by default'' be required for interoperation? X isn't > even required! It's indistinguishable from ``MUST NOT do X by default'' > from an interoperability perspective. Other software can't rely on X and > can't rely on not-X. You're correct that X isn't required. But if X is part of service Y and saying "MUST do X by default" makes service Y work consistantly between implementations, then it is entirely reasonable. > When your MUA replies to > > From: "a,b+c"@d.e > > it will incorrectly pass "a,b+c"@d.e to the MTA. There is nothing incorrect about that. The address encoding used in SMTP is "a,b+c"@d.e for that address. Yes, the alternate encoding a\,b+c@d.e is also permitted but that's generally believed to be a mistake in the formal grammar and probably won't be permitted on generation in 821bis. The format a,b+c@d.e is NOT legal in SMTP. > The address is actually a,b+c@d.e. It can be _encoded_ as "a,b+c"@d.e > under RFC 821 and RFC 822, but the quotes are not part of the address. Agreed. So does all this have a point? > It's much better in practice for the MUA to avoid address parsing. The > MTA's submission agent can take care of it. The vast majority of MUAs submit via SMTP. Thus they have to parse addresses and generate valid SMTP encodings of the address. > > > * Chris's validation restriction is bizarre. > > This is not a technical complaint and thus has no merit. > > Amusing---your previous response to this criticism was ``good point.'' My previous response was to a statement to the effect that MUAs may wish to validate certain subaddresses. "bizarre" is not a technical point and does not belong in a technical discussion. > Let me rephrase. Your validation restriction has so many obviously wrong > effects that it can't possibly be what you meant. It is, like your many > unclear requirements, a result of bad writing; the fact that it's clear > is merely an accident. I asked to have the spec reviewed because I don't write perfect specs the first try. > I've seen a list that, before calling the MLM software, invokes PGP to > verify that the message is PGP-signed by the sender. The MLM then checks > the sender address against the subscription list. Subscribers have to be > preapproved (though there are some open sublists for lurkers). > > Your requirement destroys this security mechanism. An attacker takes an > approved ``joe@isp.net'' address and registers a ``joe+haha@isp.net'' > PGP key; PGP is satisfied; but an MLM following your rules has to ignore > the +haha when it's checking the address. This is an interesting scenario. The obvious thing to do is allow different posting/control and subscription addresses and associate the key with the posting/control address. The other option would be to disallow registration of PGP keys with subaddresses at the MLM. > Your denial of this security issue is despicable. Why does this make me think of Daffy Duck? > Inadequate. Your use of the term ``subaddressing'' is still deceptive. > Choose a phrase that accurately identifies your subaddressing system, > such as ``The AMS Subaddressing System.'' Linking the proposal to a single product when it is already in multiple products is deceptive. > > And I was surprised to find that Pine > > supported the user-validation subaddressing feature. > > Which version? Where is this documented? Are you sure you haven't been > surprised by a local hack? I double-checked and found I was incorrect on this point. Pine in IMAP/SMTP mode does no recipient address validation beyond address book lookup. It was simply relaying RCPT TO errors from the SMTP submit server. Pine has a compile-time option to allow the from address to be edited, although I had to create a personal version to use subaddresses in MAIL FROM. - Chris From owner-ietf-822 Mon Aug 4 13:47:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA27739 for ietf-822-bks; Mon, 4 Aug 1997 13:47:48 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA27735 for ; Mon, 4 Aug 1997 13:47:44 -0700 (PDT) Received: (qmail 16079 invoked by uid 666); 4 Aug 1997 20:52:28 -0000 Date: 4 Aug 1997 20:52:27 -0000 Message-ID: <19970804205227.16078.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: objections, again Sender: owner-ietf-822@imc.org Precedence: bulk Finally Chris admits some of his mistakes. Chris, I invite you to write an INFORMATIONAL document explaining how e-mail addresses are controlled in AMS. > If they choose to use this variety of subaddressing, then they'd have to > change those addresses or configure in a special MTA alias. In contrast, qmail _automatically_ handles existing accounts that contain the separator character. Why are you trying to standardize an inferior mechanism? > RFC 2142 clearly requires that it be "widget-request". Correct. Now, with your ``+'' as a separator, the widget account doesn't control this ``widget-request'' address, unless the sysadmin sets up one of your ``special MTA aliases.'' In contrast, with ``-'' as a separator, the widget account automatically controls ``widget-request'', so the user's favorite MLM can use ``widget-request'' without special sysadmin support. Why are you trying to standardize an inferior mechanism? > This is an interesting scenario. Do you deny that an MLM ``upgraded'' to support your requirements will cause this security mechanism to fail? > The address encoding used in SMTP is "a,b+c"@d.e for that address. What are you saying? All MUAs have to use SMTP? I'm talking about local UNIX MUAs that pass addresses to the submission agent on the command line---there are more than thirty programs in this category. If they follow your interface requirements, they produce incorrect results with MMDF and qmail for all quoted addresses. > Linking the proposal to a single product when it is already in multiple > products is deceptive. Not at all. Obviously one vendor can imitate another vendor's features. What's deceptive is your list of supporting products: * CMU (AMS, Cyrus) and Innosoft (PMDF) have paid you. * sendmail's support is pathetic---it doesn't allow user-controlled configuration by default. * Pine's support doesn't exist; it was your unverified speculation. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Mon Aug 4 15:32:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA28836 for ietf-822-bks; Mon, 4 Aug 1997 15:32:11 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA28832 for ; Mon, 4 Aug 1997 15:32:06 -0700 (PDT) Received: from eleanor.innosoft.com ("port 53867"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IM1P4HHUMQ8WWI8M@INNOSOFT.COM> for ietf-822@imc.org; Mon, 4 Aug 1997 15:35:54 PDT Date: Mon, 04 Aug 1997 15:37:45 -0700 (PDT) From: Chris Newman Subject: Re: Innosoft interoperability In-reply-to: <19970804111148.11581.qmail@koobera.math.uic.edu> To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk This is entirely inappropriate for this group, but I feel forced to respond in defense. Dan has taken a quote out of context and posted misleading information. I encourage readers to make their own evaluation of Dan's motivations and veracity in this matter. On Mon, 4 Aug 1997, D. J. Bernstein wrote: > Speaking of Innosoft... > > A user just asked whether the latest version of pine---presumably this > is the famous Innosoft pine-with-subaddresses---works with PMDF 5.0-6. > > Here's Ned Freed's answer: ``The answer is no, it won't work. There are > countless version dependencies thoughout -- we routinely change all > sorts of interfaces and data structures during the development of new > releases of the product.'' > > So Innosoft's MUA doesn't even work with two versions of their own MTA. Pine *is not* Innosoft's MUA. Pine is a product of the University of Washington. When appropriate Internet standards are used, any version of Pine on a client will interoperate with any version of PMDF on a separate server. Innosoft maintains a VMS port of Pine for our customers. This port uses the same shared libraries that the MTA uses and thus the versions have to be kept in sync when on the same host. This is the context for Ned's quote. - Chris From owner-ietf-822 Mon Aug 4 16:52:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA29456 for ietf-822-bks; Mon, 4 Aug 1997 16:52:36 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA29452 for ; Mon, 4 Aug 1997 16:52:32 -0700 (PDT) Received: (qmail 18256 invoked by uid 666); 4 Aug 1997 23:57:16 -0000 Date: 4 Aug 1997 23:57:16 -0000 Message-ID: <19970804235716.18255.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: Innosoft interoperability Sender: owner-ietf-822@imc.org Precedence: bulk > This is entirely inappropriate for this group, Then Bart shouldn't have brought it up. He's the one pretending that your naive subaddressing ``standard'' will settle the last internal interface design issue in Internet mailers and usher in a new age of MUA-MSA-MTA-MDA interchangeability. (And, oh yes, we'll all be using Windows 95.) In the real world, Innosoft's version of pine doesn't even work with two versions of Innosoft's MTA, because---by Ned Freed's own words---the Innosoft people ``routinely change all sorts of interfaces and data structures during the development of new releases of the product.'' > Dan has taken a quote out of context and posted misleading information. What did I say that was misleading? I clearly identified my correct presumption that the MUA was a modified version of pine: ``presumably this is the famous Innosoft pine-with-subaddresses.'' (You subsequently admitted that you were wrong about the ``subaddresses'' part.) > Pine *is not* Innosoft's MUA. Pay attention. All of us---the user, Ned Freed, me---are referring to the ``pine'' program supplied and maintained by Innosoft. The user asked whether Innosoft's latest pine program worked with Innosoft's PMDF 5.0-6 program. The answer is no. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Tue Aug 5 00:43:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA02762 for ietf-822-bks; Tue, 5 Aug 1997 00:43:50 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id AAA02758 for ; Tue, 5 Aug 1997 00:43:47 -0700 (PDT) Received: (qmail 22231 invoked by uid 666); 5 Aug 1997 07:48:32 -0000 Date: 5 Aug 1997 07:48:32 -0000 Message-ID: <19970805074832.22230.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: 50 people vs. newman Sender: owner-ietf-822@imc.org Precedence: bulk Yesterday I described the main features of Newman's proposal on the qmail mailing list, along with a pointer to the text. So far, 50 users and system administrators have sent me e-mail stating ``Newman's address system should not be standardized.'' Many of them added unsolicited comments on various details of Newman's proposal, including * testimonials to the active use of account names containing "+", which would no longer receive mail if the MTA were ``upgraded'' to follow Newman's requirements; * testimonials to the active use of "-" (and "=") on their machines by tens of thousands of people and dozens of mailing lists, all of which would be stranded by an MTA following Newman's requirements; * testimonials to the active use of PGP with MLMs for security--- security that would be destroyed if the MLMs were ``upgraded'' to follow Newman's requirements; * criticism of Newman's enable-subaddresses-by-default requirement as ignoring the desires of the average user; * criticism of Newman's ``security considerations'' as violations of local security policy; and * evaluations of the difficulty of switching existing subaddresses to "+" in software, existing mailing lists, and address books around the world. Other evaluations of Newman's proposal included ``pointless,'' ``silly,'' ``insane,'' ``unneeded,'' ``intrusive,'' ``terrible,'' ``go away,'' ``fundamentally flawed,'' ``we don't want it,'' and ``lock MTAs into often undesirable and even foolish behaviors.'' My impression is that many people, like me, would be interested in an Informational RFC giving an honest description of the AMS subaddressing system. A proposed ``standard,'' however, is completely unacceptable. Here are the fifty people: Ira Abramov, Russ Allbery, Kimmo Arola, Jos Backus, Brian Behlendorf, Joe Block, David Bruce, Nathan Bryant, Len Budney, Evan Champion, Frank D. Cringle, Bernard Courtney, Dave Deakin, Gert Doering, Frank Ederveen, Janos Farkas, Felix Morley Finch, Bert Gijsbers, Paul Gregg, Andi Gutmans, Dirk Harms-Merbitz, Stephen Hawley, Douglas Henke, Marco d'Itri, Antti-Juhani Kaijanaho, Dax Kelson, Martijn Koster, Mark Lillywhite, Patrick J. LoPresti, Toshinori Maeno, Raul D. Miller, John D. Mitchell, Baldur Norddahl, John Palkovic, Andrea Paolini, Stephen Parker, Greg Patterson, William E. Powers, Chris Rovers, Aharon Schkolnik, Matthew Schnierle, Scott Schwartz, Dave Sill, Steve Simitzis, Rick Smith, Ethan Torretta, David Wuertele, Vince Vielhaber, Tommi Virtanen, Ximenes Zalteca. I'm going to ask politely, for the last time, that Newman withdraw his proposal. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Tue Aug 5 06:15:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA07228 for ietf-822-bks; Tue, 5 Aug 1997 06:15:34 -0700 (PDT) Received: from aun.uninett.no (aun.uninett.no [129.241.1.99]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA07224 for ; Tue, 5 Aug 1997 06:15:29 -0700 (PDT) Received: from dale.uninett.no by aun.uninett.no with SMTP (PP); Tue, 5 Aug 1997 15:19:39 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id PAA05092; Tue, 5 Aug 1997 15:19:37 +0200 X-Mailer: exmh version 1.6.9 8/22/96 From: Harald.T.Alvestrand@uninett.no To: "D. J. Bernstein" cc: ietf-822@imc.org Subject: Re: 50 people vs. newman In-reply-to: Your message of "05 Aug 1997 07:48:32 -0000." <19970805074832.22230.qmail@koobera.math.uic.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Aug 1997 15:19:36 +0200 Message-ID: <5089.870787176@dale.uninett.no> Sender: owner-ietf-822@imc.org Precedence: bulk I can't tell what you are complaining about. The Newman proposal describes a *per site* mechanism, with no effect (that I can see) on systems apart from the ones that *choose* to adopt this mechanism. With some care, it can be used *per user*, with no effect on the other users of the same mailhost. The objections seem to have been based on the idea that an Internet standard is somehow *mandatory* for the *whole network*. The difference between a Standard and an Informational is whether it is something we recommend when people do this kind of thing or whether it's simply documenting an existing practice. For Elective standards, there is *NO* requirement that people do it. A MUST in a standard just says "if you claim to follow this standard, you MUST do this". Nothing else. Harald Tveit Alvestrand From owner-ietf-822 Tue Aug 5 07:36:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA08184 for ietf-822-bks; Tue, 5 Aug 1997 07:36:36 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA08180 for ; Tue, 5 Aug 1997 07:36:30 -0700 (PDT) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.7/8.8.7) with ESMTP id KAA34916 for ; Tue, 5 Aug 1997 10:40:39 -0400 Message-Id: <199708051440.KAA34916@black-ice.cc.vt.edu> To: ietf-822@imc.org Subject: Re: 50 people vs. newman In-Reply-To: Your message of "Tue, 05 Aug 1997 15:19:36 +0200." <5089.870787176@dale.uninett.no> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1092358604P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 05 Aug 1997 10:40:39 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_1092358604P Content-Type: text/plain; charset=us-ascii On Tue, 05 Aug 1997 15:19:36 +0200, Harald.T.Alvestrand@uninett.no said: > The Newman proposal describes a *per site* mechanism, with no effect > (that I can see) on systems apart from the ones that *choose* to > adopt this mechanism. > With some care, it can be used *per user*, with no effect on the > other users of the same mailhost. Alas Harald, it's not *quite* that simple. Now, I could support this draft as going out as an "Informational" describing "here's the way some sites do it". Unfortunately, as written, I think this would be a Bad Idea for even "Elective" status, much less 'MUST" status. The problem is that everything is too damned intertwined. For instance, let's say we have a mailing list A, and subscribers X, Y, and Z at seperate sites. Now, if the administrators at sites X and Y upgrade to this new scheme, *it doesn't really do any good* if site A is unaware. Site A treats the 'local part' as an opaque cookie to be dealt with by sites X and Y. As such, it's *not* permitted to look "inside" the opaque-cookie local-part and say "Oh, this is from zlortch@X, he's allowed to modify zlortch+biglist@X entries". Of course, being able to do this sort of parsing *was* the whole *point* of the proposal... So site A upgrades. And thus breaks size Z, which happens to use '+' (or whatever meta-char we picked) as a seperator for something ELSE. Remember, since it's elective, site Z can opt out. However, site A now has a dilemma - it has no way of knowing which sites are using the subaddressing scheme and which aren't. Anybody who says "Site A can just keep a list of which sites X Y Z are using which style" can go back and read up on why the DNS was invented. And don't propose an "Extended MX" - it's been proven that people can't get *REGULAR* MX configured right (how long has "compuserve.com" been pointing their MX at a CNAME? ;) Bottom line - I think this proposal is a non-starter unless it provides a way for a *remote* system (such as a MLM or what-have-you) to determine if the option is available or not. Yes, I know RFC1123 says 'you MUST support postmaster'. However, notice that the status of 1123 means that a remote system is allowed to use simple lexical operations to determine address validity for those reserved addresses. If they accept a connection on port 25, it has to be safe to mail to 'postmaster@'. However, there is no similar way for a remote host to verify whether it should consider 'fred', 'fred+warbot', 'fred+ghost' etc to be the "same" or not. As has been pointed out, this has a *large* impact on MLM systems, and on anything that wants to do cryptographic signatures. This message is PGP-signed. Would I have to add a new userid to my public key and re-send it to the keyservers each time I started using a new '+whatever' address? Remember - the answer to this is *NOT* PGP-specific... ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1092358604P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM+c7ZtQBOOoptg9JAQEpzQP+NLHuEfmlHSxFhOr+0oVvwvYk50NndSug S0iJkZlQ+/Xn48S27w8xHaOw8oNL06j4XditV9i0x3xrj0tzBSYHgAHWCD8N0n+T nWEpCQi0mAI8a/2gQWV0m3/PnnDMk+6i0CAxmN7pLf5+0zLTchdqEYrQKVyW4MUS 772eVzOGDR8= =bo5F -----END PGP MESSAGE----- --==_Exmh_1092358604P-- From owner-ietf-822 Tue Aug 5 09:14:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA09348 for ietf-822-bks; Tue, 5 Aug 1997 09:14:26 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA09344 for ; Tue, 5 Aug 1997 09:14:20 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id JAA26109 for ietf-822@imc.org; Tue, 5 Aug 1997 09:18:32 -0700 From: "Bart Schaefer" Message-Id: <970805091831.ZM26108@candle.brasslantern.com> Date: Tue, 5 Aug 1997 09:18:31 -0700 In-Reply-To: <19970805074832.22230.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "50 people vs. newman" (Aug 5, 7:48am) References: <19970805074832.22230.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: 50 people vs. newman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Aug 5, 7:48am, D. J. Bernstein wrote: } Subject: 50 people vs. newman } } Yesterday I described the main features of Newman's proposal on the } qmail mailing list, along with a pointer to the text. I've read your descriptions of other people's proposals before. Care to forward this instance to us? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Tue Aug 5 09:24:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA09462 for ietf-822-bks; Tue, 5 Aug 1997 09:24:50 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA09454 for ; Tue, 5 Aug 1997 09:24:46 -0700 (PDT) Received: from eleanor.innosoft.com ("port 54711"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IM2QLBFHKA8WWTGT@INNOSOFT.COM> for ietf-822@imc.org; Tue, 5 Aug 1997 09:28:30 PDT Date: Tue, 05 Aug 1997 09:30:22 -0700 (PDT) From: Chris Newman Subject: MLM subaddress requirement In-reply-to: <199708051440.KAA34916@black-ice.cc.vt.edu> To: Valdis.Kletnieks@vt.edu Cc: ietf-822@imc.org Message-id: Content-id: MIME-version: 1.0 Content-type: MULTIPART/SIGNED; BOUNDARY="-559023410-1804928587-870798622=:18309" Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1804928587-870798622=:18309 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: On Tue, 5 Aug 1997 Valdis.Kletnieks@vt.edu wrote: > 'fred', 'fred+warbot', 'fred+ghost' etc to be the "same" or not. As has > been pointed out, this has a *large* impact on MLM systems, and on anything > that wants to do cryptographic signatures. > > This message is PGP-signed. Would I have to add a new userid to my public > key and re-send it to the keyservers each time I started using a new '+whatever' > address? Remember - the answer to this is *NOT* PGP-specific... ;) Suppose I re-word the MLM rule as follows: --- A subaddress aware MLM MUST provide a way for a user to use his primary address with a subaddress for subscription and use just his primary address for posting. Some ways to meet this requirement include: (1) Having no restrictions on who can post to the list. (2) Permitting subscribers to register different posting and submission addresses. (3) Ignoring subaddresses for the purpose of permitting postings. --- This now directly dictates the interoperability issue rather than a particular solution to it (which is what I should have done in the first draft). There are plenty of ways to address this requirement without any significant impact on MLM systems or security validation. > Bottom line - I think this proposal is a non-starter unless it provides > a way for a *remote* system (such as a MLM or what-have-you) to > determine if the option is available or not. Do you still feel this is necessary if I make the above change? - Chris ---559023410-1804928587-870798622=:18309-- From owner-ietf-822 Tue Aug 5 09:38:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA09682 for ietf-822-bks; Tue, 5 Aug 1997 09:38:29 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA09675 for ; Tue, 5 Aug 1997 09:38:20 -0700 (PDT) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.7/8.8.7) with ESMTP id MAA15290 for ; Tue, 5 Aug 1997 12:42:37 -0400 Message-Id: <199708051642.MAA15290@black-ice.cc.vt.edu> To: ietf-822@imc.org Subject: Re: MLM subaddress requirement In-Reply-To: Your message of "Tue, 05 Aug 1997 09:30:22 PDT." From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1444093296P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 05 Aug 1997 12:42:37 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_1444093296P Content-Type: text/plain; charset=us-ascii On Tue, 05 Aug 1997 09:30:22 PDT, Chris Newman said: > A subaddress aware MLM MUST provide a way for a user to use his > primary address with a subaddress for subscription and use just his > primary address for posting. Some ways to meet this requirement include: > > (1) Having no restrictions on who can post to the list. Not Acceptable. > (2) Permitting subscribers to register different posting and submission > addresses. Pain in the ass. > (3) Ignoring subaddresses for the purpose of permitting postings. This doesn't work. Remember - the MLM *CAN NOT TELL* whether a piece of mail from 'a+b@somedom.com' is from a subaddress-aware site or if it's just from a site that has some OTHER meaning for '+'. As such, if you "ignore", and the list is closed, you just allowed 'a+c@somedom.com' to improperly post/subscribe/etc to the list. > This now directly dictates the interoperability issue rather than a > particular solution to it (which is what I should have done in the first > draft). There are plenty of ways to address this requirement without any > significant impact on MLM systems or security validation. No there aren't. See above. > > Bottom line - I think this proposal is a non-starter unless it provides > > a way for a *remote* system (such as a MLM or what-have-you) to > > determine if the option is available or not. > > Do you still feel this is necessary if I make the above change? Yes. If the remote system is unable to tell if an optional feature is in use, it *MUST* assume that the feature is *NOT* present. Blindly saying "This is SO $%(*^$% neat that I'll assume the world does it TOO" is just a good way to screw the users to the wall. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1444093296P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM+dX+9QBOOoptg9JAQF9LQP9HqpuiRYuTE06I57NCKmRUlzofR+xbEaY A1WwwV6yVkL7SQwtK463OiAEON7ZeYGf7V1I/mGVhOguogEvU9BQPApzcWD8W+5q lfKjqSDBhWfJwxWF8HXvfZ9vAGQmTc/YZ512z8oCrGQOwpEqT3Zmj5rOM/WUB8/T EreZ5k32iDk= =/MoE -----END PGP MESSAGE----- --==_Exmh_1444093296P-- From owner-ietf-822 Tue Aug 5 10:15:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA10160 for ietf-822-bks; Tue, 5 Aug 1997 10:15:57 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA10156 for ; Tue, 5 Aug 1997 10:15:53 -0700 (PDT) Received: from eleanor.innosoft.com ("port 54786"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IM2SD25ZJ48WXFE2@INNOSOFT.COM> for ietf-822@imc.org; Tue, 5 Aug 1997 10:19:07 PDT Date: Tue, 05 Aug 1997 10:20:58 -0700 (PDT) From: Chris Newman Subject: Re: MLM subaddress requirement In-reply-to: <199708051642.MAA15290@black-ice.cc.vt.edu> To: Valdis.Kletnieks@vt.edu Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Tue, 5 Aug 1997 Valdis.Kletnieks@vt.edu wrote: > > (3) Ignoring subaddresses for the purpose of permitting postings. > > This doesn't work. Remember - the MLM *CAN NOT TELL* whether a piece > of mail from 'a+b@somedom.com' is from a subaddress-aware site or if > it's just from a site that has some OTHER meaning for '+'. As such, > if you "ignore", and the list is closed, you just allowed 'a+c@somedom.com' > to improperly post/subscribe/etc to the list. What is the purpose of restricting postings based on the envelope address? It's obviously *not* a security issue as anyone can generate email from any address trivially (own a copy of Netscape?). I claim the primary purpose is to reduce spam. Permitting postings from user if user+foo is subscribed has no impact on this primary purpose. In the case of a signature verifying list, there has to be some way to register a PGP key to use with the list. The way to meet the interoperability requirement is simply to allow the address in the registered PGP key (used for posting & control) to be different from the subscription address. This is not particularly cumbersome or painful given the key has to be registered anyway. > Yes. If the remote system is unable to tell if an optional feature is in > use, it *MUST* assume that the feature is *NOT* present. Blindly saying > "This is SO $%(*^$% neat that I'll assume the world does it TOO" is just > a good way to screw the users to the wall. What negative impact does the loosened form of the requirement have? I've actually been thinking about a feature negotiation for email mechanism (e.g. a simple way to say "don't send me s/mime gunk or text/html but I like UTF-8"), but such a mechanism needs to be used sparingly and I just don't think subaddresses merit this level of complexity. The fact is, subaddresses _mostly_ work today. I had to switch a compile time option to allow editing of the from address in my MUA. Every final delivery agent I've used supports them. And only one mailing list I'm on currently (IETF-TLS) doesn't meet this revised MLM requirement from what I can tell. - Chris From owner-ietf-822 Tue Aug 5 12:27:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA11493 for ietf-822-bks; Tue, 5 Aug 1997 12:27:56 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA11488 for ; Tue, 5 Aug 1997 12:27:52 -0700 (PDT) Received: (qmail 28371 invoked by uid 666); 5 Aug 1997 19:32:40 -0000 Date: 5 Aug 1997 19:32:40 -0000 Message-ID: <19970805193240.28370.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: 50 people vs. newman Sender: owner-ietf-822@imc.org Precedence: bulk > I can't tell what you are complaining about. Newman's attempt to ``standardize'' Innosoft's inferior system. > The objections seem to have been based on the idea that an Internet > standard is somehow *mandatory* for the *whole network*. Eastlake admits that this is an attempt to put ``pressure on product vendors.'' It's pressure to adopt inferior technology. There are no legitimate interoperability concerns; this is a blatant attempt by one vendor to protect its dwindling market share by deceiving purchasers. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Tue Aug 5 13:23:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA11973 for ietf-822-bks; Tue, 5 Aug 1997 13:23:29 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA11969 for ; Tue, 5 Aug 1997 13:23:26 -0700 (PDT) Received: (qmail 28695 invoked by uid 666); 5 Aug 1997 20:28:14 -0000 Date: 5 Aug 1997 20:28:14 -0000 Message-ID: <19970805202814.28694.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: return-path security Sender: owner-ietf-822@imc.org Precedence: bulk Correcting an error; no discussion of subaddresses. > What is the purpose of restricting postings based on the envelope address? > It's obviously *not* a security issue as anyone can generate email from > any address trivially (own a copy of Netscape?). On the contrary. 1. The return path is a very convenient place to put cookies. With qmail, for example, a user can invoke ``cookie-check "$SENDER"'' before calling his usual mailing list manager. The mailing list hides the return path, so the cookie isn't broadcasted to the mailing list. Of course, it's available in mail logs, but logs aren't public on well-run hosts. It's available to sniffers, but in any case the number of possible attackers has been drastically reduced. This is one of the most effective low-cost security mechanisms. The main problem in practice is that, for many people, putting extra information into the return path is not as trivial as you claim. 2. Another research security application of return paths is aimed at the following problem: how do you protect subscribers from being flooded with mail when lists are cross-subscribed? Suppose every mailing list is subscribed to every other mailing list. What can the MLM do? One answer is to set up Auto-Submitted on every mailing list. But this is naive; it doesn't let people use sublists. What I've implemented in ezmlm is the following combination of techniques. Every mailing list sets the return path. Each sublist checks that the incoming return path matches its parent list. Primary mailing lists and MLMs generate Mailing-List fields, and reject messages with existing Mailing-List fields. Sublists demand Mailing-List fields. The result is that cross-subscriptions between ezmlm mailing lists are eliminated. A primary mailing list won't accept messages that have passed through any ezmlm mailing list, since all ezmlm mailing lists have Mailing-List on all outgoing messages. A sublist won't accept messages from any ezmlm mailing list other than its parent, since all ezmlm mailing lists set the return path. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Tue Aug 5 12:59:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA11718 for ietf-822-bks; Tue, 5 Aug 1997 12:59:03 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA11714 for ; Tue, 5 Aug 1997 12:58:59 -0700 (PDT) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.7/8.8.7) with ESMTP id QAA16636 for ; Tue, 5 Aug 1997 16:03:11 -0400 Message-Id: <199708052003.QAA16636@black-ice.cc.vt.edu> To: ietf-822@imc.org Subject: Re: MLM subaddress requirement In-Reply-To: Your message of "Tue, 05 Aug 1997 10:20:58 PDT." From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_739160646P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 05 Aug 1997 16:03:10 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_739160646P Content-Type: text/plain; charset=us-ascii On Tue, 05 Aug 1997 10:20:58 PDT, Chris Newman said: > What is the purpose of restricting postings based on the envelope address? > It's obviously *not* a security issue as anyone can generate email from > any address trivially (own a copy of Netscape?). I claim the primary > purpose is to reduce spam. Permitting postings from user if user+foo is > subscribed has no impact on this primary purpose. ARGH!!! How many times do I have to say this? *YOU* *DO* *NOT* *KNOW* if 'user' and 'user+foo' are in fact the same address or not. You cannot tell if the remote system sending the mail is or is not using your extension. This applies to *ALL* interactions with an MLM, not just posting. Subscribing, unsubscribing, requesting archive - which may be private and/or sensitive. I'll let *YOU* deal with the irate phone calls because one user got a corporate-sensitive archive he should not have been able to, just because his site did *NOT* use your subaddressing scheme and your MLM assumed it did. Until you explain how a MLM can *tell* that a given address is or is not using subadressing, you MAY NOT (rfc2119 sense) give a MLM any right to guess/assume/pull-out-of-its-rectum any decision based on the "fact" that an address that contains a '+' is in fact using subaddressing. Have I made this clear? YOU CANNOT REQUIRE OR EVEN SUGGEST THAT AN MLM DO ANYTHING WITH SUBADDRESSING UNLESS IT IS EITHER A 'MUST' STANDARD OR YOU HAVE A WAY OF TELLING ON THE FLY IF THE REMOTE SITE SUPPORTS IT. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_739160646P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM+eG/dQBOOoptg9JAQEMDwP+MzEvbaKL2HKgUArm5hL4umdDmeUoify5 2uzBB/F8NHf9xBwx32nTjTnRGHeELOuZOEYvXKT9dGLM5dOtXfvWi/GEyXr6Agr7 xyYm+fewUO3h8URp++na8AlknnJN4KcAIlQcGebMMON9mK3OpQYiOCYnwwJemHDO 425toumoJdw= =Rxpd -----END PGP MESSAGE----- --==_Exmh_739160646P-- From owner-ietf-822 Tue Aug 5 13:19:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA11936 for ietf-822-bks; Tue, 5 Aug 1997 13:19:31 -0700 (PDT) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA11931 for ; Tue, 5 Aug 1997 13:19:27 -0700 (PDT) Received: by callandor.cybercash.com; id QAA28541; Tue, 5 Aug 1997 16:11:51 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma028528; Tue, 5 Aug 97 16:11:41 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA01344; Tue, 5 Aug 97 16:17:34 EDT Date: Tue, 5 Aug 1997 16:17:33 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: ietf-822@imc.org Subject: Re: 50 people vs. newman In-Reply-To: <19970805193240.28370.qmail@koobera.math.uic.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-822@imc.org Precedence: bulk On 5 Aug 1997, D. J. Bernstein wrote: > Date: 5 Aug 1997 19:32:40 -0000 > From: D. J. Bernstein > To: ietf-822@imc.org > > > I can't tell what you are complaining about. > > Newman's attempt to ``standardize'' Innosoft's inferior system. Your blantant commercialism pushing your own product and bashing other's is inappropriate. I request that you withdraw your remark and appologize. > > The objections seem to have been based on the idea that an Internet > > standard is somehow *mandatory* for the *whole network*. > > Eastlake admits that this is an attempt to put ``pressure on product > vendors.'' I believe that virtually all standards are issued with the hope that products and services will conform to them and that their popularity will exert pressure on suppliers to incorporate them. This idea for standardization is no different in that regard than any other. > It's pressure to adopt inferior technology. There are no legitimate > interoperability concerns; this is a blatant attempt by one vendor to > protect its dwindling market share by deceiving purchasers. It would hardly seem surprising that that the first draft of a standard would be colored by the author's experience. However, I detect a willingness to learn and change the draft in the author. In you I see little but intrasigence and name calling. > ---Dan > Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-ietf-822 Tue Aug 5 14:29:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA12628 for ietf-822-bks; Tue, 5 Aug 1997 14:29:10 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA12620 for ; Tue, 5 Aug 1997 14:29:05 -0700 (PDT) Received: (qmail 29448 invoked by uid 666); 5 Aug 1997 21:33:42 -0000 Date: 5 Aug 1997 21:33:42 -0000 Message-ID: <19970805213342.29447.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: 50 people vs. newman Sender: owner-ietf-822@imc.org Precedence: bulk > Your blantant commercialism pushing your own product qmail is free software. I have no financial interest in it. You may have trouble with this concept, but some people do things for the good of the community, with no prospect of remuneration. > I request that you withdraw your remark and appologize. Are you denying that Newman's system is inferior? For example, do you claim that it handles existing usernames containing "+"? > In you I see little but intrasigence and name calling. Your entire contribution to this discussion has been a series of vague attacks---a transparent attempt to distract attention from the specific objections I have raised to Newman's proposal. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Tue Aug 5 14:31:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA12653 for ietf-822-bks; Tue, 5 Aug 1997 14:31:27 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA12649 for ; Tue, 5 Aug 1997 14:31:23 -0700 (PDT) Received: from eleanor.innosoft.com ("port 55360"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IM319RWZQC8Y4WTL@INNOSOFT.COM> for ietf-822@imc.org; Tue, 5 Aug 1997 14:34:34 PDT Date: Tue, 05 Aug 1997 14:36:24 -0700 (PDT) From: Chris Newman Subject: Re: return-path security In-reply-to: <19970805202814.28694.qmail@koobera.math.uic.edu> To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Tue, 5 Aug 1997, D. J. Bernstein wrote: > The mailing list hides the return path, so the cookie isn't broadcasted > to the mailing list. Of course, it's available in mail logs, but logs > aren't public on well-run hosts. It's available to sniffers, but in any > case the number of possible attackers has been drastically reduced. This > is one of the most effective low-cost security mechanisms. If the cookie is constant, this provides a mechanism with slightly worse security than plaintext password logins, which are discouraged by the IESG/IAB currently. If the cookie is something like an HMAC-SHA1 computed over a timestamp in the message and a secret, this is pretty cool but worthless without interoperability between the MUA and MLM (thus requiring a standard). > The main problem in practice is that, for many people, putting extra > information into the return path is not as trivial as you claim. Most modern MUAs have a text box in a preferences dialog to enter the return path/sender/default from. This does make it trivial to generate a single message with any given return path, but is too cumbersome to routinely change the return path. A subaddress standard would encourage MUA authors to allow subaddresses to be specified on a per-message basis or, even better, get the subaddress from the personal address book for list postings. So I conclude that a subaddress standard could make your technique more usable down the road. - Chris From owner-ietf-822 Tue Aug 5 14:59:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA12890 for ietf-822-bks; Tue, 5 Aug 1997 14:59:45 -0700 (PDT) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA12885 for ; Tue, 5 Aug 1997 14:59:41 -0700 (PDT) Received: by callandor.cybercash.com; id RAA06369; Tue, 5 Aug 1997 17:52:06 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma006338; Tue, 5 Aug 97 17:51:42 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA03693; Tue, 5 Aug 97 17:57:35 EDT Date: Tue, 5 Aug 1997 17:57:35 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: ietf-822@imc.org Subject: Re: MLM subaddress requirement In-Reply-To: <199708052003.QAA16636@black-ice.cc.vt.edu> Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/SIGNED; BOUNDARY="==_Exmh_739160646P"; MICALG=pgp-md5; PROTOCOL="application/pgp-signature" Content-Id: Sender: owner-ietf-822@imc.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --==_Exmh_739160646P Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: On Tue, 5 Aug 1997 Valdis.Kletnieks@vt.edu wrote: > Date: Tue, 05 Aug 1997 16:03:10 -0400 > From: Valdis.Kletnieks@vt.edu > > On Tue, 05 Aug 1997 10:20:58 PDT, Chris Newman said: > > What is the purpose of restricting postings based on the envelope address? > > It's obviously *not* a security issue as anyone can generate email from > > any address trivially (own a copy of Netscape?). I claim the primary > > purpose is to reduce spam. Permitting postings from user if user+foo is > > subscribed has no impact on this primary purpose. > > ARGH!!! > > How many times do I have to say this? > > *YOU* *DO* *NOT* *KNOW* if 'user' and 'user+foo' are in fact the same > address or not. You cannot tell if the remote system sending the mail is > or is not using your extension. When non-ASCII text was added to 822 headers, a syntactic convention was found which appears to have had no collision with any actually used ASCII text, even though in principle it could. It does not seem to me to be beyond human ken to come up with such a syntax in this case. It probably won't by "+" or "-" :-) Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html --==_Exmh_739160646P-- From owner-ietf-822 Wed Aug 6 00:44:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA17099 for ietf-822-bks; Wed, 6 Aug 1997 00:44:01 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id AAA17090 for ; Wed, 6 Aug 1997 00:43:55 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.5.1647.0) id ; Wed, 6 Aug 1997 00:48:21 -0700 Message-ID: <2FBF98FC7852CF11912A00000000000105ED95ED@DINO> From: "Kenzaburou Tamaru (Exchange)" To: ietf-822@imc.org Cc: Mark Crispin Subject: comment for draft-moore-mime-cdisp-00 Date: Tue, 5 Aug 1997 21:06:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1647.0) Content-Type: text/plain Sender: owner-ietf-822@imc.org Precedence: bulk Regarding the Filename parameter, none of Asia language is taken into consideration. As result, it is sort of nightmare in specially Japan. Many copmanies use different encoding scheme. This is because none of RFC does allow to use Asia character for file name as of today, it allows only US-ASCII. Since using double-byte character is very natual in Asia countries as file name. filename-paran := "filename" "=value" need to be more considered to be able to accomodate non-US-ASCII character for value field. MIME-2(Message Header Extensions for Non-ASCII) is defined as extension for header field., I don't think this can be applied to this "value". It is time to say like --------------------------------------------- disposition-param := filename-param /.............. filename-param := "filename" "=" dstring dstring := 1*utf8 utf8 := --------------------------------------------- Thank you, Kenzaburo Tamaru Exchange Program Manager. kenzat@microsoft.com From owner-ietf-822 Wed Aug 6 01:19:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA17406 for ietf-822-bks; Wed, 6 Aug 1997 01:19:49 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id BAA17402 for ; Wed, 6 Aug 1997 01:19:44 -0700 (PDT) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.7/8.8.7) with ESMTP id EAA23536; Wed, 6 Aug 1997 04:24:03 -0400 Message-Id: <199708060824.EAA23536@black-ice.cc.vt.edu> To: "Kenzaburou Tamaru (Exchange)" Cc: ietf-822@imc.org, Mark Crispin Subject: Re: comment for draft-moore-mime-cdisp-00 In-Reply-To: Your message of "Tue, 05 Aug 1997 21:06:19 PDT." <2FBF98FC7852CF11912A00000000000105ED95ED@DINO> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_919545674P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 06 Aug 1997 04:24:02 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_919545674P Content-Type: text/plain; charset=us-ascii On Tue, 05 Aug 1997 21:06:19 PDT, "Kenzaburou Tamaru (Exchange)" said: > field. MIME-2(Message Header Extensions for Non-ASCII) is defined as > extension for header field., I don't think this can be applied to this > "value". > It is time to say like > --------------------------------------------- > disposition-param := filename-param > /.............. > filename-param := "filename" "=" dstring > dstring := 1*utf8 > utf8 := a character from ISO 10646> > --------------------------------------------- No. The more correct answer here is to allow RFC2047 header-encoding to be used in the 'dstring' field. This way, other encoding systems besides UTF8 can be used if desired. Unfortunately, it's past 4AM local time and I can't remember why we didn't allow the 2047-style encoding in the first place. Somebody else here remember why we did that? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_919545674P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM+g0oNQBOOoptg9JAQGzDAQAtpZzKpINFOrrsAHgXSllkZJgUhauHGR/ +gdNDR0VcNcpQINMozvpuNzddI7mQybZDM0+HMtyPtwf4Za+qaWFsUSDtSLfimY/ +DbSx7RJqXofbSN4rld5eufuYOObiuZ+hnOWb/jgf96iRBbfE+Jntn+Nvxz4ya/7 uTeTEOsCAVU= =FwNk -----END PGP MESSAGE----- --==_Exmh_919545674P-- From owner-ietf-822 Wed Aug 6 04:11:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id EAA20426 for ietf-822-bks; Wed, 6 Aug 1997 04:11:23 -0700 (PDT) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id EAA20421 for ; Wed, 6 Aug 1997 04:11:13 -0700 (PDT) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id NAA28985 for ; Wed, 6 Aug 1997 13:15:16 +0200 (MET DST) Received: from emeriau.gctech.edelweb.fr (emeriau.gctech.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id NAA21532 for ; Wed, 6 Aug 1997 13:15:14 +0200 From: Peter Sylvester Received: (sylvest@localhost) by emeriau.gctech.edelweb.fr (8.6.10/8.6.6) id NAA05030 for ietf-822@imc.org; Wed, 6 Aug 1997 13:15:14 +0200 Date: Wed, 6 Aug 1997 13:15:14 +0200 Message-Id: <199708061115.NAA05030@emeriau.gctech.edelweb.fr> To: ietf-822@imc.org Subject: extensions to local parts of mail addresses Sender: owner-ietf-822@imc.org Precedence: bulk I wonder why nobody is coming up with the idea of a more generalized way of extending mail addresses: - It seems that for some purposes it is useful (on a global base) to associate additional information to an e-mail address. The example given is to add 'a subaddress'. - One might think about a general mechanism like for example: <"localpart;key=value;key=value"@domain> in order to associate different things to an address. - Examples: To: "someone;reply=desired;receipttype=yes/none/negative"e@foo - Of course this causes interoperability problems at several levels. (details left out as an exercise.) These need to be addressed, yes, that's part of the work to be done. Peter From owner-ietf-822 Wed Aug 6 08:38:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA23404 for ietf-822-bks; Wed, 6 Aug 1997 08:38:17 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA23400 for ; Wed, 6 Aug 1997 08:38:14 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01IM42Q58CDC94DNXY@INNOSOFT.COM> for ietf-822@imc.org; Wed, 6 Aug 1997 08:42:07 PDT Date: Wed, 06 Aug 1997 08:36:58 -0700 (PDT) From: Ned Freed Subject: Re: comment for draft-moore-mime-cdisp-00 In-reply-to: "Your message dated Wed, 06 Aug 1997 04:24:02 -0400" <199708060824.EAA23536@black-ice.cc.vt.edu> To: Valdis.Kletnieks@vt.edu Cc: "Kenzaburou Tamaru (Exchange)" , ietf-822@imc.org, Mark Crispin Message-id: <01IM4395EOU294DNXY@INNOSOFT.COM> MIME-version: 1.0 Content-type: multipart/signed; boundary="==_Exmh_919545674P"; micalg=pgp-md5; protocol="application/pgp-signature" References: <2FBF98FC7852CF11912A00000000000105ED95ED@DINO> <2FBF98FC7852CF11912A00000000000105ED95ED@DINO> Sender: owner-ietf-822@imc.org Precedence: bulk > The more correct answer here is to allow RFC2047 header-encoding to be used > in the 'dstring' field. This way, other encoding systems besides UTF8 > can be used if desired. Close but not quite. The main problem with using pure RFC2047 parameter values is that equals signs are involved, and the quoting that results gets really messy. Another problem is that we really don't want to allow more than one character set in a single value. So what we ended up with is a mechanism that reuses only parts of RFC2047. This works, and in fact works well. > Unfortunately, it's past 4AM local time and I can't remember why we didn't > allow the 2047-style encoding in the first place. Somebody else here > remember why we did that? Because we could never reach agreement on how, given a filename from a local system, to accurately map it into and out of a legal filename parameter value. Think about message/external-body, an FTP server that does localization based on client origin, and the name= parameter in this case, and you'll see what I'm talking about. It was only by avoiding this issue entirely that we were able to come up with an acceptable approach. Pity we didn't realize this five years ago, but there you are... Ned From owner-ietf-822 Wed Aug 6 08:33:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA23316 for ietf-822-bks; Wed, 6 Aug 1997 08:33:04 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA23308 for ; Wed, 6 Aug 1997 08:32:59 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01IM42Q58CDC94DNXY@INNOSOFT.COM> for ietf-822@imc.org; Wed, 6 Aug 1997 08:36:12 PDT Date: Wed, 06 Aug 1997 08:30:05 -0700 (PDT) From: Ned Freed Subject: Re: comment for draft-moore-mime-cdisp-00 In-reply-to: "Your message dated Tue, 05 Aug 1997 21:06:19 -0700" <2FBF98FC7852CF11912A00000000000105ED95ED@DINO> To: "Kenzaburou Tamaru (Exchange)" Cc: ietf-822@imc.org, Mark Crispin Message-id: <01IM431TIFBU94DNXY@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Sender: owner-ietf-822@imc.org Precedence: bulk > Regarding the Filename parameter, none of Asia language is taken into > consideration. This is simply not true. This draft specifically references the I-D draft-freed-pvcsc-03.txt, which was recently approved as a proposed standard. This draft provides a means by which any MIME content-type parameter or content-disposition parameter can be encoded, can have a character label, and can have a language label. As such, not only is it possible to have filenames containing Asian characters, the mechanism for doing so is already standardized. > As result, it is sort of nightmare in specially Japan. > Many copmanies use different encoding scheme. This is because none of > RFC does allow to use Asia character for file name as of today, it > allows only US-ASCII. The one thing the draft doesn't do is deal with the issue of what character sets to use when. And make no mistake about it -- this _is_ a nightmare. This is the reason we didn't define a mechanism when MIME was first developed. What we've done now is simply avoid this issue because were we to try and deal with it we'd never have reached any sort of consensus. > Since using double-byte character is very natual in Asia countries as > file name. filename-paran := "filename" "=value" need to be more > considered to be able to accomodate non-US-ASCII character for value > field. MIME-2(Message Header Extensions for Non-ASCII) is defined as > extension for header field., I don't think this can be applied to this > "value". This has already been. See the referenced draft. > It is time to say like > --------------------------------------------- > disposition-param := filename-param > /.............. > filename-param := "filename" "=" dstring > dstring := 1*utf8 > utf8 := a character from ISO 10646> > --------------------------------------------- This is unacceptable, as it would lead to 8bit characters in message headers. Message headers have to remain 7bit to be compatible with the installed base. But this is not a problem if the mechanisms we've defined are used. Ned From owner-ietf-822 Wed Aug 6 09:38:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA24186 for ietf-822-bks; Wed, 6 Aug 1997 09:38:01 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA24181 for ; Wed, 6 Aug 1997 09:37:52 -0700 (PDT) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.7/8.8.7) with ESMTP id MAA14924; Wed, 6 Aug 1997 12:41:37 -0400 Message-Id: <199708061641.MAA14924@black-ice.cc.vt.edu> To: Ned Freed Cc: "Kenzaburou Tamaru (Exchange)" , ietf-822@imc.org, Mark Crispin Subject: Re: comment for draft-moore-mime-cdisp-00 In-Reply-To: Your message of "Wed, 06 Aug 1997 08:36:58 PDT." <01IM4395EOU294DNXY@INNOSOFT.COM> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <2FBF98FC7852CF11912A00000000000105ED95ED@DINO> <01IM4395EOU294DNXY@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1761536784P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 06 Aug 1997 12:41:36 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_1761536784P Content-Type: text/plain; charset=us-ascii On Wed, 06 Aug 1997 08:36:58 PDT, Ned Freed said: > Because we could never reach agreement on how, given a filename from a local > system, to accurately map it into and out of a legal filename parameter value. > Think about message/external-body, an FTP server that does localization based > on client origin, and the name= parameter in this case, and you'll see what I'm > talking about. Hmm.. I remember that flame-fest..I just couldn't remember it at 4AM.. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1761536784P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM+ipP9QBOOoptg9JAQGPngP+NnA85WiORVp6MycmO0oVKx/k89m1W0M8 seTTiqY+8prckb9qHu33ta7hiKVCYqQyRTE/YkfgeqnCWbdlMDEnAx8s2xs5gKUt pbbLZA7F9y28QNrjxBuqOYXOfP4cgLn7GZn9iYUIjWC2+/Ig9/QO9Xy14NZWscRM mUNqjyNT31Q= =E2WC -----END PGP MESSAGE----- --==_Exmh_1761536784P-- From owner-ietf-822 Wed Aug 6 10:21:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA24779 for ietf-822-bks; Wed, 6 Aug 1997 10:21:41 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (imp@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA24767 for ; Wed, 6 Aug 1997 10:21:36 -0700 (PDT) Date: Wed, 6 Aug 1997 10:14:47 -0700 (PDT) From: Mark Crispin Subject: Re: comment for draft-moore-mime-cdisp-00 To: Ned Freed cc: "Kenzaburou Tamaru (Exchange)" , ietf-822@imc.org In-Reply-To: <01IM431TIFBU94DNXY@INNOSOFT.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-822@imc.org Precedence: bulk On Wed, 06 Aug 1997 08:30:05 -0700 (PDT), Ned Freed wrote: > I-D draft-freed-pvcsc-03.txt, which was recently approved as a proposed > standard. I just read it. The problem is that it uses character sets other than ASCII and Unicode. This is a serious burden, since it essentially requires that every application in the world maintain character set conversion tables. Actually, it's worse than that; it uses charsets which are even more disgusting than character sets. It is alright to encode 8 in 7. I have no problem with that part of it. The problem is the idea of expanding the broken idea of charsets to yet another place where it doesn't belong. Language is also good. The problem is only in the contination of charsets, which is against the recommendation in the first paragraph of section 8.2 of RFC 2130. From owner-ietf-822 Wed Aug 6 13:23:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA26725 for ietf-822-bks; Wed, 6 Aug 1997 13:23:57 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA26717 for ; Wed, 6 Aug 1997 13:23:49 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA25698; Wed, 6 Aug 1997 16:27:43 -0400 (EDT) Message-Id: <199708062027.QAA25698@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Valdis.Kletnieks@vt.edu cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: MLM subaddress requirement In-reply-to: Your message of "Tue, 05 Aug 1997 16:03:10 EDT." <199708052003.QAA16636@black-ice.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Aug 1997 16:27:41 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > Have I made this clear? YOU CANNOT REQUIRE OR EVEN SUGGEST THAT AN MLM > DO ANYTHING WITH SUBADDRESSING UNLESS IT IS EITHER A 'MUST' STANDARD OR > YOU HAVE A WAY OF TELLING ON THE FLY IF THE REMOTE SITE SUPPORTS IT. I strongly disagree. It's not reasonable to use *any* return-path or header that's visible, as a password to access sensitive information. (One could even imagine that the security considerations section of an RFC saying you MUST NOT use a Return-Path or From header as an authentication mechanism.) But if the list is potentially available to anyone just for signing up, comparing the return-path isn't really an authentication mechanism -- it's just a crude heuristic to filter out bogons. There's nothing wrong with refining that heuristic to allow posting from xxx@yyy.zzz if the subscriber address is xxx+foo@yyy.zzz. Keith From owner-ietf-822 Wed Aug 6 13:46:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA27006 for ietf-822-bks; Wed, 6 Aug 1997 13:46:08 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA27001 for ; Wed, 6 Aug 1997 13:46:04 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA26350; Wed, 6 Aug 1997 16:50:07 -0400 (EDT) Message-Id: <199708062050.QAA26350@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Kenzaburou Tamaru (Exchange)" cc: ietf-822@imc.org, Mark Crispin , moore@cs.utk.edu Subject: Re: comment for draft-moore-mime-cdisp-00 In-reply-to: Your message of "Tue, 05 Aug 1997 21:06:19 PDT." <2FBF98FC7852CF11912A00000000000105ED95ED@DINO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Aug 1997 16:50:06 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > Regarding the Filename parameter, none of Asia language is taken into > consideration. As result, it is sort of nightmare in specially Japan. > Many copmanies use different encoding scheme. This is because none of > RFC does allow to use Asia character for file name as of today, it > allows only US-ASCII. I believe this is solved with draft-moore-mime-cdisp-01.txt, which references draft-freed-pvcsc-03.txt. In particular, a content-disposition header could look like content-disposition: attachment; filename*=iso-2022-jp'xx'yyyyyyyy where xx is the ISO 639 language code for Japanese (sorry, I don't have a copy of ISO 639) and yyyyyyyy is Japenese text in iso-2022-jp charset encoded using URL-style "%XX" encoding for each octet. Unfortunately, the encoding is very inefficient. Each Japanese two-octet character will require six ASCII characters to encode (for example, ABCD hex gets encoded as "%AB%CD") Text in the UTF-8 charset would require even more encoding overhead using this method. So while it is possible to encode text in any language using this method, I could certainly understand if users of Asian languages would prefer a more efficient encoding for those languages. Keith From owner-ietf-822 Wed Aug 6 13:55:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA27090 for ietf-822-bks; Wed, 6 Aug 1997 13:55:36 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA27081 for ; Wed, 6 Aug 1997 13:55:31 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA26560; Wed, 6 Aug 1997 16:59:03 -0400 (EDT) Message-Id: <199708062059.QAA26560@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Crispin cc: Ned Freed , "Kenzaburou Tamaru (Exchange)" , ietf-822@imc.org, moore@cs.utk.edu Subject: Re: comment for draft-moore-mime-cdisp-00 In-reply-to: Your message of "Wed, 06 Aug 1997 10:14:47 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Aug 1997 16:59:02 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > I just read it. > > The problem is that it uses character sets other than ASCII and > Unicode. This is a serious burden, since it essentially requires > that every application in the world maintain character set > conversion tables. If this were a new application protocol, I'd agree with you. But this burden already exists for MIME mail readers, so by using existing MIME charsets we're not imposing an additional implementation burden beyond the need to parse the new parameter sytnax. At some point we might get consensus to deprecate the use of everything but Unicode in email. But I suspect it will be a long time before this happens. In the meantime, we'd only be increasing implementation complexity to have one standard for charsets in displayable text, and another standard for charsets in parameters. Besides, we'd never get consensus to impose such a restriction. > Actually, it's worse than that; it uses charsets > which are even more disgusting than character sets. The MIME notion of 'charset' was right (and is still right) for text-based mail which is intended for display. 'charset' is probably not right for the representation of filenames, but the differences are so subtle that trying to explain them to most people only increases the confusion. Keith From owner-ietf-822 Thu Aug 7 06:10:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA08643 for ietf-822-bks; Thu, 7 Aug 1997 06:10:18 -0700 (PDT) Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA08639 for ; Thu, 7 Aug 1997 06:10:12 -0700 (PDT) Received: from white-box.jck.com ("port 2039"@[206.99.215.34]) by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0EEJOSAF500JY3@a4.jck.com> for ietf-822@imc.org; Thu, 7 Aug 1997 09:14:34 -0400 (EDT) Date: Thu, 07 Aug 1997 09:14:33 -0400 (EDT) From: John C Klensin Subject: Re: MLM subaddress requirement In-reply-to: <199708062027.QAA25698@spot.cs.utk.edu> To: Keith Moore Cc: ietf-822@imc.org, moore@cs.utk.edu, Valdis.Kletnieks@vt.edu Reply-to: John C Klensin Message-id: MIME-version: 1.0 X-Mailer: Simeon for Windows Version 4.1.1b2 Build (6) Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Authentication: none Sender: owner-ietf-822@imc.org Precedence: bulk On Wed, 06 Aug 1997 16:27:41 -0400 Keith Moore wrote: >... > But if the list is potentially available to anyone just for signing > up, comparing the return-path isn't really an authentication mechanism > -- it's just a crude heuristic to filter out bogons. > > There's nothing wrong with refining that heuristic to allow posting > from xxx@yyy.zzz if the subscriber address is xxx+foo@yyy.zzz. Keith, This, with which I agree, brings us back to a note I sent Chris some weeks ago that suggested that some of the issue being addressed was "too little, too late". While I found his response was reasonable, the "what is the list manager to do" question brings me full circle. If I can have subscribe foo-list [my-address] (i.e., get a slightly funny address in there without messing with the From field) then the author of an automated list manager can presumably extend that to subscribe foo-list [outbound-address] [inbound-address] or subscribe foo-list [outbound-address] [subaddress-indicator-and-delimiter] The posting/acceptance engine has to understand either the rule or a pair of lists in any case, so getting this from the user, especially if we start automating the subscription process, is just not a big deal. And this model would permit someone to use "-", someone else to use "+", a third party to use "=" and, modulo some understanding about what to do if more than one such symbol is encountered (an area where a recommendation would be very useful in avoiding user astonishment), and the rest of us to get on with our lives. My local MUA and MTA would probably need to be told too, but that is presumably a local problem -- they probably know what they are willing to treat as a subaddress. There are, of course, authentication problems in any of these cases. But they aren't much different by case, and the cheap heuristics, as you point out, don't accomplish much or provide much protection against anything but a casual slip-up. While I wish we could do something sensible about subaddresses, our experience has been that every attempt to relax the rule that nothing but the destination host is permitted to interpret or mess with the local-part leads to a "gotcha" somewhere. I fear the discussion of the last week or so is evidence that we now have another example. Recommendation: (i) We progress a revised version of Chris's note as a guideline and recommendation, not a standard. You and IESG figure out how to do that: vote-counting among captive audiences is silly, since this is one of those "what you already know is better" situations. (ii) We try to get a strong "security considerations" statement into the revision that discusses the interplay between subaddressing mechanisms and various security UI models. (iii) We keep it from saying anything that will violate the "don't mess with the local-part" rule. (iv) We create a separate document, or a clearly-deliniated piece of Chris's document, addressed to authors of automated intermediary systems (e.g., list exploders and semi-automatic list maintainer software). It should start from the premiss that people _will_ use these things and thus give advice about the facilities such systems might sensibly use to minimize trouble and effort. Does that make sense and, if so, do we have volunteers to do some calm writing (as distinct from more flaming, misquotation and misinterpretation, etc.)? If we believe that this is important and useful enough to justify the recent traffic level, then Chris shouldn't have to do all of the writing (although it is fine with me if he wants to sign up). john From owner-ietf-822 Thu Aug 7 11:21:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA13975 for ietf-822-bks; Thu, 7 Aug 1997 11:21:29 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA13965 for ; Thu, 7 Aug 1997 11:21:25 -0700 (PDT) Received: (qmail 18385 invoked by uid 666); 7 Aug 1997 18:26:20 -0000 Date: 7 Aug 1997 18:26:20 -0000 Message-ID: <19970807182620.18384.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: MLM subaddress requirement Sender: owner-ietf-822@imc.org Precedence: bulk > It's not reasonable to use *any* return-path or header that's visible, > as a password to access sensitive information. People protect this mechanism with strong authentication---e.g., PGP. > There's nothing wrong with refining that heuristic to allow posting > from xxx@yyy.zzz if the subscriber address is xxx+foo@yyy.zzz. It breaks existing PGP-protected mailing lists, turning good security into nonexistent security. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Thu Aug 7 12:39:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA23440 for ietf-822-bks; Thu, 7 Aug 1997 12:39:57 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA23422 for ; Thu, 7 Aug 1997 12:39:49 -0700 (PDT) Received: (qmail 20379 invoked by uid 666); 7 Aug 1997 19:44:45 -0000 Date: 7 Aug 1997 19:44:45 -0000 Message-ID: <19970807194445.20378.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: failure to address objections Sender: owner-ietf-822@imc.org Precedence: bulk > "what you already know is better" qmail _is_ better. For example, qmail automatically handles existing usernames containing the separator character. Newman's proposal doesn't. This is not a minor issue. This is a fundamental flaw in Newman's proposal. His insistence on a global syntax means that he cannot handle existing usernames correctly. As another example, qmail's default separator, "-", automatically gives ``project'' control over MLM addresses such as ``project-request''. Newman's proposal doesn't. Newman hasn't shown any willingness to address these objections--- because addressing them would mean throwing his proposal away. He just ignores them. That's dishonest. Similarly, you're pretending that qmail's superiority is merely a matter of ``what you already know.'' But it's not. Users really do complain when their mail doesn't get delivered. > a guideline and recommendation, Please try to act like an engineer who actually cares about engineering failures. Why are you recommending Innosoft's inferior technology? ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Thu Aug 7 14:59:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA10912 for ietf-822-bks; Thu, 7 Aug 1997 14:59:36 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA10900 for ; Thu, 7 Aug 1997 14:59:32 -0700 (PDT) Received: from eleanor.innosoft.com ("port 56299"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IM5UVMHQ9894DT0X@INNOSOFT.COM> for ietf-822@imc.org; Thu, 7 Aug 1997 15:03:44 PDT Date: Thu, 07 Aug 1997 15:05:35 -0700 (PDT) From: Chris Newman Subject: Re: failure to address objections In-reply-to: <19970807194445.20378.qmail@koobera.math.uic.edu> To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Thu, 7 Aug 1997, D. J. Bernstein wrote: > For example, qmail automatically handles existing usernames containing > the separator character. Newman's proposal doesn't. > > This is not a minor issue. This is a fundamental flaw in Newman's > proposal. His insistence on a global syntax means that he cannot handle > existing usernames correctly. For the MLM rules this is a non-issue. It is an issue for the final delivery agent if there are legacy usernames on the system. The latter case will be addressed. > As another example, qmail's default separator, "-", automatically gives > ``project'' control over MLM addresses such as ``project-request''. > Newman's proposal doesn't. The character "-" is used as a non-hiearachy separator much more commonly than "+" is so used. In fact one of the more popular email address conventions conflicts with your use of "-" due to dashed last names. And just to make myself clear, I'd be willing to agree to change to "=" as the default. My objection is solely a technical objection to "-". > Newman hasn't shown any willingness to address these objections--- > because addressing them would mean throwing his proposal away. He just > ignores them. That's dishonest. This statement is false. I have attempted to respond to every one of your technical objections. This is very difficult to do as it is hard to separate the technical content of your messages from the self-promotion, insults, attacks and empty rhetoric. > Why are you recommending Innosoft's inferior technology? Your public attacks on my employeer are misleading, tiresome, pointless and very obnoxious. If you want me to listen to your technical comments, stop attacking my employeer and myself publicly. I will not respond to this sort of blather again. - Chris Newman From owner-ietf-822 Thu Aug 7 16:51:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA19294 for ietf-822-bks; Thu, 7 Aug 1997 16:51:05 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA19290 for ; Thu, 7 Aug 1997 16:51:02 -0700 (PDT) Received: (qmail 23883 invoked by uid 666); 7 Aug 1997 23:55:58 -0000 Date: 7 Aug 1997 23:55:58 -0000 Message-ID: <19970807235558.23882.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: failure to address objections Sender: owner-ietf-822@imc.org Precedence: bulk [ existing addresses, not subaddresses, containing "+" ] > For the MLM rules this is a non-issue. False. Your MLM rules impose a global syntax and global semantics. Whenever one of your ``subaddress aware'' MLMs accepts bob+ruth@absolutely.anywhere, it is also required to accept bob+liz. This global scheme is incompatible with existing addresses. Your MLM requirement is a security violation. > I have attempted to respond to every one of your technical objections. Mm-hm. Where exactly is your response to the widget-request problem? Just to refresh your memory: There's a group project account called widget. ``widget'' is also the mailing list for that project, run by some MLM. Most separators are incompatible with the de facto ``-request'' standard. If "+" is the separator, for example, the widget people will end up pestering the sysadmin for a special ``widget-request'' alias. With "-" as the subaddress separator, the widget account automatically controls ``widget-request'', as well as ``widget-owner'' and ``widget-subscribe'' and whatever other addresses the MLM might support. This is clearly superior. Getting you to admit that the right address is ``widget-request'' and not ``widget+request'' was like pulling teeth; I had to ask three times. Apparently you don't want to admit any benefits of "-". You've spent far more time claiming, incorrectly, that "-" doesn't work. > In fact one of the more popular email address > conventions conflicts with your use of "-" due to > dashed last names. False. Many qmail sysadmins use this convention. There is no conflict. For example, if there are jean and jean-pierre.serre accounts, the jean-pierre.serre account controls jean-pierre.serre-books-request. (UNIX traditionally doesn't support such long account names, but qmail supports a translation table: e.g., jps:jean-pierre.serre.) Similarly, if + is the separator, and there are smith and smith+co accounts, the address smith+co+help is controlled by smith+co. Next strawman? ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Fri Aug 8 09:43:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA27807 for ietf-822-bks; Fri, 8 Aug 1997 09:43:06 -0700 (PDT) Received: from lust.cs.utk.edu (Z.CS.UTK.EDU [128.169.92.74]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA27803 for ; Fri, 8 Aug 1997 09:43:02 -0700 (PDT) Received: from cs.utk.edu by lust.cs.utk.edu with ESMTP (cf v2.11c-UTK) id MAA01668; Fri, 8 Aug 1997 12:41:00 -0400 (EDT) Message-Id: <199708081641.MAA01668@lust.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ To: ietf-822@imc.org Subject: please don't feed the Dan cc: moore@cs.utk.edu From: Keith Moore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Aug 1997 12:40:59 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk As usual, Dan Bernstein has managed to take a civil, technical discussion and turn it into a sewer -- with insults, inappropriate accusations, and misattributions. Dan is right some of the time, and occasionally he even manages to produce a cogent and convincing argument. So it's sometimes worthwhile to read his opinion on a subject. But I've never seen an occasion where responding to a message from Dan yielded anything useful. Either you agree with him, in which case he'll use it against you later, or you disagree with him, in which case he'll respond with insults. The result of replying to Dan is nearly always to polarize the discussion -- to change it from a discussion aimed at honing technical details or fine tuning language, to a discussion about whether Dan is right or wrong. While such a discussion might be entertaining to those involved, it's certainly not going to produce anything useful. So please - don't feed the Dan. Read his messages if you want to, but resist the temptation to respond. If you do respond, consider responding directly to the list, rather than replying to Dan with a cc to the list. Address the topic of discussion in your own language, with a new Subject header, rather than responding to his diatribes on a point-by-point basis. This will make it possible for the other list members to see the variation in opinion, rather than how strongly people agree or disagree with Dan. Keith From owner-ietf-822 Fri Aug 8 11:29:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA28797 for ietf-822-bks; Fri, 8 Aug 1997 11:29:13 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA28793 for ; Fri, 8 Aug 1997 11:29:09 -0700 (PDT) Received: (qmail 3502 invoked by uid 666); 8 Aug 1997 18:34:08 -0000 Date: 8 Aug 1997 18:34:08 -0000 Message-ID: <19970808183408.3501.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: watch Moore squirm Sender: owner-ietf-822@imc.org Precedence: bulk It's always rather amusing to watch Keith Moore trying to defend the standardization of inferior technology. > with insults, inappropriate accusations, and misattributions. Hmmm. Are you saying that you prefer ``Newman's inferior technology'' to ``Innosoft's inferior technology''? > to change it from a discussion aimed at honing technical details Unlike some people here, I never use general complaints as an excuse to ignore specific engineering issues. > Address the topic of discussion in your own language, > with a new Subject header, rather than responding to his diatribes on a > point-by-point basis. Translation: ``Please don't discuss the specific costs and benefits of Newman's proposal. The IESG knows what is Right For The Internet, damn it, and if we decide that we have to standardize an inferior proposal, we don't want people to talk about how incompetent we were.'' ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Fri Aug 8 12:14:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA29061 for ietf-822-bks; Fri, 8 Aug 1997 12:14:35 -0700 (PDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA29056 for ; Fri, 8 Aug 1997 12:14:30 -0700 (PDT) Received: (from uucp@localhost) by uucp1.nwnexus.com (8.8.5/8.8.5) with UUCP id MAA22018 for ietf-822@imc.org; Fri, 8 Aug 1997 12:18:59 -0700 (PDT) Received: from zircon.seattle.wa.us by jhgrud.mselectron.com with bsmtp (Smail3.1.29.1 #6) id m0wwuUv-0008XMC; Fri, 8 Aug 97 12:14 PDT Received: by zircon.seattle.wa.us via sendmail with stdio id for ietf-822@imc.org; Fri, 8 Aug 1997 11:59:13 -0700 (PDT) (Smail-3.2 1996-Jul-4 #7 built 1996-Aug-7) Message-Id: Date: Fri, 8 Aug 1997 11:59:13 -0700 (PDT) From: Joe Kelsey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-822@imc.org Subject: please don't feed the Dan In-Reply-To: <199708081641.MAA01668@lust.cs.utk.edu> References: <199708081641.MAA01668@lust.cs.utk.edu> X-Mailer: VM 6.30 under Emacs 19.34.1 Sender: owner-ietf-822@imc.org Precedence: bulk I have to say that I completely disagree with Keith on this issue. Dan has the most cogent, well-thought out sense of a problem of anyone I have ever encountered on the net. He has the ability to see through all of the vagueness and unclear thinking that most users use when posting messages and boil things down the the basics very quickly. In this case he has correctly analyzed the broken proposal of Newman as being an attempt to make the CMU/Innosoft subaddress scheme a global requirement simply for the perceived benefit of one administrator who doesn't want to support what user's really want to do. I have never seen an issue where I disagreed with Dan. He does tend to assume that everyone can use the same completely logical thought processes to arrive at his conclusions, so sometimes it takes people a little longer to understand his positions. Or, sometimes people refuse to take the time to think an issue through and so they never understand his conclusions, in which case a flame war erupts. However, the original source of the flames is always someone who through prejudice or inability to use logic cannot understand his original position. /Joe From owner-ietf-822 Fri Aug 8 13:59:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA29864 for ietf-822-bks; Fri, 8 Aug 1997 13:59:58 -0700 (PDT) Received: from amex.cox.smu.edu (root@mail.cox.smu.edu [129.119.80.101]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA29858 for ; Fri, 8 Aug 1997 13:59:52 -0700 (PDT) Received: from p1.cox.smu.edu (p1.cox.smu.edu [129.119.81.10]) by amex.cox.smu.edu (8.6.12/8.6.9) with SMTP id QAA30028; Fri, 8 Aug 1997 16:04:17 -0500 Date: Fri, 8 Aug 1997 16:07:00 -0500 () From: Allen Gwinn To: Keith Moore cc: ietf-822@imc.org Subject: Re: please don't feed the Dan In-Reply-To: <199708081641.MAA01668@lust.cs.utk.edu> Message-ID: X-X-Sender: allen@mail.cox.smu.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-822@imc.org Precedence: bulk Well, I haven't posted in a long time, so, here goes! First off, I disagree with you, Keith. Dan usually has a very good technical sense about him. The only thing, perhaps, that I could side with you on is the alt.flamisms. Although I don't post alot, I feel that his rationale and arguments wrt subaddressing and this whole line has been well thought out. Perhaps if everybody stuck to the issues and spent a little less time flaming -- but on the other hand addressing the concerns of the other parties (rather than toting their own party line) we'd actually do things that benefitted the 'Net, eh? Cheers! Allen On Fri, 8 Aug 1997, Keith Moore wrote: > As usual, Dan Bernstein has managed to take a civil, technical discussion and > turn > it into a sewer -- with insults, inappropriate accusations, and > misattributions. > > Dan is right some of the time, and occasionally he even manages to produce a > cogent and convincing argument. So it's sometimes worthwhile to read his > opinion > on a subject. > > But I've never seen an occasion where responding to a message from Dan yielded > anything useful. Either you agree with him, in which case he'll use it against > you later, or you disagree with him, in which case he'll respond with insults. > > The result of replying to Dan is nearly always to polarize the discussion -- > to change it from a discussion aimed at honing technical details or fine tuning > language, to a discussion about whether Dan is right or wrong. > > While such a discussion might be entertaining to those involved, it's certainly > not going to produce anything useful. > > So please - don't feed the Dan. > > Read his messages if you want to, but resist the temptation to respond. If > you > do respond, consider responding directly to the list, rather than replying to > Dan > with a cc to the list. Address the topic of discussion in your own language, > with a new Subject header, rather than responding to his diatribes on a > point-by-point basis. > > This will make it possible for the other list members to see the variation in > opinion, rather than how strongly people agree or disagree with Dan. > > Keith > > > From owner-ietf-822 Fri Aug 8 17:03:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA01335 for ietf-822-bks; Fri, 8 Aug 1997 17:03:05 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA01331 for ; Fri, 8 Aug 1997 17:03:01 -0700 (PDT) Received: from eleanor.innosoft.com ("port 56692"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-9 #8694) with SMTP id <01IM7DGDXQNO94DX8P@INNOSOFT.COM> for ietf-822@imc.org; Fri, 8 Aug 1997 17:06:39 PDT Date: Fri, 08 Aug 1997 17:08:30 -0700 (PDT) From: Chris Newman Subject: Re: please don't feed the Dan In-reply-to: To: Joe Kelsey Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Fri, 8 Aug 1997, Joe Kelsey wrote: > In this case he has correctly analyzed the broken proposal of Newman as > being an attempt to make the CMU/Innosoft subaddress scheme a global > requirement simply for the perceived benefit of one administrator who > doesn't want to support what user's really want to do. Guessing other people's motives is always a dubious venture, and both Dan and you have guessed incorrectly. My motives are as follows: (1) I like subaddressing and think others would like it as well. (2) Quality MUA interfaces for subaddressing can't be built without a standard since it requires cooperation between MUA and the final delivery agent (which usually are on different hosts). (3) Certain spam-limitation efforts on MLMs make the use of subaddresses for subscriptions a real pain. (4) I like to write standards for the benefit of the community. I also noted that this would benefit my employeer, but that has more impact on my personal vs. work time allocation then anything else. This is a personal proposal -- not an Innosoft or CMU proposal. So I wrote a _first rough draft_ of a standard based on personal experience with the intent to address (1)-(3). I brought the rough draft forward for public comment so it can be refined to a level suitable for standardization, if possible. The result is that I've learned a lot more about how people use subaddresses and will make substantial revisions in the next draft. Now can we please end the confrontational garbage and stick with technical issues? - Chris From owner-ietf-822 Fri Aug 8 19:45:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA02089 for ietf-822-bks; Fri, 8 Aug 1997 19:45:58 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA02080 for ; Fri, 8 Aug 1997 19:45:52 -0700 (PDT) From: Masataka Ohta Message-Id: <199708090245.LAA01056@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA01056; Sat, 9 Aug 1997 11:45:12 +0900 Subject: please don't feed the Keith To: moore@cs.utk.edu (Keith Moore) Date: Sat, 9 Aug 97 11:45:10 JST Cc: ietf-822@imc.org, moore@cs.utk.edu In-Reply-To: <199708081641.MAA01668@lust.cs.utk.edu>; from "Keith Moore" at Aug 8, 97 12:40 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ietf-822@imc.org Precedence: bulk Keith; > As usual, Dan Bernstein has managed to take a civil, technical discussion and > turn > it into a sewer -- with insults, inappropriate accusations, and > misattributions. Keith, it's your usual behaviour. Masataka Ohta From owner-ietf-822 Sat Aug 9 23:06:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA13146 for ietf-822-bks; Sat, 9 Aug 1997 23:06:35 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id XAA13142 for ; Sat, 9 Aug 1997 23:06:31 -0700 (PDT) Received: (qmail 24150 invoked by uid 666); 10 Aug 1997 06:09:48 -0000 Date: 10 Aug 1997 06:09:48 -0000 Message-ID: <19970810060948.24149.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: rfc 2119 violation Sender: owner-ietf-822@imc.org Precedence: bulk I asked Scott Bradner, the author of RFC 2119, about Newman's ``MUST be delivered to that primary address by default'' requirement. Scott wrote back after reviewing Newman's spec. ``In looking at the text I think you are correct in detail---i.e. this is not a case of ensuring interoperability between systems so it does violate the caution in rfc 2119,'' he says. ``It seems like the author is trying to ensure consistent user-level behavior, a reasonable goal, but the use of MUST seems out of place.'' ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html From owner-ietf-822 Mon Oct 6 13:36:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA16280 for ietf-822-bks; Mon, 6 Oct 1997 13:36:11 -0700 (PDT) Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA16276 for ; Mon, 6 Oct 1997 13:36:08 -0700 (PDT) Received: from mailsun3 (mailsun3-fddi.us.oracle.com [144.25.88.135]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id NAA02111 for ; Mon, 6 Oct 1997 13:38:27 -0700 (PDT) Received: from gocampo-pc by mailsun3 with SMTP (SMI-8.6/37.9) id NAA22675; Mon, 6 Oct 1997 13:35:45 -0700 Message-Id: <199710062035.NAA22675@mailsun3> From: Gerardo Ocampo To: ietf-822@imc.org CC: gocampo@us.oracle.com Reply-To: gocampo@us.oracle.com Organization: Oracle Corporation Subject: redirected mail Date: Mon, 06 Oct 1997 13:32:51 -0700 X-Mailer: Oracle InterOffice 1.0.1.2.20/Java on Windows NT X-Orcl-Priority: Normal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary_cnUCthisp=_urMUAsuxeafc09490" Sender: owner-ietf-822@imc.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_cnUCthisp=_urMUAsuxeafc09490 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Folks, I'm looking for information on what the standards are for = "redirected mail". Basically any information on which headers are being = retained and which ones are modified. Any help's greatly appreciated.= thanks much in advance, Gerry Ocampo --Boundary_cnUCthisp=_urMUAsuxeafc09490 Content-Type: text/HTML Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

I'm looking for information on what the standards are for = "redirected mail". Basically any information on which headers are being retained and which ones are modified. Any help's greatly appreciated.

 

thanks much in advance,

Gerry Ocampo

--Boundary_cnUCthisp=_urMUAsuxeafc09490-- From owner-ietf-822 Tue Oct 7 13:29:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA07525 for ietf-822-bks; Tue, 7 Oct 1997 13:29:33 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA07519 for ; Tue, 7 Oct 1997 13:29:23 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA23552; Tue, 7 Oct 1997 16:30:40 -0400 (EDT) Message-Id: <199710072030.QAA23552@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: gocampo@us.oracle.com cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: redirected mail In-reply-to: Your message of "Mon, 06 Oct 1997 13:32:51 PDT." <199710062035.NAA22675@mailsun3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Oct 1997 16:30:40 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > I'm looking for information on what the standards are for "redirected > mail". Basically any information on which headers are being retained > and which ones are modified. Any help's greatly appreciated. It's not clear what you mean by "redirected"... Do you mean mail that is originally sent to address 'A' and automatically forwarded (presumably at a's request) to address 'B'? (in this case, common practice is to retain all headers) Or do you mean mail that is sent to 'A' and received by 'A' who then reads it and chooses to forward it to 'B'? (there are at least three common ways of doing this) Or do you mean something else? Keith From owner-ietf-822 Mon Oct 27 04:44:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA17879 for ietf-822-bks; Mon, 27 Oct 1997 04:44:03 -0800 (PST) Received: from muswell.demon.co.uk (muswell.demon.co.uk [158.152.10.120]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA17867 for ; Mon, 27 Oct 1997 04:43:45 -0800 (PST) Received: (from ruth@localhost) by muswell.demon.co.uk (8.6.12/8.6.12) id MAA06312; Mon, 27 Oct 1997 12:38:28 GMT Date: Mon, 27 Oct 1997 12:38:28 GMT Message-Id: <199710271238.MAA06312@muswell.demon.co.uk> From: ruth moulton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: info-mime@cs.utk.edu, ietf-822@imc.org Subject: mail to fax X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Cc: ruth@muswell.demon.co.uk Disposition-notification-to: ruth@muswell.demon.co.uk Sender: owner-ietf-822@imc.org Precedence: bulk Hi, I wonder if anyone can help me - I'm looking for a way to send e-mail out as fax: we have software that generates MIME/'822 e-mail for an application and sends the message out via sendmail or other local MTA we now have a requirement to send out the same message (when it's plain text only) but via fax, to a recipient fax machine, rather than via e-mail, I see solutions as being 1. send message to a gateway that will convert to fax and send over telephone to a fax m/c - are there any such gateways ? - is there any rfc that describes headers that are needed for this e.g. a header giving the final fax phone number ? 2. send the message to an application that takes in the mail and sends it out over fax - same as (1) really, but done on local machine - are there any such applications 3. our applicaiton works with an API between the application and the e-mail facilities - so write a back end for the API to drive a fax modem - are there any UNIX fax modem drivers available that provide something to work with ? - I guess this needs text-to-ccittG4fax conversion - does anyone know of such software ? 4. It is also needed for NT. Here we are using MAPI as the system mail api, does anyone know if one can send to a fax driver from MAPI (as one can send from other applications, e.g. word, given the fax driver is installed) I'd be grateful to any answers - or clues as to where look further, with thanks, Ruth -- ================================================ Ruth Moulton ruth@muswell.demon.co.uk Consultant 65 Tetherdown, London N.10 1NH, UK Tel:+44 181 883 5823 -- From owner-ietf-822 Mon Oct 27 06:17:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA19183 for ietf-822-bks; Mon, 27 Oct 1997 06:17:14 -0800 (PST) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA19179 for ; Mon, 27 Oct 1997 06:17:07 -0800 (PST) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.7/8.8.7) with ESMTP id JAA22458; Mon, 27 Oct 1997 09:16:09 -0500 Message-Id: <199710271416.JAA22458@black-ice.cc.vt.edu> To: ruth moulton Cc: info-mime@cs.utk.edu, ietf-822@imc.org Subject: Re: mail to fax In-Reply-To: Your message of "Mon, 27 Oct 1997 12:38:28 GMT." <199710271238.MAA06312@muswell.demon.co.uk> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1170871322P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 27 Oct 1997 09:16:06 -0500 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_-1170871322P Content-Type: text/plain; charset=us-ascii On Mon, 27 Oct 1997 12:38:28 GMT, ruth moulton said: > 1. send message to a gateway that will convert to fax and send over > telephone to a fax m/c > - are there any such gateways ? The name "hylafax" rings a bell here for sendmail->fax gateways. > - is there any rfc that describes headers that are needed for this > e.g. a header giving the final fax phone number ? None that I can see. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-1170871322P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBNFSiJdQBOOoptg9JAQHwkwP/dE6f84ajh5S+Ol85vPI9VjtSXEKaK13o xsF2rCXiOz5SKMWFxjUAt01xMVhyGdMCGKBlo9PnzbvgqDrJONT30jxzZd3nK00M HBehtzy/avVbtvkzooHq7vWoy0u5TP+iIV5MFS7Dh6bPsQqQz7CKPIzX5zbZYKLc WBLgIprWNFo= =5S4g -----END PGP MESSAGE----- --==_Exmh_-1170871322P-- From owner-ietf-822 Mon Oct 27 08:06:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA21027 for ietf-822-bks; Mon, 27 Oct 1997 08:06:17 -0800 (PST) Received: from amex.cox.smu.edu (root@mail.cox.smu.edu [129.119.80.101]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA21023 for ; Mon, 27 Oct 1997 08:06:12 -0800 (PST) Received: from p1.cox.smu.edu (p1.cox.smu.edu [129.119.81.10]) by amex.cox.smu.edu (8.6.12/8.6.9) with SMTP id KAA14911; Mon, 27 Oct 1997 10:05:11 -0600 Date: Mon, 27 Oct 1997 10:05:25 -0600 () From: Allen Gwinn To: ruth moulton cc: info-mime@cs.utk.edu, ietf-822@imc.org Subject: Re: mail to fax In-Reply-To: <199710271238.MAA06312@muswell.demon.co.uk> Message-ID: X-X-Sender: allen@mail.cox.smu.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-822@imc.org Precedence: bulk Check out HYLAFAX. It is what you are looking for. If you use paging, it has a rather smoothe interface to SNPP as well as TAP/IXO as well. The FAX part is highly configurable and adds powerful send/receive capabilites for everyone in your organization. Best of all, it is free! Cheers, Allen On Mon, 27 Oct 1997, ruth moulton wrote: > Hi, > > I wonder if anyone can help me - I'm looking for a way to send e-mail > out as fax: > > we have software that generates MIME/'822 e-mail for an > application and sends the message out via sendmail or other local MTA > > we now have a requirement to send out the same message (when it's > plain text only) but via fax, to a recipient fax machine, rather than > via e-mail, > > I see solutions as being > > 1. send message to a gateway that will convert to fax and send over > telephone to a fax m/c > - are there any such gateways ? > - is there any rfc that describes headers that are needed for this > e.g. a header giving the final fax phone number ? > > 2. send the message to an application that takes in the mail and sends > it out over fax - same as (1) really, but done on local machine - are > there any such applications > > 3. our applicaiton works with an API between the application and the > e-mail facilities - so write a back end for the API to drive a > fax modem > - are there any UNIX fax modem drivers available that provide > something to work with ? > - I guess this needs text-to-ccittG4fax conversion - does anyone know > of such software ? > > 4. It is also needed for NT. Here we are using MAPI as the system mail > api, does anyone know if one can send to a fax driver from MAPI > (as one can send from other applications, e.g. word, given the > fax driver is installed) > > I'd be grateful to any answers - or clues as to where look further, > > with thanks, > Ruth > > -- > ================================================ > Ruth Moulton ruth@muswell.demon.co.uk > Consultant > > 65 Tetherdown, > London N.10 1NH, UK Tel:+44 181 883 5823 > > -- > From owner-ietf-822 Mon Oct 27 11:38:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA24387 for ietf-822-bks; Mon, 27 Oct 1997 11:38:48 -0800 (PST) Received: from muswell.demon.co.uk (muswell.demon.co.uk [158.152.10.120]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA24376 for ; Mon, 27 Oct 1997 11:38:41 -0800 (PST) Received: (from ruth@localhost) by muswell.demon.co.uk (8.6.12/8.6.12) id TAA00342; Mon, 27 Oct 1997 19:26:10 GMT Date: Mon, 27 Oct 1997 19:26:10 GMT Message-Id: <199710271926.TAA00342@muswell.demon.co.uk> From: ruth moulton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: info-mime@cs.utk.edu, ietf-822@imc.org Cc: ruth moulton Subject: Re: mail to fax In-Reply-To: References: <199710271238.MAA06312@muswell.demon.co.uk> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Disposition-notification-to: ruth@muswell.demon.co.uk Sender: owner-ietf-822@imc.org Precedence: bulk thanks to everyone who replied to my query - you've given me plenty to follow up on, and thanks to any answers still comming my way! Ruth -- ================================================ Ruth Moulton ruth@muswell.demon.co.uk Consultant 65 Tetherdown, London N.10 1NH, UK Tel:+44 181 883 5823 -- From owner-ietf-822 Tue Nov 4 23:52:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA21699 for ietf-822-bks; Tue, 4 Nov 1997 23:52:02 -0800 (PST) Received: from davinci.netaxis.COM (davinci.netaxis.com [198.69.103.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA21695 for ; Tue, 4 Nov 1997 23:51:58 -0800 (PST) F