Re: ADMIN: Re: OT How do I unsubscribe?

["Sandy Harris" <sharris -at- dkl -dot- com>]

Iain Harrison wrote:
 
> > If I wanted to unsubscribe, I'd mail techwr-l-request -at- raycomm -dot- com
> > the one-line message "unsubscribe". To unsubscribe from techcomm,
> > I'd mail techcomm-request.
> >
> > I'd be quite upset if those didn't work.

They would, Eric tells me.
 
> That's a spectacularly silly way to approach it! What's wrong with
> following the simple instruction in the footer?

The point is there is a standard way to unsubscribe from lists.

For example, if you go to PAML, the Publicly Available Mailing Lists
reference server, their "getting off" document:

http://www.neosoft.com/internet/paml/gettingoff.html

gives the following suggestions in order:

	Save the welcome message and follow instructions there.
	Read list headers and footers and ...
	<listname>-request@
	listserv@, listproc@, listserver@, majordomo@, ...
	...

> > This has been an oral tradition standard since before I started
> > using mailing lists, i.e. at least 15 years.

> Well, I'd expect a command to listserve@ to be the standard, not
> listname-request -at-  -dot- 

No. Many sites run majordomo and accept commands to majordomo@ and
many run some other software. 

> Techcomm is hosted for free, so we can't tell the host to amend his
> (perfectly adequate) mailing list server. I think it is a standard NT
> mail server, but I'm not sure.

I'd consider any list software that didn't support -request broken.
 
> As you point out, the RFC you refer to is not agreed (I personally
> hope it never is) so it has no import.

It is on the IETF standards track, which means it is quite likely
to become a standard more-or-less as it stands and some descendant
of it, possibly modified, is almost certain to.

In IETF terms:

Things start as "internet drafts" and get kicked around a lot.

"Proposed Standard" means the relevant committees have agreed on the
design, and the area directors decided it should be published, and
that both think it should aim at being a standard, not just an
"informational" or "experimental" RFC.

Before it can advance to "Draft Standard", at least two unrelated
implementations must be built and their compatibility tested.

For the final standard, any major problems discovered in implementation or testing must be fixed.