List-Header Digest Archive: April 1997 http://www.nisto.com/list-spec/mail/ X-List-Help: , X-List-Unsubscribe: X-List-Subscribe: X-List-Archive: X-List-Post: X-List-Owner: Contents: -> Re: List of Email Clients by Morna Findlay <(suppressed)@newcastle.ac.uk> -> Introduction... by (suppressed)@polyhymnia.pmail.gen.nz -> Re: List of Email Clients by Morna Findlay <(suppressed)@newcastle.ac.uk> -> Re: Introduction... by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> my status by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Introduction... by "Richard Stevenson" <(suppressed)@polyhymnia.pmail.gen.nz> -> Re: Introduction... by Christopher Allen <(suppressed)@consensus.com> -> Draft Letter to server authors by Grant Neufeld <(suppressed)@achilles.net> -> general report by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by Christopher Allen <(suppressed)@consensus.com> -> Re: general report by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: general report by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> List-Post by (suppressed)@akimbo.com -> Re: general report by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> minor revision to draft by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by Paul Hoffman <(suppressed)@imc.org> -> Re: minor revision to draft by Christopher Allen <(suppressed)@consensus.com> -> list-address field by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by Christopher Allen <(suppressed)@consensus.com> -> Re: list-address field by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: list-address field by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: list-address field by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Function name in header value by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: general report by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: general report by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: general report by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by Noritoshi Demizu <(suppressed)@csl.sony.co.jp> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by (suppressed)@akimbo.com -> Plain text in header fields (was: List-Post) by Grant Neufeld <(suppressed)@achilles.net> -> How many (which) headers? (was: general report) by Grant Neufeld <(suppressed)@achilles.net> -> List Details MIME part (was: general report) by Grant Neufeld <(suppressed)@achilles.net> -> s-ubscribe vs. the rest (was: general report) by Grant Neufeld <(suppressed)@achilles.net> -> Re: s-ubscribe vs. the rest (was: general report) by Rob Chandhok <(suppressed)@within.com> -> disclosing to the user (was: list-address field) by Grant Neufeld <(suppressed)@achilles.net> -> Re: list-address field by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by Marc Horowitz <(suppressed)@cygnus.com> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by Marc Horowitz <(suppressed)@cygnus.com> -> Re: Plain text in header fields (was: List-Post) by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: Plain text in header fields (was: List-Post) by Jason L Tibbitts III <(suppressed)@hpc.uh.edu> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by (suppressed)@akimbo.com -> Re: Plain text in header fields (was: List-Post) by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: s-ubscribe vs. the rest (was: general report) by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: general report by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? (was: general report) by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: s-ubscribe vs. the rest (was: general report) by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: general report by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: Plain text in header fields (was: List-Post) by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: list-address field by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: Plain text in header fields (was: List-Post) by Christopher Allen <(suppressed)@consensus.com> -> Re: s-ubscribe vs. the rest (was: general report) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Plain text in header fields (was: List-Post) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Plain text in header fields (was: List-Post) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: disclosing to the user (was: list-address field) by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: s-ubscribe vs. the rest (was: general report) by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: Plain text in header fields (was: List-Post) by Jason L Tibbitts III <(suppressed)@hpc.uh.edu> -> Re: general report by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: Plain text in header fields (was: List-Post) by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: Plain text in header fields (was: List-Post) by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: Plain text in header fields (was: List-Post) by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: Plain text in header fields (was: List-Post) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Christopher Allen <(suppressed)@consensus.com> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Christopher Allen <(suppressed)@consensus.com> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Christopher Allen <(suppressed)@consensus.com> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: general report by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> MIME type for List Details object (was: general report) by Grant Neufeld <(suppressed)@achilles.net> -> Re: Plain text in header fields by Grant Neufeld <(suppressed)@achilles.net> -> Re: list-address field by Grant Neufeld <(suppressed)@achilles.net> -> list spec updates by Grant Neufeld <(suppressed)@achilles.net> -> Re: How many (which) headers? by Grant Neufeld <(suppressed)@achilles.net> -> we're talking about mail - use mailto (was: Plain text in header fields) by Grant Neufeld <(suppressed)@achilles.net> -> Re: s-ubscribe vs. the rest by Grant Neufeld <(suppressed)@achilles.net> -> forbidden commands (was: Plain text in header fields) by Grant Neufeld <(suppressed)@achilles.net> -> Re: disclosing to the user by Grant Neufeld <(suppressed)@achilles.net> -> this list (was: list-address field) by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: How many (which) headers? by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: MIME type for List Details object (was: general report) by Marc Horowitz <(suppressed)@cygnus.com> -> Re: How many (which) headers? by Jason L Tibbitts III <(suppressed)@hpc.uh.edu> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Plain text in header fields by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Grant Neufeld <(suppressed)@achilles.net> -> Re: How many (which) headers? by Grant Neufeld <(suppressed)@achilles.net> -> Re: Plain text in header fields by Grant Neufeld <(suppressed)@achilles.net> -> Re: How many (which) headers? by (suppressed)@polyhymnia.pmail.gen.nz -> Re: How many (which) headers? by Jason L Tibbitts III <(suppressed)@hpc.uh.edu> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Plain text in header fields by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: How many (which) headers? by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: How many (which) headers? by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: Plain text in header fields (was: List-Post) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: general report by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: list-address field by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: list-address field by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: How many (which) headers? (was: general report) by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: How many (which) headers? (was: general report) by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Nested mailing lists by Jacob Palme <(suppressed)@dsv.su.se> -> Re: How many (which) headers? by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: list-address field by (suppressed)@frutiger.staffs.ac.uk (James Berriman) ---------------------------------------------------------------------- Date: 2 Apr 1997 04:09:23 -0500 From: Morna Findlay <(suppressed)@newcastle.ac.uk> Subject: Re: List of Email Clients >The December 96 issue of Internet World had a product comparison of the >following 12 email clients. I thought the list would be useful for our >evangelizing efforts: [List deleted] > >I know that this leaves out a lot of programs. (Such as Elm and Pine >already mentioned). However, I think this is a good start? Yes it is a good start but I think it's worth remembering programs like elm and pine which are free to the user and so have a heavy user-base and so will be around for a while. Here in the UK academic community a survey of all UK universities showed that ( in those sites which responded) pegasus was by far the most popular user agent. It's free - so it's give to students to use. Commercial UAs trailed in use but I'm sure these will be catching up fast as more staff and students get PCs on their desks. ( Yes, there are still plenty of staff here without email access!) cheers Morna Findlay Mailbase http://www.mailbase.ac.uk/ ( Main UK academic email list service) ---------------------------------------------------------------------- Date: 3 Apr 1997 07:21:57 -0500 From: (suppressed)@polyhymnia.pmail.gen.nz Subject: Introduction... - -----BEGIN PGP SIGNED MESSAGE----- Hi all I work for David Harris, the author of the Pegasus Mail system and Mercury mail transport system. This working group has been brought to our attention recently, and we decided to take a look at what you're doing. David can see the potential benefit in what you're all working to achieve, and is willing to support the headers you propose, both in the Pegasus Mail client and in the Mercury list server. I'm just here to let you know we're watching with great interest - let's face it, anything to make lists easier from the user's point of view is A Good Thing (TM). The proposed standard will go a long way toward the simplification of list use. I look forward to seeing the progress of the proposal. BTW, does this list server support MIME digests? The other kind are dreadful to work with... Cheers Richard - -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: cp850 iQCVAwUBM0Of7KRUcYUOWi3VAQFlNAP+KRIUMHVJdJd7N4HEjMuSUClYRxHs/itC oylHVICOi953dnwnaURQMmUH08Q1xKeL5PXNs03/UxTLfLjtdotMx7SFyAft2yQs J2kfNwYJzWSQjVjDJXqNogQrcq0c+9v20icSOEpiYB2DgThyrscWLW2OWU7IVeRS S+i0DFdQebg= =+qC8 - -----END PGP SIGNATURE----- - -- Richard Stevenson richard@polyhymnia.pmail.gen.nz Earth Rotation Protection Society http://home.sol.no/litlaboe/erps PGP Key ID 0x0E5A2DD5 fingerprint = 7B DD 1C 51 76 05 A1 42 44 2E DD 61 78 DB 2D 07 ---------------------------------------------------------------------- Date: 3 Apr 1997 07:59:57 -0500 From: Morna Findlay <(suppressed)@newcastle.ac.uk> Subject: Re: List of Email Clients I let the pegasus developers know about this group. Here's what they said: >> Hello - I wonder if you are aware of the IETF working party >> on list-headers. > >> The group is actively seeking the cooperation of developers >> of UAs to incorporate the proposed standards which will be >> aired at the Memphis IETF next week. >Thanks for the information - we hadn't heard of the proposal until your >message. We've taken a look at what the working group is proposing, and >are very interested. We'll be watching the progress of the standard with >an eye to implementing the changes required. > >Pegasus Mail Technical Support, Dunedin, New Zealand. >tech-support@pmail.gen.nz M Morna Findlay Mailbase Manager http://www.mailbase.ac.uk/ ---------------------------------------------------------------------- Date: 3 Apr 1997 09:58:02 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Introduction... At 7:17 AM -0500 4/3/97, Richard Stevenson wrote: > I work for David Harris, the author of the Pegasus Mail system and Mercury > mail transport system. This working group has been brought to our > attention recently, and we decided to take a look at what you're doing. Welcome! > David can see the potential benefit in what you're all working to achieve, > and is willing to support the headers you propose, both in the Pegasus > Mail client and in the Mercury list server. I'm just here to let you know > we're watching with great interest - let's face it, anything to make lists > easier from the user's point of view is A Good Thing (TM). The proposed > standard will go a long way toward the simplification of list use. I look > forward to seeing the progress of the proposal. Great to hear! Most people have met this proposal with open arms, and we already have some working implementations available for review. What features do you like most? What user-interface elements do you think will be most useful? > BTW, does this list server support MIME digests? The other kind are > dreadful to work with... Reply to this message and change the subject to "subscribe digest". ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 4 Apr 1997 13:21:39 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: my status Sorry I dropped off the face of the earth there - I got hit with a really nasty bug and so have been trying to spend most of my time sleeping, napping or whining ;-) The bug seems to be starting to let up, so I may be able to get to the pr stuff sometime over the next few days. Please bear with me on this. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 4 Apr 1997 17:54:47 -0500 From: "Richard Stevenson" <(suppressed)@polyhymnia.pmail.gen.nz> Subject: Re: Introduction... - -----BEGIN PGP SIGNED MESSAGE----- On 3 Apr 97 at 9:53, Joshua D. Baer wrote: > At 7:17 AM -0500 4/3/97, Richard Stevenson wrote: > > > David can see the potential benefit in what you're all working to achieve, > > and is willing to support the headers you propose, both in the Pegasus > > Mail client and in the Mercury list server. I'm just here to let you know > > we're watching with great interest - let's face it, anything to make lists > > easier from the user's point of view is A Good Thing (TM). The proposed > > standard will go a long way toward the simplification of list use. I look > > forward to seeing the progress of the proposal. > > Great to hear! Most people have met this proposal with open arms, and we > already have some working implementations available for review. What > features do you like most? What user-interface elements do you think will > be most useful? The best part of it is that the list subscriber doesn't have to worry about remembering what the commands are, and whether they should be placed in the subject or the body of the message. I've come into the discussion too late, given that there is already an IETF draft on this... but here's one concern I do have. RFC1738 defines the Mailto: URL as mailto: The ?Subject= and ?Body= extensions, along with any others, are non-standard. Does anybody know if a revision of, or amendment to, RFC1738 is in the pipeline? I can't imagine anything worse than specifying certain URL formats for list headers, and then having the specification for Mailto: URLs use a different format when it eventually specifies extensions of this type. > > BTW, does this list server support MIME digests? The other kind are > > dreadful to work with... > > Reply to this message and change the subject to "subscribe digest". Tried that... it's the other kind of digest Cheers Richard - -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: cp850 iQCVAwUBM0WE6KRUcYUOWi3VAQEydgQAkrSouUNBsttmo4Si9TbbQFv+Gvgn924X DI5LyuZhsvqnBk6HuSGjCDHewUas+Hk0LQPMcibmTLe4xg5+eG0ggYG1Ro9vures MBnLn8gDfXAY9hhYIKeAHOn1uCWa2nSPzLO9D8FDSvOBHN3+vpbAScQ+b98Ub7gb C0H7e6tP92g= =pC+K - -----END PGP SIGNATURE----- ---------------------------------------------------------------------- Date: 4 Apr 1997 18:11:59 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: Introduction... At 2:47 AM -0800 4/5/97, Richard Stevenson wrote: >I've come into the discussion too late, given that there is already >an IETF draft on this... but here's one concern I do have. RFC1738 >defines the Mailto: URL as > >mailto: > >The ?Subject= and ?Body= extensions, along with any others, are >non-standard. Does anybody know if a revision of, or amendment to, >RFC1738 is in the pipeline? I can't imagine anything worse than >specifying certain URL formats for list headers, and then having the >specification for Mailto: URLs use a different format when it >eventually specifies extensions of this type. There is already a well-recieved Internet-Draft that defines the ?subject=, etc. tags. It is . Mailto:'s in this format have been adopted by most every Mac mail software developer, Netscape, Microsoft, and a number of PC mail software developers. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 12 Apr 1997 13:28:07 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Draft Letter to server authors Please review the following and let me know if it looks good for sending to list server software authors. (the letters for list managers and client authors are nearly identical) Are the spelling, grammar, punctuation, etc. okay? Does it cover everything needed for a cover letter? Is there anything that doesn't need to be in this letter? Is it 'enticing' enough to get them interested? --- Begin DRAFT Letter --- This is a request for you to implement support for the List Header initiative which will make mail list access much easier for users. The newly defined List Header Fields provide you with a standard method by which you can consistently describe electronic mailing list command syntax so that client applications can implement an interface to make list access easier for users. As they are adopted and supported by email software developers, the List header fields will make it easier for users to join and leave email lists. The currently defined fields are List-Subscribe, List-Unsubscribe and List-Help. They describe commands for subscribing, unsubscribing and retrieving help information. An Internet-Draft, which formally describes the header fields and their content, has been submitted to the IETF for consideration to become an RFC. Implementation guidelines for list software authors are available at: Extended details on the List header fields are available from: A mailing list for discussion is available at: or Please let us know if you plan to implement support for the List header fields, and also if/when you ship an implementation, so we can track the progress of this initiative. --- End Letter --- - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 12 Apr 1997 13:56:44 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: general report Well, I seem to be mostly over the bug that had me wiped out for a while there. Just some lingering throat irritation left. So, I'm back in action again, finally. New document: "Guidelines to the List Specification Header Fields for Server Application Authors" Updated documents: I've split up the main document a bit. The technical stuff has been split off into separate documents: with more to come (such as the MIME part). Any news from Memphis, yet? Did the BOF thing happen? We still need people to contact mail software authors. The biggies that we don't have contacts for yet include: AOL, Netscape, ELM, PINE, Listserv, Listproc, SmartMail. Although many of those are represented on lists like List-Managers. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 12 Apr 1997 14:14:08 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: general report At 10:56 AM -0700 4/12/97, Grant Neufeld wrote: >Any news from Memphis, yet? Did the BOF thing happen? Yes, there was a BOF meeting at IETF Memphis. It originally was to be much larger in scope then our internet draft (there were two chairmen of the BOF that had I think a larger agenda in mind) but in the end most of the discussion was about our internet draft. I gave a brief overview of the draft, and tried to respond to questions that people had. The two biggest concerns were that some firewalls and gateways strip out unknown headers (the response to which was that it was a chicken and egg situation, they wouldn't add the headers until the draft was accepted) and the use of List-Subscribe as a priority over List-Archive (which I tried to respond to but didn't have a strong point). Other concerns were raised but I think I adequately covered them based on the results of previous discussions on this list. Most of the discussion was of making List-Header a working group, and we decided that we didn't want to have agenda creep. So instead, we should do a two-week "list last call" and advertise it widely, and then submit the draft to the IESG for a four week "IESG Last Call". If there are no major objections, we could be an RFC without using a Working Group in 6 week! I had to leave the meeting early (it was scheduled at the same time as the S/MIME BOF), so I don't have the minutes for the whole meeting, but I was told later that there was not a whole lot more discussion after I left. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 12 Apr 1997 19:15:58 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: general report At 2:11 PM -0400 4/12/97, Christopher Allen wrote: > I gave a brief overview of the draft, and tried to respond to questions > that people had. The two biggest concerns were that some firewalls and > gateways strip out unknown headers (the response to which was that it was a > chicken and egg situation, they wouldn't add the headers until the draft > was accepted) and the use of List-Subscribe as a priority over List-Archive > (which I tried to respond to but didn't have a strong point). Other > concerns were raised but I think I adequately covered them based on the > results of previous discussions on this list. From your comments and those on this list, I'm favorable towards adding List-Archive and even List-Post to the draft. What do others think? ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 12 Apr 1997 20:12:08 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: general report At 07:11 PM 4/12/97 -0400, you wrote: >At 2:11 PM -0400 4/12/97, Christopher Allen wrote: > >> I gave a brief overview of the draft, and tried to respond to questions >> that people had. The two biggest concerns were that some firewalls and >> gateways strip out unknown headers (the response to which was that it was a >> chicken and egg situation, they wouldn't add the headers until the draft >> was accepted) and the use of List-Subscribe as a priority over List-Archive >> (which I tried to respond to but didn't have a strong point). Other >> concerns were raised but I think I adequately covered them based on the >> results of previous discussions on this list. > >From your comments and those on this list, I'm favorable towards adding >List-Archive and even List-Post to the draft. What do others think? From the IETF meeting, I think there was general feeling on keeping the draft at subscribe, unsubscribe, and help. Now, it was also felt that coming out with another doc, after the current one is a standard, that would encompass that doc, plus allow for enhancing mechanisms would be a good thing. i.e. get the current one through with a minimum of fuss and then worry about adding more. regards, Jack p.s. in favour of defining list- headers, and then defining a list of verbs, to keep the draft extensible - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 12 Apr 1997 23:40:00 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > Yes, there was a BOF meeting at IETF Memphis. It originally was to be much > larger in scope then our internet draft (there were two chairmen of the BOF > that had I think a larger agenda in mind) but in the end most of the > discussion was about our internet draft. The "two chairmen of the BOF that I think had a larger agenda in mind" could be read multiple ways, so let me clarify: We had two different requests, from two different parties, for mailing list related BOFs. One BOF request was for the List-* headers; the other was for a BOF to form a working group to standardize mailing list commands. Since we have a limited number of meeting slots, and the two topics were so similar, the Applications area directors (Harald Alvestrand and myself) decided to combine the two into a single BOF covering both topics. Rather than snub either proposal by appointing the other proposal's champion as BOF chair, we appointed Ned Freed and John Klensin as neutral co-chairs. (So yes, the chairs did have a larger agenda in mind, but they were just following the wishes of the area directors.) Given that the List-* proposal had a well-written draft document, and the other BOF topic had no document at all...it's not surprising that the List-* proposal got more attention. It's hard to discuss a proposal that doesn't exist in concrete form. Keith ---------------------------------------------------------------------- Date: 13 Apr 1997 01:14:44 -0400 From: (suppressed)@akimbo.com Subject: List-Post One recent thought I had about the headers is that we should define a format for message text instead of a URL. This is useful for List-Post in particular: List-Post: "You cannot post to this list. It is an announce-only list." Here I'm presuming that "..." is the syntax adopted for message text. The message would of course be directly readable in the headers, and if the user were to hit the "Post" button in a mail program, presumably this message would pop up. I can't see much use for message text in the other headers, although I suppose: List-Subscribe: "Send $99 to Scam & Spam, PO Box 1234, ..." would be useful to someone :-). --- Bruce Leban Akimbo Systems http://www.akimbo.com/globetrotter Publish on the web without learning HTML! (Really.) ---------------------------------------------------------------------- Date: 13 Apr 1997 02:34:19 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: general report At 11:36 PM -0400 4/12/97, Keith Moore wrote: > Given that the List-* proposal had a well-written draft document, and > the other BOF topic had no document at all...it's not surprising that > the List-* proposal got more attention. It's hard to discuss a > proposal that doesn't exist in concrete form. If it's not too off topic, could someone provide a concise summary of the other proposal? I think it would be of general interest here... ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 13 Apr 1997 09:56:48 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > If it's not too off topic, could someone provide a concise summary of the > other proposal? I think it would be of general interest here... All I have is a mail message from the person who proposed the BOF, which was basically of the form "wouldn't it be nice if we standardized a command language for mailing lists?" Most people would agree that it would be nice. But the last time we tried to do it, we found it (a) VERY difficult to get anything like consensus on the language to be used, and (b) also difficult to keep the discussion from diverging in to other areas -- such as whether and how lists should mung message headers. Keith ---------------------------------------------------------------------- Date: 13 Apr 1997 10:43:00 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: minor revision to draft In cleaning up the references section, a couple references that are referenced in appendix A were omitted, resulting in 'hanging' references. (how many references to the word reference can I make in one sentance? :-) Specifically, the [2] and [3] in the first paragraph of appendix A, which do not match the actual References in the draft. Should I submit a new version (01) of the draft, or can I just submit this as a minor correction to the standing draft? Here are the pertinant chunks of the current draft: A. Background Discussion This proposal arose from discussions started on the ListMom-Talk Discussion List [2]. When the discussion reached a sufficient level, a separate list was formed for discussing this proposal, the List Headers Mail List [3] for deeper discussion. We have included edited excerpts from that discussion here, in order to show some of the alternatives examined and reasons for our decisions. References [1] David H. Crocker, "Standard for the Format of ARPA Internet Text Messages" RFC 822, August 1982. [2] P. Hoffman and L. Masinter, "The mailto URL scheme" 'work in progress' January 1997. [3] T. Berners-Lee, L. Masinter and M. McCahill, "Uniform Resource Locators (URL)" RFC 1738, December 1994. I would either remove the references ("[2]" and "[3]") from the appendix, or add the two lists to the References section. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 13 Apr 1997 10:50:46 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: general report At 2:11 PM -0400 97/4/12, Christopher Allen wrote: >I gave a brief overview of the draft, and tried to respond to questions >that people had. Thanks for your work on this - it's much appreciated! >The two biggest concerns were that some firewalls and >gateways strip out unknown headers (the response to which was that it was a >chicken and egg situation, they wouldn't add the headers until the draft >was accepted) We're never going to be able to completely cover the wide variety of behaviours (broken or otherwise) exhibited by mail handling systems, but we can still make a significant difference for those systems that don't munge the headers. If we give up on trying to improve things because we can't help everybody, we'll never get anywhere. >and the use of List-Subscribe as a priority over List-Archive >(which I tried to respond to but didn't have a strong point). I stick to my point that it's the most widely used command (more people subscribe than unsubscribe) and as such there will be much to benefit from providing standardized access to it. >Other >concerns were raised but I think I adequately covered them based on the >results of previous discussions on this list. Great! Thanks again. >Most of the discussion was of making List-Header a working group, and we >decided that we didn't want to have agenda creep. So instead, we should do >a two-week "list last call" and advertise it widely, and then submit the >draft to the IESG for a four week "IESG Last Call". If there are no major >objections, we could be an RFC without using a Working Group in 6 week! That would be excellent. How does the IESG last call and vote work? The IETF procedures I read didn't explain these. >I had to leave the meeting early (it was scheduled at the same time as the >S/MIME BOF), so I don't have the minutes for the whole meeting, but I was >told later that there was not a whole lot more discussion after I left. Where can we get ahold of the minutes? Could someone post a copy here if they have them, please? - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 13 Apr 1997 10:51:53 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: general report At 7:11 PM -0400 97/4/12, Joshua D. Baer wrote: >At 2:11 PM -0400 4/12/97, Christopher Allen wrote: ... >> was accepted) and the use of List-Subscribe as a priority over List-Archive ... > >From your comments and those on this list, I'm favorable towards adding >List-Archive and even List-Post to the draft. What do others think? I don't want to push anything else into the current draft. It'll (hopefully) be a lot easier to get other things working once we have the core headers formally standardized. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 13 Apr 1997 20:12:49 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > >The two biggest concerns were that some firewalls and > >gateways strip out unknown headers (the response to which was that it was a > >chicken and egg situation, they wouldn't add the headers until the draft > >was accepted) > > We're never going to be able to completely cover the wide variety of > behaviours (broken or otherwise) exhibited by mail handling systems, but we > can still make a significant difference for those systems that don't munge > the headers. That's exactly right. Furthermore, we don't want to cater too much to broken behavior -- it just encourages it. Things that strip headers without knowing what they are deserve to lose. > If we give up on trying to improve things because we can't help everybody, > we'll never get anywhere. In other words, "the best is the enemy of the good". > >and the use of List-Subscribe as a priority over List-Archive > >(which I tried to respond to but didn't have a strong point). > > I stick to my point that it's the most widely used command (more people > subscribe than unsubscribe) and as such there will be much to benefit from > providing standardized access to it. As I recall, the argument was that List-Unsubscribe (not List-Archive) should be given top billing, because that will be seen to be the most useful feature. (or at least, it will provide the most pain relief.) Personally, I don't think it's a big deal either way, as long as both capabilities are present. > How does the IESG last call and vote work? The IETF procedures I read > didn't explain these. When you get the draft to the point that you think it's ready, (1) publish that document as a revised internet-draft, and (2) send mail to the IESG APPS Area Directors (me and Harald Alvestrand <(suppressed)@uninett.no>) asking that that draft be considered as a Proposed Standard. One of us will ask the Secretariat to send out a Last Call. The Last Call is announced by email to the IETF mailing list. The announcement is basically of the form: The IESG has received a request to consider "title" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by . The IESG will read the draft, along with any comments. Depending on the nature of the comments, the IESG may ask the authors to respond to the comments and/or revise the draft in light of comments. When the Last Call expires, the IESG will vote on the draft. If the IESG approves the draft, the approval will be announced to the IETF mailing list, and the RFC Editor will be asked to publish it as a Proposed Standard RFC. > Where can we get ahold of the minutes? Could someone post a copy here if > they have them, please? WG and BOF chairs have a couple of weeks to submit the minutes. Once the minutes are submitted, they will appear on the IETF web site. I'll try to rememebr to post them here when I get them. Keith ---------------------------------------------------------------------- Date: 13 Apr 1997 22:44:09 -0400 From: Paul Hoffman <(suppressed)@imc.org> Subject: Re: general report At 1:00 PM -0700 4/13/97, Keith Moore wrote: >When you get the draft to the point that you think it's ready, (1) >publish that document as a revised internet-draft... In the appendix to that finalish document, I suggest that you put a mention of this mailing list, and the list archives, so that people don't rehash old arguments. When (er, if) we get past the last call, you can ask the RFC editor to remove that appendix before publishing it as an RFC. Such a reference is, however, very useful to have on a non-WG document. - --Paul Hoffman, Director - --Internet Mail Consortium ---------------------------------------------------------------------- Date: 14 Apr 1997 09:58:59 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: minor revision to draft At 7:41 AM -0700 4/13/97, Grant Neufeld wrote: >Should I submit a new version (01) of the draft, or can I just submit this >as a minor correction to the standing draft? You have to do an 01. > [2] P. Hoffman and L. Masinter, "The mailto URL scheme" > 'work in progress' January 1997. /internet-drafts/draft-hoffman-mailto-url-00.txt> BTW, this has since been revised to 01 itself. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 15 Apr 1997 15:06:08 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: list-address field The new draft (01) suggests the following guideline for user feedback: > For 'mailto' URL based commands, mail client applications should > provide specialized feedback (such as presenting a dialog or alert), > instead of the actual command email message, asking for command > confirmation from the user. The feedback should identify the message > destination and command within a more descriptive explanation. For > example: > > "Do you want to send the unsubscription command 'unsubscribe > somelist' to 'somelist-request@some.host.com'? > Sending the command will result in your removal from the > associated list." Thought we wanted to hide this kind of information from the user. (If the user wants to see it, he reviews the outgoing message.) Some list servers also use the subject field. So then we mention all this detailed information, and pretty soon we have some verbiage that looks very similar to a URL!!! What happened to the list-address field? MUAs could be much more friendly with warnings such as: "Are you sure you want to unsubscribe from the "somelist@some.host.com" mailing list? You will no longer receive any posts to this list." - -Clarence ---------------------------------------------------------------------- Date: 15 Apr 1997 15:31:57 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: list-address field At 2:57 PM -0400 4/15/97, Clarence C. Wong wrote: > What happened to the list-address field? MUAs could be much more friendly > with warnings such as: "Are you sure you want to unsubscribe from the > "somelist@some.host.com" mailing list? You will no longer receive any posts > to this list." This would probably be the same as the List-Post field. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://www.skyweyr.com/skylist/ ---------------------------------------------------------------------- Date: 15 Apr 1997 18:38:34 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: list-address field At 10:57 AM -0800 4/15/97, Clarence C. Wong wrote: >> "Do you want to send the unsubscription command 'unsubscribe >> somelist' to 'somelist-request@some.host.com'? >> Sending the command will result in your removal from the >> associated list." > >Thought we wanted to hide this kind of information from the user. This is a recommendation for a dialogue that could be presented if list-header smart mail-agent app wants to notify the user. This is not text for the subject line. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 15 Apr 1997 19:15:34 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: list-address field >At 10:57 AM -0800 4/15/97, Clarence C. Wong wrote: >>> "Do you want to send the unsubscription command 'unsubscribe >>> somelist' to 'somelist-request@some.host.com'? >>> Sending the command will result in your removal from the >>> associated list." >> >>Thought we wanted to hide this kind of information from the user. > >This is a recommendation for a dialogue that could be presented if >list-header smart mail-agent app wants to notify the user. This is not text >for the subject line. > I know. Maybe I didn't make myself clear. One of my points is that the MUA doesn't know where the command is. It could be in the subject or the body, or even in another header field (I think SmartList looks for a specific header field, though I could be mistaken.) All the MUA knows is what kind of command it is (e.g. subscribe, unsubscribe, help) and where the list server is (e.g. somelist-request@some.host.com). Should the user care where the list server is? Should he care about what text is being sent (in the subject, body, or any other header field)? I thought we were trying to hide these details from the user. I think the user should really only be concerned with the command and the mailing list. The confirmation dialog should present that information in a clear and simple way. - -Clarence ---------------------------------------------------------------------- Date: 15 Apr 1997 19:40:25 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: list-address field > > For 'mailto' URL based commands, mail client applications should > > provide specialized feedback (such as presenting a dialog or alert), > > instead of the actual command email message, asking for command > > confirmation from the user. The feedback should identify the message > > destination and command within a more descriptive explanation. For > > example: > > > > "Do you want to send the unsubscription command 'unsubscribe > > somelist' to 'somelist-request@some.host.com'? > > Sending the command will result in your removal from the > > associated list." > > Thought we wanted to hide this kind of information from the user. (If the > user wants to see it, he reviews the outgoing message.) Some list servers > also use the subject field. So then we mention all this detailed > information, and pretty soon we have some verbiage that looks very similar > to a URL!!! Hiding what's sent from the user leads to a security problem. Suppose the message actually sent does something completely different than the header it appears it suggests? The message might not have come from the list server. It could have been faked. ---------------------------------------------------------------------- Date: 15 Apr 1997 20:35:23 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: list-address field At 7:31 PM -0400 4/15/97, Roger Fajman wrote: >Hiding what's sent from the user leads to a security problem. Suppose >the message actually sent does something completely different than the >header it appears it suggests? The message might not have come from >the list server. It could have been faked. Good point. This is why the URL specification warns against automatically queuing or sending messages. The URL should behave the same way it does now, bringing forth a sendable message. The confirmation dialog should inform the user what the intended action of this message is. Then, it is the user's responsibility to review and send/cancel the message. - -Clarence ---------------------------------------------------------------------- Date: 16 Apr 1997 00:30:19 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Function name in header value One point that I raised at the BOF was the possibility of moving the name of the function into the header value, instead of the name of the header. The advantages of this are twofold. One is that firewalls need look for only one header instead of many. If a new function is added, firewalls that look at headers don't need to be changed unless they look inside the header. The other advantage is that only one header name is defined, which may address the concern of some about defining a large number of headers. The grammar could be something like this: list-header = "List-function" ":" function-name 1*("," url) function-name = "help" / "unsubscribe" / "subscribe" / "archives" ... Or, at the cost of some additional complexity, multiple functions could be allowed in one header: list-header = "List-function" ":" function-spec *(";" function-spec) function-spec = function-name 1*("," url) function-name = "help" / "unsubscribe" / "subscribe" / "archives" ... The additional complexity is not strictly necessary, as multiple headers can be specified for multiple functions. ---------------------------------------------------------------------- Date: 16 Apr 1997 00:40:27 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: general report > From the IETF meeting, I think there was general feeling on keeping the > draft at subscribe, unsubscribe, and help. Now, it was also felt that > coming out with another doc, after the current one is a standard, that would > encompass that doc, plus allow for enhancing mechanisms would be a good thing. > i.e. get the current one through with a minimum of fuss and then worry > about adding more. I was at the BOF and I don't remember it that way. I brought up the issue of archives and the presenter gave the argument in favor of restricting it to the three functions. I don't recall a lot of comment one way or the other from the rest of the people on that issue. No straw poll was taken. The consideration of firewalls that look of headers seems to me to be a point in favor of not dribbling them out or of using a more extensible syntax. Also, we are asking user agent and list server developers to add support for these headers. It's easier for them to do it once instead of several times. Also, user education is easier if there is a standard set of headers that encompasses most functions, as it is less likely that there will be varying levels of support in different list servers and user agents that have been deployed at different times. ---------------------------------------------------------------------- Date: 16 Apr 1997 00:46:03 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: general report > >and the use of List-Subscribe as a priority over List-Archive > >(which I tried to respond to but didn't have a strong point). > > I stick to my point that it's the most widely used command (more people > subscribe than unsubscribe) and as such there will be much to benefit from > providing standardized access to it. But I think it's unlikely that most people will be subscribing through the use of a List-subscribe header. ---------------------------------------------------------------------- Date: 16 Apr 1997 00:52:43 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: general report At 12:40 AM -0400 4/16/97, Roger Fajman wrote: > > >and the use of List-Subscribe as a priority over List-Archive > > >(which I tried to respond to but didn't have a strong point). > > > > I stick to my point that it's the most widely used command (more people > > subscribe than unsubscribe) and as such there will be much to benefit from > > providing standardized access to it. > > But I think it's unlikely that most people will be subscribing > through the use of a List-subscribe header. I like both, but if I had to choose at this point I would take List-Post or List-Archive over List-Subscribe. I see the usefulness of them all, but I can visualize a "Post to List" button in my Eudora window or a "View List ArchivesŠ" menu item and would value either more than a "Subscribe" button. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 16 Apr 1997 01:10:51 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > > I stick to my point that it's the most widely used command (more people > > subscribe than unsubscribe) and as such there will be much to benefit from > > providing standardized access to it. > > But I think it's unlikely that most people will be subscribing > through the use of a List-subscribe header. I don't think it's very likely that someone will subscribe to a list using a List-subscribe header from a message from that list distributed to that person. However, if a List-subscribe field were defined, people would know to look there, and that would help distribute information about the list to interested parties (including, alas, spammers). I also think it would be useful to have a text/mailing-list MIME type, that contains one or more List-* fields in the body part. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 01:41:54 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > I like both, but if I had to choose at this point I would take List-Post or > List-Archive over List-Subscribe. I see the usefulness of them all, but I > can visualize a "Post to List" button in my Eudora window or a "View List > Archives" menu item and would value either more than a "Subscribe" button. I don't think there's a strong need to the number of List-* fields defined in the RFC. If some of the fields turn out to be not very useful, people won't use them as often. But as long as a List-* field appears to have reasonable utility, and as long as there's reasonable consensus about how to define a particular field, you might as well include it. IMHO, List-{Post,Subscribe,Unsubscribe,Archive,Maintainer} are all likely to fall in that category. Much beyond that, and it's probably a loss. However, I would like to know if there's interest in one more field: a List-Info field which contains a URL that, when referenced, produces an object of type text/mailing-list-info, where the latter is a complete list of List-* fields for that list. So a message from a list might contain three fields: List-Unsubscribe: List-Maintainer: List-Info: and if you look up the latter URL, you'll get back the complete set of info for that list: content-type: text/mailing-list-info [in the http response header] List-Subscribe: List-Unsubscribe: List-Maintainer: List-Info: List-Archive: List-Post: List-Description: this list discusses foos List-Spam-Policy: let's stamp out spam in our lifetime - -Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 01:49:26 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: general report At 1:24 AM -0400 4/16/97, Keith Moore wrote: > > I like both, but if I had to choose at this point I would take List-Post or > > List-Archive over List-Subscribe. I see the usefulness of them all, but I > > can visualize a "Post to List" button in my Eudora window or a "View List > > Archives" menu item and would value either more than a "Subscribe" button. > > I don't think there's a strong need to the number of List-* fields defined > in the RFC. If some of the fields turn out to be not very useful, > people won't use them as often. But as long as a List-* field appears > to have reasonable utility, and as long as there's reasonable consensus > about how to define a particular field, you might as well include it. > > IMHO, List-{Post,Subscribe,Unsubscribe,Archive,Maintainer} are all likely > to fall in that category. Much beyond that, and it's probably a loss. > > However, I would like to know if there's interest in one more field: a > List-Info field which contains a URL that, when referenced, > produces an object of type text/mailing-list-info, where the latter is > a complete list of List-* fields for that list. I like that a lot! It's a very simple meta language itself. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 16 Apr 1997 08:28:35 -0400 From: Noritoshi Demizu <(suppressed)@csl.sony.co.jp> Subject: Re: list-address field > > What happened to the list-address field? MUAs could be much more friendly > > with warnings such as: "Are you sure you want to unsubscribe from the > > "somelist@some.host.com" mailing list? You will no longer receive any posts > > to this list." > > This would probably be the same as the List-Post field. the list-address field and the list-post field seem to have different meaning. Because the list-post field seems to to control users' posting, the values of the list-address field and the list-post field will be different when the mailing list is moderated (I'm not sure this is the case) or the mailing list is only for announcement. So how about to use the list-post field only when the administrator wants to control users' posting? case 1: When the subscribers can post freely, List-Address: list-header@arpp.carleton.ca case 2: When the subscribers are not allowed to post to the list. List-Address: list-header-announce@arpp.carleton.ca List-Post: (I dont' have good idea about the format of this URL...) case 3: When the list is moderated and has another address for the moderator, List-Address: list-header-announce@arpp.carleton.ca List-Post: Of course, we can integrate these two headers by introducing some schemes like . But if the list-address field contains e-mail address only, we can use the field from scan.form of MH easily. :-) By the way, I also would like to have sequence number in list headers in addition to the name of mailing list. There are many mailng lists which modifies subject fields to insert the mailing list name and the sequence number. e.g. Subject: (list-header 200) Re: list-address field Although I think having these information in the output of "MH-scan" is very useful in many cases, modification of subject field is sometimes not convenient. So if we could have the name and the sequence number in standardized separated fields other than subject field, e.g. List-Address: list-header@arpp.carleton.ca List-Seq: 200 we'll be happy by modifying maybe the last line of our scan.form of MH like the following: (%{list-address} %{list-seq}) %{subject}%<{body}<<%{body}%> They also will be very useful when refiling mail automatically and sorting mail according to sequence numbers. Regards, Noritoshi Demizu ---------------------------------------------------------------------- Date: 16 Apr 1997 12:14:59 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: list-address field At 8:24 AM -0400 4/16/97, Noritoshi Demizu wrote: > case 1: When the subscribers can post freely, > List-Address: list-header@arpp.carleton.ca Or List-Post: > case 2: When the subscribers are not allowed to post to the list. > List-Address: list-header-announce@arpp.carleton.ca > List-Post: > (I dont' have good idea about the format of this URL...) In this case you just wouldn't include a List-Post header, because posting is not allowed. > case 3: When the list is moderated and has another address for the >moderator, > List-Address: list-header-announce@arpp.carleton.ca > List-Post: Or List-Post: In each of your examples, I don't see why the extra List-Address field is necessary or useful. What would it be used for? What information is there which isn't in other, more appropriate places? Further, what address should List-Address point to? It's not clear, (posting address, control address, some other?) while the List-Post content is extremely clear. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 16 Apr 1997 12:35:03 -0400 From: (suppressed)@akimbo.com Subject: Re: list-address field >> "Do you want to send the unsubscription command 'unsubscribe >> somelist' to 'somelist-request@some.host.com'? >> Sending the command will result in your removal from the >> associated list." One reason for a message in this form is for security reasons. For example, suppose some evil spammer puts the header List-Unsubscribe: A message like "Do you want to send the unsubscription command 'death threat' to 'someone@hate.mail'? Sending the command will result in your removal from the associated list." We hope the user might realize that the second sentence and the first sentence say very different things and cancel. --- Bruce Leban Akimbo Systems http://www.akimbo.com/globetrotter Publish on the web without learning HTML! (Really.) ---------------------------------------------------------------------- Date: 16 Apr 1997 13:14:03 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Plain text in header fields (was: List-Post) At 1:11 AM -0400 97/4/13, BruceLeban@akimbo.com wrote: >One recent thought I had about the headers is that we should define a >format for message text instead of a URL. This is useful for List-Post in >particular: I've produced an initial description of the inclusion of plain text items in the List- header fields. I've added this to http://arpp.carleton.ca/listspec/header-fields.html#UseOfPlainText Use of Plain Text Header fields could be used to provide a plain text message to users. For example, a list which does not allow posting (announcements only) might use the List-Post header field with a plain text message stating "You cannot post to this list. It is only for announcements." instead of providing a mailto URL for an address to post to. Plain text will be identified in the List- header fields by enclosing it in double-quotes: "plain text". No special encoding is required except that used by the mail transport mechanism (e.g., Quoted Printable). This method presents problems in terms of multi-lingual support and non-standard messages. Formal specification of list attributes may be a more appropriate method of identifying restrictions and features of mailing lists (as currently proposed in the form of the List-Attributes header field and the List Attributes identifier meta-syntax). However, the inclusion of plain text in the List headers provides directly human-readable description without the intervention of the client application. Additionally, the allowance for plain text in the header fields would provide greater flexibility for describing specific conditions of a mailing list that may not be covered through formal list attribute identification. It may also be useful to combine plain text with the use of meta-syntax (currently URLs) in the header fields. A possible example of this could be: List-Post: "Post only through the web form" Client applications may want to display the plain text to the user in the form of a dialog or alert when the user initiates the associated action. For example, a no-posting list might have the header: List-Post: "No posting on this list - announcements only." So that when the user clicks on the "Post to List" button (or whatever), the client application pops up an alert like: Cannot post to this list: "No posting on this list - announcements only." - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 13:14:20 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: How many (which) headers? (was: general report) At 12:35 AM -0400 97/4/16, Roger Fajman wrote: >The consideration of firewalls that look of headers seems to me to be a >point in favor of not dribbling them out or of using a more extensible >syntax. Also, we are asking user agent and list server developers to >add support for these headers. It's easier for them to do it once >instead of several times. Also, user education is easier if there is a >standard set of headers that encompasses most functions, as it is less >likely that there will be varying levels of support in different list >servers and user agents that have been deployed at different times. At 1:24 AM -0400 97/4/16, Keith Moore wrote: >If some of the fields turn out to be not very useful, >people won't use them as often. But as long as a List-* field appears >to have reasonable utility, and as long as there's reasonable consensus >about how to define a particular field, you might as well include it. Good points. Hmmm, maybe we need to reconsider the decision to restrict the initial effort to just the core functions. The reasons I see for keeping it to just the 3 are as follows: - - Fewer headers means we're less likely to run into "header bloat" objections. Basically, trying to be as inoffensive as possible to improve our chances of making it through the standards process. - - Minimize the use of headers (avoid bloat) and focus further efforts on things like the MIME part, footers, specialized messages, etc. Some people have asked: why not just skip headers altogether and just work on the more comprehensive and flexible alternatives? - - Various headers of this type are already in use (X-URL, X-Unsubscribe, etc.) so let's standardize them so they can be useful to client applications. - - Header support is relativly easy to implement. - - Headers don't pose the problems that things like MIME parts do. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 13:14:37 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: List Details MIME part (was: general report) At 1:24 AM -0400 97/4/16, Keith Moore wrote: >However, I would like to know if there's interest in one more field: a >List-Info field which contains a URL that, when referenced, >produces an object of type text/mailing-list-info, where the latter is >a complete list of List-* fields for that list. I've written up a description of this (using the example Keith provided) at: http://arpp.carleton.ca/listspec/mime-part.html - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 13:16:16 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: s-ubscribe vs. the rest (was: general report) At 12:40 AM -0400 4/16/97, Roger Fajman wrote: ... > But I think it's unlikely that most people will be subscribing > through the use of a List-subscribe header. At 12:49 AM -0400 97/4/16, Joshua D. Baer wrote: >I like both, but if I had to choose at this point I would take List-Post or >List-Archive over List-Subscribe. I see the usefulness of them all, but I >can visualize a "Post to List" button in my Eudora window or a "View List >ArchivesŠ" menu item and would value either more than a "Subscribe" button. Does anyone else agree with me about the importance of including subscribe? Or, am I just so enamoured of my own ideas that I'm ignoring reality? I've ranted (note that Grant without the 'g' is rant ;-) many times before about including subscribe. By sheer virtue of it being the most used list command I think the inclusion of subscribe is very valuable. Personally, I would rank the importance/usefulness of the commands as follows: unsubscribe, help, subscribe, switch to digest, access archives, post to the list, switch from digest to individual messages, contact human admin. I'm not sure where identifying the list name and address fits in to this - but including them would be useful. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 13:23:36 -0400 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: s-ubscribe vs. the rest (was: general report) At 1:15 PM -0400 4/16/97, Rant Neufeld wrote: >Does anyone else agree with me about the importance of including subscribe? >Or, am I just so enamoured of my own ideas that I'm ignoring reality? I agree! People will pass around subscription messages. Invitations using the subscribe header can be sent to your friends. Who says only the list software can make the header? Rob ______________________________________________________ Within Technology, Inc. people process technology Collaborative Technology........Design and Consulting ______________________________________________________ web: http://www.within.com/ phone: +1 412 852-2599 fax: +1 412 852-2435 ______________________________________________________ ---------------------------------------------------------------------- Date: 16 Apr 1997 13:38:07 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: disclosing to the user (was: list-address field) At 2:57 PM -0400 97/4/15, Clarence C. Wong wrote: >The new draft (01) suggests the following guideline for user feedback: > >> For 'mailto' URL based commands, mail client applications should >> provide specialized feedback (such as presenting a dialog or alert), >> instead of the actual command email message, asking for command >> confirmation from the user. The feedback should identify the message >> destination and command within a more descriptive explanation. ... >Thought we wanted to hide this kind of information from the user. (If the >user wants to see it, he reviews the outgoing message.) Some list servers >also use the subject field. So then we mention all this detailed >information, and pretty soon we have some verbiage that looks very similar >to a URL!!! I disagree. If you have the field: List-Unsubscribe: I would recommend an alert message like: Are you sure you want to send a message with the unsubscribe request "unsubscribe somelist" to <(suppressed)@server.com>? It's much more 'human readable', but still discloses the action being taken. It's crucial (for security reasons) that the details be disclosed to the user _every_ time they issue such a command. Imagine if some spam-brained person rigged a message with the header field: List-help: I think it's preferable (although not required) to display a clearly worded alert rather than the mail message because an alert can provide additional context for the user. However, it's important that the user always be able to access the actual message prior to it being sent. At 7:11 PM -0400 97/4/15, Clarence C. Wong wrote: > One of my points is that the MUA >doesn't know where the command is. Yes it does. ^^^^^^^ The whole point of this is to let the MUA know where to send the command (list@foo.bar), what the the command is (help), and where to put the command (Subject). >Should the user care where the list server is? Should he care about what >text is being sent (in the subject, body, or any other header field)? I >thought we were trying to hide these details from the user. Not necessarily. The most important thing we're trying to do is make it so the user can access commands without having to remember or correctly type the details. This doesn't mean we have to hide the details from them. >I think the user should really only be concerned with the command and the >mailing list. The confirmation dialog should present that information in a >clear and simple way. I think they need to see the command address and the actual text of the command, for security reasons. In an ideal and friendly world (spam-free) we'd be able to hide the details and just say "Do you want to unsubscribe from SomeList?" At 8:28 PM -0400 97/4/15, Clarence C. Wong wrote: >The URL should behave the same way it does >now, bringing forth a sendable message. The confirmation dialog should >inform the user what the intended action of this message is. Then, it is >the user's responsibility to review and send/cancel the message. That's a reasonable alternative. Display an alert/dialog describing the intended action "Do you want to subscribe to SomeList <(suppressed)@server.com>? You will begin receiving messages from the list in your email (possibly a large number of messages)." Then, once the user has confirmed it, bring up the actual message constructed from the URL for review. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 13:38:35 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: list-address field At 8:24 AM -0400 97/4/16, Noritoshi Demizu wrote: >the list-address field and the list-post field seem to have different >meaning. Because the list-post field seems to to control users' posting, >the values of the list-address field and the list-post field will be >different when the mailing list is moderated (I'm not sure this is the >case) or the mailing list is only for announcement. That's basically it. >So how about to use the list-post field only when the administrator >wants to control users' posting? I think that only List-Post should describe where postings should be sent. So if a list is moderated, the List-Post may differ from the List-Address. And if the list does not take postings, List-Post may just be a plaintext message stating that it doesn't take posts. List-Address is really just an informational field and should be the address of the list itself (regardless of where posts and commands go) and perhaps the name of the list. E.g., List-Address: somelist@server.com "Some Mailing List" So we have: > case 1: When the subscribers can post freely, List-Address: list-header@arpp.carleton.ca "List Headers Working Group" List-Post: > case 2: When the subscribers are not allowed to post to the list. List-Address: list-header-announce@arpp.carleton.ca List-Post: "This is an announcements only list - no postings." > case 3: When the list is moderated and has another address for the moderator, List-Address: list-header@arpp.carleton.ca List-Post: At 8:24 AM -0400 97/4/16, Noritoshi Demizu wrote: >Of course, we can integrate these two headers by introducing some >schemes like . Nah. Let's keep them separate because they can have different meanings. >But if the >list-address field contains e-mail address only, we can use the field >from scan.form of MH easily. :-) What's MH? >By the way, I also would like to have sequence number in list headers >in addition to the name of mailing list. ... > List-Seq: 200 ... >They also will be very useful when refiling mail automatically and >sorting mail according to sequence numbers. Seems reasonable to standardize that info. I've added it: http://arpp.carleton.ca/listspec/header-fields.html#List-Sequence - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 15:45:16 -0400 From: Marc Horowitz <(suppressed)@cygnus.com> Subject: Re: general report Keith Moore <(suppressed)@cs.utk.edu> writes: >> However, I would like to know if there's interest in one more field: a >> List-Info field which contains a URL that, when referenced, >> produces an object of type text/mailing-list-info, where the latter is >> a complete list of List-* fields for that list. I'm not sure text is an appropriate type. Quoting rfc2046: (1) text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set. Other subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes of "text" thus include any word processor format that can be read without resorting to software that understands the format. In particular, formats that employ embeddded binary formatting information are not considered directly readable. A very simple and portable subtype, "richtext", was defined in RFC 1341, with a further revision in RFC 1896 under the name "enriched". Although the list-* headers are basically human-parsable, I don't think they are within the spirit of this media type. So, which should it be? image, audio, and video are clearly wrong. application also seems wrong (this implies "not directly readable"). I would suggest that additional headers be presented something like this: multipart/separate-list-headers part 1: whatever the body is part 2: message/list-headers, or message/rfc822 The message/list-headers part would contain additional headers (not sure if these "headers" should be in the header or body section of the part). If the complete list is external, use message/external-body to point elsewhere. This scheme is somewhat analagous to multipart/signed and multipart/encrypted. As usual, intelligent mime readers can present this in a more user-friendly fashion. This is a straw-man brainstorm I just came up with, so feel free to rip it to shreds :-) Marc ---------------------------------------------------------------------- Date: 16 Apr 1997 16:46:19 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > I'm not sure text is an appropriate type. Quoting rfc2046: > > Although the list-* headers are basically human-parsable, I don't > think they are within the spirit of this media type. It could either be text/ or application/. Bottom line: If you want user agents that don't "understand" foo/mailing-list-info to display such a file as text, you want it to be a subtype of text. If you don't want them to display the file, you want the content-type to be a subtype of application. > I would suggest > that additional headers be presented something like this: > > multipart/separate-list-headers > part 1: whatever the body is > part 2: message/list-headers, or message/rfc822 It's certainly possible, but I wouldn't want to use this on a regular basis. The whole idea is to provide minimum list information in the message header (where the recipient's UA can easily get to it) along with a simple means of obtaining additional information about the list in a structured form. A URL pointing to a web server that returns the foo/mailing-list-info type seems like a good way to acheive that. You of course could do multipart/whatever and have the second part be a message/external-body that points to a message/list-headers. But that's a lot of baggage with little more functionality than a simple List-Info header and URL. And MUAs are already accustomed to looking in message headers to figure out how to do things like replies. Should they now have to look everywhere in the message body? let's keep it simple. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 17:13:53 -0400 From: Marc Horowitz <(suppressed)@cygnus.com> Subject: Re: general report Keith Moore <(suppressed)@cs.utk.edu> writes: >> > I would suggest >> > that additional headers be presented something like this: >> > >> > multipart/separate-list-headers >> > part 1: whatever the body is >> > part 2: message/list-headers, or message/rfc822 >> >> It's certainly possible, but I wouldn't want to use this on a regular >> basis. The whole idea is to provide minimum list information in the >> message header (where the recipient's UA can easily get to it) along >> with a simple means of obtaining additional information about the list >> in a structured form. A URL pointing to a web server that returns the >> foo/mailing-list-info type seems like a good way to acheive that. >> >> You of course could do multipart/whatever and have the second part be >> a message/external-body that points to a message/list-headers. But >> that's a lot of baggage with little more functionality than a simple >> List-Info header and URL. And MUAs are already accustomed to looking >> in message headers to figure out how to do things like replies. >> Should they now have to look everywhere in the message body? >> >> let's keep it simple. Clarification: I wouldn't suggest that a second body part always be used; that would be complex and inefficient. In the simple case, toss a header or two in the message headers, and be done with it. That's simple. However, when something more complex is desired, MIME already provides a mechanism for telling the MUA to look somewhere else for something. I'd rather not see us define a new standard which uses the rather ad-hoc technique of a url in a header. The generic MIME mechanism is a little bulky, yes, but as readers get more intelligent, and hide this from the user, it won't matter. I guess I have a question of intent here: do you expect that a MUA would follow a list-info url automagically to get the extra headers, or that it would only be done at the request of the user? If the former, I think a MIME structure is preferred; if the latter, a url in a message is ok, since the url could also point to a page with forms, buttons, and other information and structure to help the user along. The argument about MUA's having "to look everywhere in the message body" is a red herring; they only need to look in parts of the appropriate type, which is trivial given what a MIME reader has to do already. Also, procedurally, I don't think any of this (Keith's proposal, mine, or some alternative) should delay the initial draft. It can all be done as follow-up work. Marc ---------------------------------------------------------------------- Date: 16 Apr 1997 17:44:18 -0400 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: Plain text in header fields (was: List-Post) At 6:11 pm 16/4/97, Grant Neufeld wrote: >Plain text will be identified in the List- header fields by enclosing it in >double-quotes: "plain text". No special encoding is required except that >used by the mail transport mechanism (e.g., Quoted Printable). Why reinvent the wheel? rfc822 (p.14) states that text within parentheses () is a comment. So we get: List-Post: (Post only through the web form) List-Post: (No posting on this list - announcements only.) ( :-]) James ---------------------------------------------------------------------- Date: 16 Apr 1997 17:54:39 -0400 From: Jason L Tibbitts III <(suppressed)@hpc.uh.edu> Subject: Re: Plain text in header fields (was: List-Post) >>>>> "JB" == James Berriman <(suppressed)@frutiger.staffs.ac.uk> writes: JB> Why reinvent the wheel? rfc822 (p.14) states that text within JB> parentheses () is a comment. Well, if you want to take that route, everything outside of <> (excepting certain quoting rules) is a comment. JB> List-Post: (Post only through the web form) Just as easily List-Post: Post only through the web form (strict RFC822 compliance requires the route address to come after the comment, though this is kind of a grey area). This reads well, too. - -- Jason L. Tibbitts III - tibbs@uh.edu - 713/743-8684 - 221SR1 System Manager: University of Houston High Performance Computing Center 1994 PC800 "Kuroneko" DoD# 1723 ---------------------------------------------------------------------- Date: 16 Apr 1997 17:59:31 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > Clarification: I wouldn't suggest that a second body part always be > used; that would be complex and inefficient. In the simple case, toss > a header or two in the message headers, and be done with it. That's > simple. However, when something more complex is desired, MIME already > provides a mechanism for telling the MUA to look somewhere else for > something. I'd rather not see us define a new standard which uses the > rather ad-hoc technique of a url in a header. The two aren't mutally exclusive, and to my mind, they have subtly different semantics. The presense of a a List-* header field in a message says something about the message itself -- that it came via a list with certain characteristics. And you can find more information about *the list the message came from* by following the List-Info link. On the other hand, the presense of a foo/mailing-list-info MIME body part in a message doesn't say anything about where the message came from -- it simply provides information about a mailing list. The recipient's UA should never assume that a foo/mailing-list-info attachment means that the message came from a list, or that the attachment refers to the list that the message came from. For example, someone might send mail to the list-managers list, telling them about the list-header list. The message received by subscribers to the list-managers list would contain List-* headers describing the list-managers list. However, the message could also have a foo/mailing-list-info attachment describing the list-header list, to make it easy for people on the list-managers list to subscribe to the list-header list, should they choose to do so. Of course, a single multipart message could contain any number of foo/mailing-list-info body parts. > I guess I have a question of intent here: do you expect that a MUA > would follow a list-info url automagically to get the extra headers, > or that it would only be done at the request of the user? I certainly wouldn't use an MUA that referenced a remote List-Info URL for me every time I read a message from a list. And I think the very common list functions like unsubscribe should always go in the message header rather than being indirected through List-Info. So no, I don't really expect UAs to follow that link automagically. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 19:22:25 -0400 From: (suppressed)@akimbo.com Subject: Re: list-address field >From: josh@skyweyr.com (Joshua D. Baer) >> List-Post: >> (I dont' have good idea about the format of this URL...) > >In this case you just wouldn't include a List-Post header, because posting >is not allowed. I agree with the other comments about why a separate List-Address isn't necessary (given that we've recognized that the Sender header identifies the name of the list). However, the above statement won't work. Right now List-Post isn't even in the proposed core standard so not having a List-Post certainly can't mean posting is not allowed. That's why I previously suggested recognizing List-Post: "message" to mean posting is not allowed. Having syntax in the headers that specifically means a feature is not available is useful and I'm not sure about whether it's a good idea to invent alert: URLs. I suppose alert messages might be useful in other contexts where URLs are normally used, but it is a little weird. --- Bruce Leban Akimbo Systems http://www.akimbo.com/globetrotter Publish on the web without learning HTML! (Really.) ---------------------------------------------------------------------- Date: 16 Apr 1997 20:56:10 -0400 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: Plain text in header fields (was: List-Post) At 01:11 PM 4/16/97 -0400, Grant Neufeld wrote: [snip] >Use of Plain Text [snip] >It may also be useful to combine plain text with the use of meta-syntax >(currently URLs) in the header fields. A possible example of this could be: > List-Post: "Post only through the web form" *HORRIBLE* example!!! Please don't encourage this, even by example. Mailing lists are an email medium. WWW is something else. I can download my email, read it at my leisure, reply to it, and then upload. I can't do that with the WWW, which requires tying up my phone line. Maybe you have a second phone line, or even a dedicated T1, but don't assume the rest of the world does. Please don't even suggest that a mailing list should be configured such that posts must go through a web form. YUCKKK!!! In fact, for that reason, I'd suggest that should be the "preferred" header for any of the List-* headers. Please don't lose sight of the fact this is for *email*, not *www*. Those animals function differently, have different connectivity requirements, and generally require different clients. I want to subscribe, post, read, and unsubscribe to a mailing list all from a mail client. I shouldn't need Netscape to do these things, nor should I need to be on-line when preparing any commands to the list server. One other thing I'd suggest for mail clients (while I'm here) is that they be *strongly* encouraged to permit users to add their own headers before sending those "convenient" messages. In particular, I like: Bcc: myself for such messages (and "myself" might be a different account than the one I'm actually un/subscribing from). Cheers, Stan ---------------------------------------------------------------------- Date: 16 Apr 1997 20:56:48 -0400 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: s-ubscribe vs. the rest (was: general report) At 01:15 PM 4/16/97 -0400, Grant Neufeld wrote: >At 12:40 AM -0400 4/16/97, Roger Fajman wrote: >... >> But I think it's unlikely that most people will be subscribing >> through the use of a List-subscribe header. > >At 12:49 AM -0400 97/4/16, Joshua D. Baer wrote: >>I like both, but if I had to choose at this point I would take List-Post or >>List-Archive over List-Subscribe. I see the usefulness of them all, but I >>can visualize a "Post to List" button in my Eudora window or a "View List >>ArchivesŠ" menu item and would value either more than a "Subscribe" button. > > >Does anyone else agree with me about the importance of including subscribe? >Or, am I just so enamoured of my own ideas that I'm ignoring reality? I don't want to say that you're ignoring reality, but I do think you are overestimating the utility of a subscribe function. In order to use it, you'll have to be (a) not currently subscribed; and (b) in possession of a message from the list you're not subscribed to, with full headers, and (c) want to subscribe. I don't picture this happening very often. (And I don't see any need based on "gee, I'll unsubscribe this week and re-subscribe next week." -- just keep a copy of your original sub message, or use LISTSERV where you can set yourself to NOMAIL and not actually unsubscribe.) Sure, the number of "subscribes" sent on the internet undoubtedly exceed the number of "unsubscribes" -- because mailing lists still exist. I've never been in a position where I could use a subscribe header, but I've often found myself digging around in folders for the place and syntax to send commands *to lists to which I'm already subscribed* -- and I think these are by far the more important functions. I'm not sure that "Post to List" buys much either, except to override a list owner's choice that default replies should go to the sender rather than the list. Hopefully, MLM software which implements that will allow individual list owners to be able to *not* include it. [snip] >I'm not sure where identifying the list name and address fits in to this - >but including them would be useful. It would be nice to have a "standard" header that one could do mail filtering on to uniquely identify a list...at present, the various types of lists I'm on require various tricks (and I still occasionally wind up with a stray post in the inbox when, say, a list has been Bcc'd.) This would be much more useful to me than any "subscribe" header (though if the "subscribe" header were predictable, I could filter on *that*! ) Cheers, Stan ---------------------------------------------------------------------- Date: 16 Apr 1997 20:58:56 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: general report > However, I would like to know if there's interest in one more field: a > List-Info field which contains a URL that, when referenced, > produces an object of type text/mailing-list-info, where the latter is > a complete list of List-* fields for that list. > > So a message from a list might contain three fields: > > List-Unsubscribe: > List-Maintainer: > List-Info: > > and if you look up the latter URL, you'll get back the complete > set of info for that list: > > content-type: text/mailing-list-info [in the http response header] > > List-Subscribe: > List-Unsubscribe: > List-Maintainer: > List-Info: > List-Archive: > > List-Post: > List-Description: this list discusses foos > List-Spam-Policy: let's stamp out spam in our lifetime > > -Keith Sounds like a reasonable idea to me if the user agent developers don't mind the additional complexity. But then I wonder about why there is a need for both ways of doing it if all can be represented with List-info? We usually prefer having one way of doing something instead of two. P.S. - By analogy with the second part of the multipart/report content type, the MIME type for List-info could be message/mailing-list-info. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:07:29 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: How many (which) headers? (was: general report) > The reasons I see for keeping it to just the 3 are as follows: > > - Fewer headers means we're less likely to run into "header bloat" > objections. Basically, trying to be as inoffensive as possible to improve > our chances of making it through the standards process. I remember the discussion about "header bloat" going on, but I've forgotten what the main objection was. Was it the amount that the List-* headers would increase the size of the header section of the average message to a mailing list? Or was it the number of different headers being defined? The List-info proposal addresses the former objection (size of the headers) and the List-function proposal I made yesterday addresses the latter objection (number of different headers). Also, by being overly concerned about one possible objection (header bloat) you may open yourself to objections about inadequate functionality (also expressed here). > Some people have asked: why not just skip headers altogether and just work > on the more comprehensive and flexible alternatives? > > - Various headers of this type are already in use (X-URL, X-Unsubscribe, > etc.) so let's standardize them so they can be useful to client > applications. > > - Header support is relativly easy to implement. > > - Headers don't pose the problems that things like MIME parts do. I like the header proposal better than the MIME part in every message proposal. It's more straightforward and has much less adverse effect on users whose user agents lack support for the feature. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:11:27 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: s-ubscribe vs. the rest (was: general report) > Does anyone else agree with me about the importance of including subscribe? > Or, am I just so enamoured of my own ideas that I'm ignoring reality? I think subscribe is useful. It's just that I disagree with including it while excluding other functions that, in my opinion, will be more useful to the ordinary user. So I just order the list differently that you do. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:18:07 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: general report > The presense of a a List-* header field in a message says something > about the message itself -- that it came via a list with certain > characteristics. And you can find more information about *the list > the message came from* by following the List-Info link. > > On the other hand, the presense of a foo/mailing-list-info MIME body > part in a message doesn't say anything about where the message came > from -- it simply provides information about a mailing list. The > recipient's UA should never assume that a foo/mailing-list-info > attachment means that the message came from a list, or that the > attachment refers to the list that the message came from. This makes a lot of sense to me. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:18:34 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: Plain text in header fields (was: List-Post) > >Plain text will be identified in the List- header fields by enclosing it in > >double-quotes: "plain text". No special encoding is required except that > >used by the mail transport mechanism (e.g., Quoted Printable). > > Why reinvent the wheel? rfc822 (p.14) states that text within parentheses > () is a comment. Comments are to be discarded without other processing. The point of the quoted string is to provide text that can be displayed to the user. I think it's a good idea. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:22:21 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: list-address field > I agree with the other comments about why a separate List-Address isn't > necessary (given that we've recognized that the Sender header identifies > the name of the list). The Sender header doesn't always identify the name of the list. Some list servers set Sender to the address of the list owner. This is arguably more conformant to the definition of Sender in RFC 822. > Having syntax in the headers that specifically means a feature is not > available is useful and I'm not sure about whether it's a good idea to > invent alert: URLs. I suppose alert messages might be useful in other > contexts where URLs are normally used, but it is a little weird. I do remember seeing a proposal for a URL for constant text. But it's probably just an Internet Draft at this point. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:51:47 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: Plain text in header fields (was: List-Post) At 2:40 PM -0700 4/16/97, James Berriman wrote: >Why reinvent the wheel? rfc822 (p.14) states that text within parentheses >() is a comment. > >So we get: > >List-Post: (Post only through the web form) > >List-Post: (No posting on this list - announcements only.) I like this idea -- should work with existing apps as well. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 16 Apr 1997 22:26:04 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: s-ubscribe vs. the rest (was: general report) > People will pass around subscription messages. Invitations using the > subscribe header can be sent to your friends. Who says only the list > software can make the header? no, we don't want to encourage people to send list-subscribe headers to each other in messages that aren't from the list. of course people want to send subscription information to their friends. that's what the foo/mailing-list-info MIME type is for. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 22:35:19 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Plain text in header fields (was: List-Post) > JB> Why reinvent the wheel? rfc822 (p.14) states that text within > JB> parentheses () is a comment. > > Well, if you want to take that route, everything outside of <> (excepting > certain quoting rules) is a comment. Actually, no. The stuff before a bracketed address in a To, From, Cc, whatever field is a 'phrase'. Phrases are part of the message content, and actually have meaning, and can be interpreted by mail reading software. For instance, the phrase preceding an address is supposed to be the name asociated with that address. There are also grammatical constraints on a phrase. Comments, on the other hand, are almost completely arbitrary, and are not intended to be interpreted by mail reading software. It's a subtle distinction, and RFC 822 doesn't explain it very clearly, but that's what's intended. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 22:58:59 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > > I agree with the other comments about why a separate List-Address isn't > > necessary (given that we've recognized that the Sender header identifies > > the name of the list). > > The Sender header doesn't always identify the name of the list. > Some list servers set Sender to the address of the list owner. > This is arguably more conformant to the definition of Sender > in RFC 822. Both practices are also arguably completely against the intent of Sender. Widespread practice to the contrary, it's nearly always inappropriate for lists to supply a Sender field. (The exception that comes to mind is a message digest, and perhaps a moderated list.) Sender is supposed to be the identity of the "AGENT (person, system, or process) that sends the message", as distinct from the From field, which is defined as the "person(s) who wished the message to be sent". The distinction is subtle but important. The examples of Sender in RFC 822 are of messages sent by the Sender *on behalf of* the address(es) in the From field. (one sent by a secretary for his boss, another sent by one member of a group on behalf of the entire group). Another clue to the function of Sender is in the last paragraph of 4.4.2 of RFC 822: Since the critical function served by the "Sender" field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer pro- gram generates a message, the HUMAN who is responsible for that program be referenced as part of the "Sender" field mail- box specification. That is, part of the purpose of Sender is to identify who is *responsible* for sending the message. A third clue is the use of the word "authentic" in the RFC 822 grammar, revealing the intent that the From/Sender fields be "authenticated" to ensure that either the From field correctly identifies the originator, or that the Sender field is present and identifes the originator. For a list that automatically forwards mail to its members, the original submitter of the message, not the list maintainer, bears responsibility for the message. Under most circumstances, the list should NOT discard this information nor hide it from the list recipients. If someone spams a list, they're trespassing on a community, and the list members (the members of the community being spammed) have a right to know who is doing it. Of course, some lists want to support anonymous posting, and those lists will want to hide the Sender field. But unless the list owner is accepting responsibility for material sent to the list (as might be the case in a moderated list), putting the address of the list owner in the Sender field is inconsistent with the purpose of that field. Note that while it's currently easy to forge SMTP messages and thus the Sender field, this can be expected to change. The trend is for SMTP servers to refuse to relay mail that didn't originate locally and isn't for local recipients. There is also increased interest in SMTP authentication and in a special protocol for message submission. All of these will help make the Sender field more reliable. Keith p.s. my suggestion for the list-header effort is: Don't assume any interpretation for Sender or any other part of RFC 822 - that's clearly within the scope of the IETF DRUMS working group, and not within the purview of any other group or document. If you decide you need a header field that identifies the owner or maintainer of a list, define a new field for that purpose. ---------------------------------------------------------------------- Date: 16 Apr 1997 23:06:08 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > Sounds like a reasonable idea to me if the user agent developers don't > mind the additional complexity. But then I wonder about why there is a > need for both ways of doing it if all can be represented with > List-info? We usually prefer having one way of doing something instead > of two. Two things: 1. If the only List-* header field which appears in a message is List-Info, the UA then has to be able to fetch web pages in order to implement an Unsubscribe button. Seems like too much overhead to me. Also, not everyone who reads mail has an on-demand net connection. I'd like for people to be able to compose an unsubscribe message and queue it for later delivery (say from their laptop or their handheld personal organizer), without having to first download a web page. 2. You can think of the List-* message headers as a preloaded cache of the most frequently used fields from the foo/mailing-list-info description of the mailing list. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 23:19:22 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Plain text in header fields (was: List-Post) > Plain text will be identified in the List- header fields by enclosing it in > double-quotes: "plain text". No special encoding is required except that > used by the mail transport mechanism (e.g., Quoted Printable). 1. Quoted-printable is not, in general, used by the mail transport mechanism. Though it is designed to overcome limitations of mail transports, quoted-printable (and other content-transfer-encodings) are intended to be applied by the sender's user agent, and decoded by the recipient's user agent. 2. Quoted-printable encoding does not apply to message headers, only to the contents of messages and body parts. 3. Any proposal to include human readable text that doesn't support I18N will get soundly trounced. And if you want to include something besides ASCII-only text in a List-* field, you need to use RFC 2047 to do this. As RFC 2047's encoded-words are not valid within quoted-strings, you need some other way than quotes to distinguish human readable text. Given that you can just use comments, I'm not sure it's worth the trouble to define a separate mechanism. Also, for List-Post: I think it would be worthwhile to have a special convention that says "you cannot post to the list" rather than trying to include it in a comment. Perhaps this could be indicated by an empty List-Post: field (with no field-body), or by a special keyword, e.g.: List-Post: forbidden Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 23:51:05 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: disclosing to the user (was: list-address field) At 1:37 PM -0400 4/16/97, Grant Neufeld wrote: >At 7:11 PM -0400 97/4/15, Clarence C. Wong wrote: >> One of my points is that the MUA >>doesn't know where the command is. > >Yes it does. > ^^^^^^^ >The whole point of this is to let the MUA know where to send the command >(list@foo.bar), what the the command is (help), and where to put the >command (Subject). > This is rare, but some MLMs use more than one field: From: cwong To: mail-list-admin Subject: somelist subscribe cwong We use such a syntax at Qualcomm (I don't necessarily think it's elegant, but we started out with it a couple years ago and we're stuck with it.) What would the dialog say in this case? ---------------------------------------------------------------------- Date: 17 Apr 1997 00:05:22 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: s-ubscribe vs. the rest (was: general report) At 8:53 PM -0400 4/16/97, Stan Ryckman wrote: >>I'm not sure where identifying the list name and address fits in to this - >>but including them would be useful. > >It would be nice to have a "standard" header that one could do mail >filtering on to uniquely identify a list...at present, the various >types of lists I'm on require various tricks (and I still occasionally >wind up with a stray post in the inbox when, say, a list has been Bcc'd.) >This would be much more useful to me than any "subscribe" header (though >if the "subscribe" header were predictable, I could filter on *that*! ) > This is a very good point. Whenever I subscribe to a list, I create a new mailbox and filter. If the MUA knew the list address, it could automatically do this for the user. The MUA could offer this option within the subscription dialog box. MUAs could also use the list address field to keep track of what lists the user has subscribed to/unsubscribed from; useful for those who are on many lists and subscribe/unsubscribe from them frequently. - -Clarence ---------------------------------------------------------------------- Date: 17 Apr 1997 00:27:22 -0400 From: Jason L Tibbitts III <(suppressed)@hpc.uh.edu> Subject: Re: Plain text in header fields (was: List-Post) >>>>> "KM" == Keith Moore <(suppressed)@cs.utk.edu> writes: KM> Actually, no. The stuff before a bracketed address in a To, From, Cc, KM> whatever field is a 'phrase'. Yes, of course. (I'm painfully aware of the vagaries of RFC822 address syntax.) Actually, the constraints the grammar places on the phrase (especially on periods) probably make it less useful if one intends to follow the constraints of RFC822 when it comes to the non-URL portion of the header. I suppose this really goes to show that trying to mimic RFC822 isn't really a good idea, unless you try to mimic all of the warts as well. That would be pretty much pointless. Doesn't the URL syntax have provisions for textual comments? Is it necessary to come up with a hybrid of two (confusing) standards for this? - J< ---------------------------------------------------------------------- Date: 17 Apr 1997 01:36:18 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: general report > 2. You can think of the List-* message headers as a preloaded cache of > the most frequently used fields from the foo/mailing-list-info > description of the mailing list. > > Keith But if some UAs can't handle List-info, then there's this possibility of inconsistent behavior that has to be explained to users. That's not a good thing, in my opinion. ---------------------------------------------------------------------- Date: 17 Apr 1997 01:40:14 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: Plain text in header fields (was: List-Post) > 3. Any proposal to include human readable text that doesn't support > I18N will get soundly trounced. And if you want to include something > besides ASCII-only text in a List-* field, you need to use RFC 2047 to > do this. As RFC 2047's encoded-words are not valid within > quoted-strings, you need some other way than quotes to distinguish > human readable text. For those who aren't up on the latest shorthand, I18N stands for "internationalization", meaning making Internet protocols friendly to languages other than English. > Given that you can just use comments, I'm not sure it's worth the > trouble to define a separate mechanism. But in other contexts we've been saying that comments should not be processed in any way except to be passed over. > Also, for List-Post: I think it would be worthwhile to have a special > convention that says "you cannot post to the list" rather than trying > to include it in a comment. Perhaps this could be indicated by an > empty List-Post: field (with no field-body), or by a special keyword, > e.g.: > > List-Post: forbidden > > Keith I like this idea, but had hestitated to suggest it before because it seems to add a little more complexity. A word like "unavailable" might be better because it could be used with other List-* headers. ---------------------------------------------------------------------- Date: 17 Apr 1997 01:52:33 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > But if some UAs can't handle List-info, then there's this possibility > of inconsistent behavior that has to be explained to users. That's > not a good thing, in my opinion. we already have some UAs with built-in web browsers and some without. some UAs recognize embedded URLs in messages, some don't. it's not something we can control. Though I am wary of using mailto: URLs when ordinary email addresses will do. If an email address is the only thing that can reasonably go in a List-* field, it should be an email address, not a mailto: URL. Keith ---------------------------------------------------------------------- Date: 17 Apr 1997 02:13:59 -0400 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: list-address field At 10:55 PM 4/16/97 -0400, Keith Moore wrote: >> > I agree with the other comments about why a separate List-Address isn't >> > necessary (given that we've recognized that the Sender header identifies >> > the name of the list). >> >> The Sender header doesn't always identify the name of the list. >> Some list servers set Sender to the address of the list owner. >> This is arguably more conformant to the definition of Sender >> in RFC 822. > >Both practices are also arguably completely against the intent of >Sender. > >Widespread practice to the contrary, it's nearly always inappropriate >for lists to supply a Sender field. (The exception that comes to mind >is a message digest, and perhaps a moderated list.) > >Sender is supposed to be the identity of the "AGENT (person, system, >or process) that sends the message", as distinct from the From field, >which is defined as the "person(s) who wished the message to be sent". >The distinction is subtle but important. The examples of Sender in >RFC 822 are of messages sent by the Sender *on behalf of* the >address(es) in the From field. (one sent by a secretary for his boss, >another sent by one member of a group on behalf of the entire group). I think you're partially correct here. My interpretation is that "Resent-Sender:" is the header that *ought* to be used; one list I'm on does this. It also uses "Resent-Date:", "Resent-Message-Id:", etc. and preserves all the originals. Keep in mind, though, that as I send this, the list *IS* my AGENT in distributing this mail to all of you; it's a system or process indeed distinct from "From:" which does identify me, the person who wished this message to be sent. That program is indeed acting *on behalf of* me when I send this to it. Unfortunately, RFC 822 doesn't stand by itself; some of the examples are broken (e.g., dates); some things it talks about fail in most common implementations (multiple addresses in Reply-To:); some have been replaced by later RFC's (date formats again)... it sure would be nice to have a rewrite of the whole thing, fixed and updated. RFC 822 also seems to have been written in complete ignorance of the concept of mailing lists as we know them today (although maybe such things didn't exist in 1982... I dunno). That's the *real* problem, I think... examples of sending for someone else are of the type of a secretary sending for the boss, and not of a mailing list resending mail to thousands of subscribers. (And I don't even want to get into the problem here of what the heck you're supposed to do with the "Resent-xxxx" headers if mail is resent more than once, but I think the RFC's ought to.) >Another clue to the function of Sender is in the last paragraph of >4.4.2 of RFC 822: > > Since the critical function served by the "Sender" field is > identification of the agent responsible for sending mail and > since computer programs cannot be held accountable for their > behavior, it is strongly recommended that when a computer pro- > gram generates a message, the HUMAN who is responsible for > that program be referenced as part of the "Sender" field mail- > box specification. > >That is, part of the purpose of Sender is to identify who is >*responsible* for sending the message. I think this is OK... what this means to me is that bounces need to wind up in the "correct" place. This does *NOT* mean that the Sender: is responsible for the content, just for the sending action, and needs to be the person to handle errors in the delivery process should they occur. They (bounces) should *NOT* go to the From: address, but rather to the (Resent-)Sender: address. It does not matter if this is called "owner-listname@wherever.com". This does generally identify a human, whose identity may change even though the address remains constant. I read that paragraph as saying basically, "mail loops are bad things... it should go to Sender and stay there." >A third clue is the use of the word "authentic" in the RFC 822 >grammar, revealing the intent that the From/Sender fields be >"authenticated" to ensure that either the From field correctly >identifies the originator, or that the Sender field is present and >identifes the originator. This means little... who "authenticates?" A little loophole now being grossly exploited by spammers. >For a list that automatically forwards mail to its members, the >original submitter of the message, not the list maintainer, bears >responsibility for the message. Under most circumstances, the list >should NOT discard this information nor hide it from the list >recipients. If I had my druthers, I'd replace that "should" with "MUST". Note, LISTSERV offers subscribers the *option* of shorter headers, including the origination information being stripped, which is OK by me, but lists which do it perforce annoy me. *THIS* list is guilty of that; it fudges things so that everything appears to originate from "void.achilles.net". Check the headers. >If someone spams a list, they're trespassing on a >community, and the list members (the members of the community being >spammed) have a right to know who is doing it. Agreed. If someone spams *this* list, I'd like the header information to go after the spammer *without* having to count on the list owner doing it, even if those headers are logged somewhere. Right now, not possible. >Of course, some lists >want to support anonymous posting, and those lists will want to hide >the Sender field. But unless the list owner is accepting >responsibility for material sent to the list (as might be the case in >a moderated list), putting the address of the list owner in the Sender >field is inconsistent with the purpose of that field. I don't read it as "Sender" accepting any responsibility for content, just for collecting bounces. The RFC example of a secretary mailing for the boss would bear that out, I think. However, "Resent-Sender:" would probably be best, at least if a "Sender:" was already present in the headers. Consider: To: all@unlucky.com From: big-boss-man@unlucky.com Sender: poor-secretary@unlucky.com Subject: You're all fired!! Boss wrote content, secretary just did the sending. To whom should you complain about the content? Cheers, Stan ---------------------------------------------------------------------- Date: 17 Apr 1997 02:53:03 -0400 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: Plain text in header fields (was: List-Post) At 01:33 AM 4/17/97 EDT, Roger Fajman wrote: [snip] >> Also, for List-Post: I think it would be worthwhile to have a special >> convention that says "you cannot post to the list" rather than trying >> to include it in a comment. Perhaps this could be indicated by an >> empty List-Post: field (with no field-body), or by a special keyword, >> e.g.: >> >> List-Post: forbidden >> >> Keith > >I like this idea, but had hestitated to suggest it before because >it seems to add a little more complexity. A word like "unavailable" >might be better because it could be used with other List-* headers. Why not just?: List-Post: NO Simplest special keyword I can think of for this! :-) It's probably multipurpose and can be used with other List-* headers as well. It's understandable in reading the headers, and the mail client can translate it to "This list will not accept posts" if desired. Cheers, Stan ---------------------------------------------------------------------- Date: 17 Apr 1997 03:29:42 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > >Widespread practice to the contrary, it's nearly always inappropriate > >for lists to supply a Sender field. (The exception that comes to mind > >is a message digest, and perhaps a moderated list.) > > > >Sender is supposed to be the identity of the "AGENT (person, system, > >or process) that sends the message", as distinct from the From field, > >which is defined as the "person(s) who wished the message to be sent". > >The distinction is subtle but important. The examples of Sender in > >RFC 822 are of messages sent by the Sender *on behalf of* the > >address(es) in the From field. (one sent by a secretary for his boss, > >another sent by one member of a group on behalf of the entire group). > > I think you're partially correct here. My interpretation is that > "Resent-Sender:" is the header that *ought* to be used; one list I'm > on does this. It also uses "Resent-Date:", "Resent-Message-Id:", etc. > and preserves all the originals. 822 really botched the definition of the Resent-* field. I believe that DRUMS has decided that Resent-* is best reserved for *manual* resending for those rare cases where a message needs to be manually forwarded to an alternate recipient with the original message headers intact. (The most common use of resend is probably to forward a misdirected message to some sort of mail robot. Another possible use would be for a moderated list -- the list moderator could approve a new submission by "resend-ing" the message to the list.) > Keep in mind, though, that as I send this, the list *IS* my AGENT > in distributing this mail to all of you; it's a system or process > indeed distinct from "From:" which does identify me, the person > who wished this message to be sent. That program is indeed acting > *on behalf of* me when I send this to it. Yes, but the same argument would apply to every MTA in the signal path. "Sender" is clearly intended to indicate the original sender; someone/something who can accept responsibility for the message being sent; a cause, not an effect. The "AGENT" language makes more sense in the context of a message generated by an automatic process (say a cron job) which generates the message without explicit human direction. > Unfortunately, RFC 822 doesn't stand by itself; some of the examples > are broken (e.g., dates); yes, but the definition is clear > some things it talks about fail in most > common implementations (multiple addresses in Reply-To:); Really? Every Internet UA I've ever used can handle multiple addresses in reply-to. The only things I know of that break here are gateways from the Internet to dysfunctional mail systems. Mailers that can't handle multiple reply-to addresses are simply broken, and that's no fault of RFC 822. > some have > been replaced by later RFC's (date formats again)... it sure would be > nice to have a rewrite of the whole thing, fixed and updated. That's precisely what the DRUMS WG is doing. See http://www.ietf.org/html.charters/drums-charter.html > RFC 822 also seems to have been written in complete ignorance of the > concept of mailing lists as we know them today (although maybe > such things didn't exist in 1982... I dunno). Yes, such things did exist. (Seems like the sf-lovers list started somewhere around 1980.) But they were relatively new, and I agree that RFC 822 doesn't seem to benefit from a mature understanding of lists. > (And I don't even want to get into the problem here of what the heck > you're supposed to do with the "Resent-xxxx" headers if mail is > resent more than once, but I thi