List-Header Digest Archive: May 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: Plain text in header fields (was: List-Post) by Jacob Palme <(suppressed)@dsv.su.se> -> Re: Plain text in header fields (was: List-Post) by Jacob Palme <(suppressed)@dsv.su.se> -> Re: s-ubscribe vs. the rest (was: general report) by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: s-ubscribe vs. the rest (was: 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: s-ubscribe vs. the rest (was: general report) by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: How many (which) headers? by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: How many (which) headers? by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> (listspec) Back again, newly unimproved by Grant Neufeld <(suppressed)@achilles.net> -> Digest Formats (was: How many (which) headers?) by Grant Neufeld <(suppressed)@achilles.net> -> Re: list-address field by Grant Neufeld <(suppressed)@achilles.net> -> Command confirmations (was: How many (which) headers?) by Grant Neufeld <(suppressed)@achilles.net> -> Other uses for the list-headers by Grant Neufeld <(suppressed)@achilles.net> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: Other uses for the list-headers by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: Other uses for the list-headers by (suppressed)@akimbo.com -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by Grant Neufeld <(suppressed)@achilles.net> -> Re: Other uses for the list-headers by Grant Neufeld <(suppressed)@achilles.net> -> Re: Other uses for the list-headers by "Bob Hartman" <(suppressed)@esoft.com> ---------------------------------------------------------------------- Date: 2 May 1997 09:48:27 -0400 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: Plain text in header fields (was: List-Post) >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" The IETF e-mail standard way of doing this is to use parenthesises, not quotes. I.e. your example should be formatted the following way: List-Post: )Post only through the web form) - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 4 May 1997 13:53:44 -0400 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: Plain text in header fields (was: List-Post) Sorry for the misspelling, here is the correct syntax (how I long for the time when "Supersedes" is generally implemented in e-mail): The IETF e-mail standard way of doing this is to use parenthesises, not quotes. I.e. your example should be formatted the following way: List-Post: (Post only through the web form) - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 14 May 1997 12:29:32 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: s-ubscribe vs. the rest (was: general report) >I don't want to say that you're ignoring reality, but I do think you are >overestimating the utility of a subscribe function. I just saw this posting and wanted to comment. Since I placed a List-Subscribe header into my messages as a test, it has allowed for an easier subscribe. If someone wants to subscribe, someone on the list will send them a copy of one of the messages to see if they want to join (i.e. look at the message, do they like it, can they stand the volume). If the answer is yes, they have a handy URL that they can use to subscribe, and I don't have to worry about them complaining to postmaster because their friend told them to subscribe to mylist-1 and it says the list doesn't exist. just my opinion, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 14 May 1997 12:33:09 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> 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.) This is somewhat up in the air for me. Sender is supposed to be the person originating the message into the mail system. Now, is the mailing list software considered a user agent acting on behalf of the end user and is an endpoing, or is it a part of the mail system? For me, the line is kind of fuzzy, so I am finding it hard to decide. If it is a UA, then it should probable set the Sender field to itself, and can play around with the message. If it is part of the server itself, then it shouldn't touch the message at all. regards, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 14 May 1997 12:36:26 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: s-ubscribe vs. the rest (was: general report) >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. Same here... I don't know how out of scope this is, but how would we handle the case where we use an IMAP server as a mail store and want to have mail automatically sorted? The problem is that the subscription requestion should be simple (i.e. for us, it becomes "body=subscribe mylist-l FirstName LastName" ) but there may be a need for us to specify a header that would allow for a specific mailbox (for us, "body=subscribe mylist-l FN LN"). regards, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 14 May 1997 12:48:09 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: How many (which) headers? At 03:16 PM 4/18/97 -0400, you wrote: >At 2:14 PM -0400 4/18/97, Grant Neufeld wrote: > >> Frankly, I now think it may be appropriate to add to the current draft some >> or all of Post, Archive, Digest-On, Digest-Off, Address, and Human-Admin. > >I like Post, Archive, Digest, Address, and Owner. List-Owner is better >than List-Human-Admin because its shorter, easier to read, and is already >in use as a term for most MLMs. > >Do most lists have separate commands for Digest-Off and Subscribe? Most >lists I've been on allow you to change from Digest to Normal subscription >by resending a subscribe command. If possible on most servers, only having >one header would be much simpler/nicer. I know a number of lists where you simply send a message to the listserver to change your 'status' from digested to non-digested. There are also a number where you subscribe to a digested or non-digested list specifically. We should come up with some method that deals with both, say: List-Subscribe and List-Subscribe-Digest and List-Digest and List-NoDigest You would simply have the listserver broadcast which ones you supported and ignore the others. (well, ignore list-subscribe-digest) regards, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 14 May 1997 12:50:43 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: How many (which) headers? At 04:44 PM 4/18/97 -0400, you wrote: >> Frankly, I now think it may be appropriate to add to the current draft some >> or all of Post, Archive, Digest-On, Digest-Off, Address, and >> Human-Admin. > >Post: agreed >Archive: agreed >Digest-*: bad idea. too many variant behaviors >Address: if you have List-Post, what's the point? it's confusing at best. >Human-Admin: agreed On the digest idea, do the variant behaviours fall into a finitely small set of classes that we can enumerate them? I would like to know what the variants are before I make a decision. (I thought there were only 2 to be honest) regards, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 14 May 1997 19:41:16 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > This is somewhat up in the air for me. Sender is supposed to > be the person originating the message into the mail system. Now, > is the mailing list software considered a user agent acting on > behalf of the end user and is an endpoing, or is it a part of > the mail system? Clearly, the subscribrs of a mailing list would like to be able to know both the original sender of the message to that list, and the address of the list itself. If the list stomps on Sender, it can only supply the latter. If the list leaves Sender as-is and puts its own address in the List-address (or whatever) header, the original Sender remains intact. Seems like a no-brainer to me. Add to that the advantage that a List-address header will be well defined, while various list server programs use Sender in slightly different ways. Keith ---------------------------------------------------------------------- Date: 16 May 1997 15:15:52 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: (listspec) Back again, newly unimproved My apologies for seemingly dropping off the side of the planet - a number of things led to my setting the list-header project aside for a while. I'm going over the backlog of messages I haven't dealt with (or replied to). Hopefully I'll get caught up over the next few days. I'm working on the revised draft: http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-01.txt - -- "Don't blaim me - I'm a parasite." grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 May 1997 15:16:52 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Digest Formats (was: How many (which) headers?) At 8:50 PM -0400 97/4/18, Richard Stevenson wrote: >This gives you three possibilities for >Digest-on: one for MIME digests, one for the older kind (as used on this >list), and one for the default, or "I don't care." As more MLMs support >MIME digests, this is likely to become more of an issue. Perhaps another field "List-Digest-MIME" is in order? http://arpp.carleton.ca/listspec/header-fields.html#List-Digest-MIME At 9:15 PM -0400 97/4/18, Jason L Tibbitts III wrote: >But the problem is still there, and >Majordomo 2.0 will have the possibility of more than two digests per list. >Some of this can be settled by saying that the list owner can choose which >defaults are reasonable. You will not be able to solve the problem >entirely, at least not in the space of a single header. Right, which is why the List-Digest field should probably just point to the 'default' digest format for the list and leave it at that. Anything more advanced will require the list specification MIME object (or whatever we end up defining to describe more detailed list command syntax). At 10:14 PM -0400 97/4/18, Keith Moore wrote: >> Switching to digest mode is one of the more frequently requested options, >> so it would seem to be a good candidate for inclusion. > >Most lists don't have a digest mode; some of those that do have > digest mode don't offer you the choice of non-digest mode. Then those lists wouldn't include the List-Digest field. >Some lists require you to unsubscribe from one list and subscribe > to a different list. These aren't easily accomodated > by a List-Digest-* field. This could be handled two ways (depending on the commands required). - - Stacking of commands as in: List-Digest:

so that the client issues two commands when the user selects digest. - - Where the server supports multiple commands in the same message, you just have to put a newline (CRLF) between the commands in the mailto: List-Digest: >I think of List-Digest-* as being of marginal value, close to the >point of diminishing returns (or perhaps past that point). Before I implemented digest support on my server, the biggest source of listmom traffic I had was requests for digest mode. I see it having a lot of value. >Sophisticated lists have lots of other per-recipient flags besides >"digest", should we define commands for those also? Yes. The question is which (if any) of them to include in the header fields - - we should try to support all of them in the MIME object (or whatever). >At what point do we give up trying to list all of the commands >that someone might want to use, and start trying to define a standard >command set? (Then you could just have "List-command-set: RFC2345") When you can get the religious wars on standard-syntax to settle down enough. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 May 1997 15:17:02 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: list-address field At 9:51 PM -0400 97/4/18, Keith Moore wrote: >> >Why is >> >List-Address different from List-Post? > >> Because you don't necessarily post to the list-address. > >Then why do we need a List-Address? To serve as a unique identifier for the list. The questions I'm trying to answer with those two fields are: - - Where do you send messages for posting to the list? - - What is the unique identifier for the list? - - What is a human readable identifier (name - not address) for the list? As I may have said before, List-Identity might be a more descriptive label for List-Address, but I still like the idea of having a well-defined way to identify the address of the list - for probably the same reasons that a number of lists have (wrongly?) chosen to use Sender for the list address. At 11:47 PM -0400 97/4/18, Clarence C. Wong wrote: >To help manage mailing lists better, the MUA could use the list address for >three things: > >1- As part of the confirmation dialog, informing the user that the intended >action is to subscribe (or unsubscribe) from this list. (e.g. Are you sure >you want to subscribe to "some-list@host.com?") >2- When subscribing to lists, the MUA could automatically (as an option) >create filters and mailboxes for the user. >3- MUAs could keep track of lists users have subscribed to or unsubscribed >from. People who go on vacation often unsubscribe to a bunch of lists and >then resubscribe later on. At 12:34 AM -0400 97/4/19, Keith Moore wrote: >Although none of the things you listed require an email address, >*all* of the things you listed work just fine using a List-Post address. No. Consider: List-Post: moderator@foo.bar List-Address: "Foo Forever" With the List-Address field: the confirmation dialog can say "Are you sure you want to subscribe to 'Foo Forever'?". This is information which provides value to the user. As has been pointed out, List-Post can also be used to indicate that posting is not allowed on a given list: List-Post: NO (or whatever keyword ends up being defined for this) At 8:15 PM -0400 97/4/20, Joshua D. Baer wrote: >I still don't understand what is meant by "the address of the list". If >it's not the posting address, what is it used for? The address messages come from; usually the same as the posting address. Moderated lists may use a separate posting address. At 2:23 PM -0400 97/4/21, Clarence C. Wong wrote: >>At 11:47 PM -0400 4/18/97, Clarence C. Wong wrote: >>> 1- As part of the confirmation dialog, informing the user that the intended >>> action is to subscribe (or unsubscribe) from this list. (e.g. Are you sure >>> you want to subscribe to "some-list@host.com?") > >Grant and others have argued that this warning message should be a summary >of the outgoing message. I'd prefer it to be more user friendly, by >explicitly informing the user the NAME of the list they're about to >subscribe to. The name _in addition to_ the command details. To preserve security, it's crucial that the user always be shown what they are sending out (until such time as systems for establishing trust and authentication are implemented - probably in about 100 years). >When the user clicks on subscribe button (or selects the menu item), how >does the MUA know what information to filter on for the newly subscribed >list? There's nothing in the three core headers. And as stated before, >list-post and list-address could be different for moderated lists. Good point. However, this is contingent on the List-Address field being present in every message from the list (which it should be if it was in the message the user used to subscribe). - -- "Never eat more than you can lift." - Miss Piggy grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 May 1997 15:17:10 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Command confirmations (was: How many (which) headers?) At 11:47 PM -0400 97/4/18, Clarence C. Wong wrote: >By the way, has there been any talk of a list-confirmation field? I think that qualifies a separate project. It would be useful to have a standard format for command confirmation messages so that the process can be made easier for the end user. Since I don't even have enough time for the List- headers, I'll leave that one to someone else. - -- "I, for one, welcome our new insect overlords, and would like to remind them that as a trusted tv personality, I can be helpful in rounding up others to toil in their underground sugar caves." - Kent Brockman grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 May 1997 15:26:27 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Other uses for the list-headers It occurred to me tonight, as I was reviewing my bounced mail digests, that the list headers could potentially be used to automatically unsubscribe users whose accounts are defunct. So, if user@foo.bar is subscribed to list@host.x and the user account is terminated: when the mailer @foo.bar receives a message for user@foo.bar from list@host.x , they could use the value of the List-Unsubscribe field to tell list@host.x to unsubscribe user@foo.bar. There are some notable security problems with this, based on the current definition of the headers and on the totally unauthenticated nature of smtp mail at present - but this may eventually become feasible. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 May 1997 22:17:27 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: list-address field At 3:13 PM -0400 5/16/97, Grant Neufeld wrote: > At 9:51 PM -0400 97/4/18, Keith Moore wrote: > >> >Why is > >> >List-Address different from List-Post? > > > >> Because you don't necessarily post to the list-address. > > > >Then why do we need a List-Address? > > To serve as a unique identifier for the list. Why do we need this? Isn't the posting address a unique identifier? Isn't this redundant? > At 12:34 AM -0400 97/4/19, Keith Moore wrote: > >Although none of the things you listed require an email address, > >*all* of the things you listed work just fine using a List-Post address. > > No. Consider: > > List-Post: moderator@foo.bar > List-Address: "Foo Forever" > > With the List-Address field: the confirmation dialog can say "Are you sure > you want to subscribe to 'Foo Forever'?". This is information which > provides value to the user. I do NOT think this is great value to the user. The important piece of information is the email address, not the name. The name is nice, but not crucial (and IMO beyond the scope of this project). > As has been pointed out, List-Post can also be used to indicate that > posting is not allowed on a given list: > > List-Post: NO > (or whatever keyword ends up being defined for this) So what the heck would a list-address be used for if there is no posting allowed? > At 8:15 PM -0400 97/4/20, Joshua D. Baer wrote: > >I still don't understand what is meant by "the address of the list". If > >it's not the posting address, what is it used for? > > The address messages come from; usually the same as the posting address. > Moderated lists may use a separate posting address. Uh, ok then... why would I ever care what the "address messages come from" is if I don't ever use it? I don't send commands to it, I don't send posts to it, what the heck is it for? Bounce messages? Why is this relevant? I feel pig-headed, because I still cannot seem find one USEFUL reason for a list-address field. The only valid suggestion (although of low importance to me) was so that the free form name could be displayed in dialogs, but this would be more appropriately addressed by a List-ID or just List-Name header which did NOT include ANY addressing information. List-Address makes absolutely no sense. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 16 May 1997 22:17:48 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Other uses for the list-headers At 3:27 PM -0400 5/16/97, Grant Neufeld wrote: > It occurred to me tonight, as I was reviewing my bounced mail digests, that > the list headers could potentially be used to automatically unsubscribe > users whose accounts are defunct. > > So, if user@foo.bar is subscribed to list@host.x and the user account is > terminated: when the mailer @foo.bar receives a message for user@foo.bar > from list@host.x , they could use the value of the List-Unsubscribe field > to tell list@host.x to unsubscribe user@foo.bar. > > There are some notable security problems with this, based on the current > definition of the headers and on the totally unauthenticated nature of smtp > mail at present - but this may eventually become feasible. Oooh! I like this! SMTP servers could unsubscribe bad addresses automatically! The security risk is minimal, since servers would likely be configured to only try to unsubscribe addresses served by that domain. Therefore, it would NEVER unsubscribe a valid address. We should talk to mail server developers about this kind of support. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 17 May 1997 00:48:31 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: list-address field >Uh, ok then... why would I ever care what the "address messages come from" >is if I don't ever use it? I don't send commands to it, I don't send posts >to it, what the heck is it for? Bounce messages? Why is this relevant? > >I feel pig-headed, because I still cannot seem find one USEFUL reason for a >list-address field. The only valid suggestion (although of low importance >to me) was so that the free form name could be displayed in dialogs, but >this would be more appropriately addressed by a List-ID or just List-Name >header which did NOT include ANY addressing information. List-Address >makes absolutely no sense. You may not find it useful, but your MUA might. There are quite a lot of things that I think MUAs should be doing to better manage mailing lists. Your MUA could offer the option of automatically filtering all messages from the list-header@arpp.carleton.ca mailing list into the list-header mailbox. It may also use this field to keep track of what lists you've subscribed to and unsubscribed from. - -Clarence ---------------------------------------------------------------------- Date: 17 May 1997 12:34:38 -0400 From: (suppressed)@akimbo.com Subject: Re: Other uses for the list-headers >So, if user@foo.bar is subscribed to list@host.x and the user account is >terminated: when the mailer @foo.bar receives a message for user@foo.bar >from list@host.x , they could use the value of the List-Unsubscribe field >to tell list@host.x to unsubscribe user@foo.bar. This is a good idea. Some tweaks: 1) Mailer software could also switch someone to digest mode when their mailbox gets full if the incoming mail has a List-Digest header. 2) If a mailer is unsubscribing someone it includes extra headers which may or may not be recognized by the list software: List-Request-From-Postmaster: [reason] List-Request-Postmaster-Address: List-Request-Expires: [date] where [reason] is something like "defunct account" or "mailbox full". This info could be saved and logged by the mail software so if a user is getting mysteriously unsubscribed they know why it's happening. The postmaster address is so that if the list owner thinks they're getting bogus unsubscribes, they know who to write to. The final thing is if the mail host unsubscribes someone because of an overflowed mailbox it wouldn't want to do it permanently. I suggest using headers here so list software because putting it in the body won't work with some existing software. ---------------------------------------------------------------------- Date: 17 May 1997 13:32:24 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: list-address field At 12:43 AM -0400 5/17/97, Clarence C. Wong wrote: > You may not find it useful, but your MUA might. There are quite a lot of > things that I think MUAs should be doing to better manage mailing lists. > Your MUA could offer the option of automatically filtering all messages > from the list-header@arpp.carleton.ca mailing list into the list-header > mailbox. It may also use this field to keep track of what lists you've > subscribed to and unsubscribed from. All valid points, couldn't this all be accomplished better and less-ambiguously using List-Post or List-Name? ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 19 May 1997 13:55:14 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: list-address field At 9:59 PM -0400 97/5/16, Joshua D. Baer wrote: >Why do we need this? Isn't the posting address a unique identifier? Isn't >this redundant? ... and others have been expressing similar questioning. So, let's leave List-Address out of the headers for now (at least until a convincing argument in its favor is established). The issue of list identification remains. In the long term (and as a project parallel to, but seperate from, this one) it would be beneficial to have a system of defining unique identifiers for lists, but not tied to a given address (since lists may change addresses, but still be the same list). In the mean time, perhaps the 'List-Name' field which has been suggested here would be an acceptable compromise. Personally, I don't favor it. My inclination would be to go with an extensible 'List-Identity' (although a clearer name for the field could hopefully be found). List-Identity: ""[; <>[; ]] - -- "Don't blaim me - I'm a parasite." grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 19 May 1997 13:55:39 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: Other uses for the list-headers At 10:01 PM -0400 97/5/16, Joshua D. Baer wrote: >At 3:27 PM -0400 5/16/97, Grant Neufeld wrote: > > >> It occurred to me tonight, as I was reviewing my bounced mail digests, that >> the list headers could potentially be used to automatically unsubscribe >> users whose accounts are defunct. ... >Oooh! I like this! SMTP servers could unsubscribe bad addresses >automatically! The security risk is minimal, since servers would likely be >configured to only try to unsubscribe addresses served by that domain. >Therefore, it would NEVER unsubscribe a valid address. That's not the security risk I was thinking about - the security risk is in servers executing commands arbitrarily defined in non-authenticated messages. I think there needs to be either a standard unsubscribe command message, or authenticated email transactions, before this is considered a safe method. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 20 May 1997 02:33:56 -0400 From: "Bob Hartman" <(suppressed)@esoft.com> Subject: Re: Other uses for the list-headers On 16 May 97 at 22:01, Joshua D. Baer wrote: > > It occurred to me tonight, as I was reviewing my bounced mail digests, that > > the list headers could potentially be used to automatically unsubscribe > > users whose accounts are defunct. > > > > So, if user@foo.bar is subscribed to list@host.x and the user account is > > terminated: when the mailer @foo.bar receives a message for user@foo.bar > > from list@host.x , they could use the value of the List-Unsubscribe field > > to tell list@host.x to unsubscribe user@foo.bar. > Oooh! I like this! SMTP servers could unsubscribe bad addresses > automatically! The security risk is minimal, since servers would > likely be configured to only try to unsubscribe addresses served by > that domain. Therefore, it would NEVER unsubscribe a valid address. > > We should talk to mail server developers about this kind of support. I've been lurking in this discussion for some time. I'll be writing a list server application for my company's Internet Protocol Adapter (IPAD) for the next revision. I'm going to include whatever I can from this project, since it seems very nice for the user. I also agree that automatically unsubscribing is a REALLY nice feature. Unfortunately, I do see a security problem with it. If I receive a message for a user in my domain that I no longer have listed (ie, they have been removed), if I just blindly send the unsubscribe data, someone could have sent a bogus message that would really be causing me to send a subscribe message to a huge mailing list, or worse yet, a junk message to a spam generator or something similar. Since there is no way to authenticate that the user was really a member of the list, there is no good way to do the unsubscribe automatically without having the possibility of it causing problems. ============== Bob Hartman ----====+====---- eSoft, Inc. ============== bob.hartman@esoft.com Voice: (303)699-6565 BBS: (303)699-8222 Setting up an Internet presence shouldn't fray your nerves. Point your web browser to http://www.esoft.com and find out how eSoft's Internet Protocol Adapter (IPAD) can put your business on the Internet quickly and easily. Put the power of the Internet into your business! ======================================================================= ---------------------------------------------------------------------- End of Digest