ezmlm: Thread: early thoughts


[<<] [<] Page 1 of 1 [>] [>>]
Subject: early thoughts
From: Paul Fox ####@####.####
Date: 23 Dec 1996 22:42:36 -0000
Message-Id: <812.851380595@foxharp.boston.ma.us>

[ i guess the first copy of this was lost... ]

hello -- i'm going to react to several things regarding ezmlm as a user.  i
haven't fetched the package source (if available, even), so i'm just a
subscriber, not an administrator.

    - why not use a "list-request" address, with commands in subject or
	body?  that's a model that's been around for quite a while.  i see
	that the list-request address works, but doesn't _do_ anything. 
	frustrating as a user to have to learn yet another mailing list
	command model.

    - i tried to subscribe "pgf-ezmlm" to this list, but ezmlm didn't take
	the "Reply-to" field that i used.  i know there are other ways of
	forcing the "From:" to be set, but as a user, don't really want to
	have to learn it.

    - i hope subject lines are planned for mail from the list automaton.
	even a single fixed subject of "Subject: mailing list information"
	would be preferable to none.

    - semantic nit:  when i unsubscribed, the Acknowledgement message
	wasn't completely clear that yes, i had been subscribed, and yes, i
	was now no longer.  all it said was "this address is not a
	subscriber" which could either mean an error or success, depending
	on the _previous_ state of that address.

    - what's the '-dsn' address that admin requests come from?  it's a
	non-obvious acronym.

all that being said, i'm looking forward to seeing how ezmlm progresses...

paul
---------------------
    paul fox, ####@####.#### (arlington, ma)


Subject: Re: early thoughts
From: "D. J. Bernstein" ####@####.####
Date: 23 Dec 1996 23:56:32 -0000
Message-Id: <19961223235632.24342.qmail@koobera.math.uic.edu>

> - why not use a "list-request" address, with commands in subject or body?

Because that model is a pain for users and consequently for list
managers. See http://library.ummed.edu/~naleks/mlmfaq/mlmfaq_15.html or
the majordomo mailing list.

> - semantic nit:  when i unsubscribed, the Acknowledgement message
> wasn't completely clear that yes, i had been subscribed, and yes, i
> was now no longer.

It'd be no problem generating separate messages for the two cases. The
problem is that the messages may be wrong. After ezmlm-manage changes
the subscriber list, it might find that qmail-queue is out of disk space
for the acknowledgment message. When it tries again, the subscriber list
will already have been changed, so it'll produce an incorrect message.
Keeping track of dead-but-not-acknowledged subscribers would mean extra
I/O. Resurrecting dead-but-not-acknowledged subscribers would be just as
much pain to code and wouldn't be reliable.

> - what's the '-dsn' address that admin requests come from?

``Delivery status notification'' is a catch-all term for bounce
messages, warning messages, and success messages. Perhaps
djb-ezmlm-return would be more comprehensible. I thought about using
djb-ezmlm-trash, but users might be worried at seeing messages coming
from the trash.

---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html

Subject: Re: early thoughts
From: Paul Fox ####@####.####
Date: 24 Dec 1996 00:19:27 -0000
Message-Id: <2114.851386407@foxharp.boston.ma.us>

 > > - why not use a "list-request" address, with commands in subject or body?
 > 
 > Because that model is a pain for users and consequently for list
 > managers. See http://library.ummed.edu/~naleks/mlmfaq/mlmfaq_15.html or
 > the majordomo mailing list.
well, my read of the mlmfaq makes it look like ezmlm has provided yet
another ad-hoc non-standard solution to the problem.  it mentions that
several of the major list servers are beginning to use "list-request", and
that the excessive header or preamble problem is well-solved by a
"commands-start-here" line.  i also don't see that providing that
functionality would be incompatible with also providing the ezmlm separate
address model.

 > 
 > > - semantic nit:  when i unsubscribed, the Acknowledgement message
 > > wasn't completely clear that yes, i had been subscribed, and yes, i
 > > was now no longer.
 > 
 > It'd be no problem generating separate messages for the two cases. The
 > problem is that the messages may be wrong. After ezmlm-manage changes
 > the subscriber list, it might find that qmail-queue is out of disk space
 > for the acknowledgment message. When it tries again, the subscriber list
 > will already have been changed, so it'll produce an incorrect message.
it sounds like the "just unsubscribed" message could be generated correctly
most of the time, and the "not a subscriber" (the current ambiguous one)
message could be used in all other cases.

 > Keeping track of dead-but-not-acknowledged subscribers would mean extra
 > I/O. Resurrecting dead-but-not-acknowledged subscribers would be just as
 > much pain to code and wouldn't be reliable.
don't bother -- send the ambiguous message in that case.

 > 
 > ``Delivery status notification'' is a catch-all term for bounce
 > messages, warning messages, and success messages. Perhaps
 > djb-ezmlm-return would be more comprehensible. I thought about using
i think so, or perhaps djb-exmlm-acknowledgement.  unless we're trying to
conserve bandwidth.  ;-)

paul
---------------------
    paul fox, ####@####.#### (arlington, ma)


Subject: Re: early thoughts
From: "D. J. Bernstein" ####@####.####
Date: 24 Dec 1996 02:31:28 -0000
Message-Id: <19961224023128.25855.qmail@koobera.math.uic.edu>

> it mentions that
> several of the major list servers are beginning to use "list-request",

And several aren't. Anyway, telling users to contact list-request is
easy; telling them _what to say_ is not. Messages are regularly
malformed, misinterpreted, and rejected. The list manager suffers.

> it sounds like the "just unsubscribed" message could be generated correctly
> most of the time, and the "not a subscriber" (the current ambiguous one)
> message could be used in all other cases.

Good point. I'll split the message.

---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html

Subject: Re: early thoughts
From: Paul Fox ####@####.####
Date: 24 Dec 1996 04:04:15 -0000
Message-Id: <6282.851399896@foxharp.boston.ma.us>

 > And several aren't. Anyway, telling users to contact list-request is
 > easy; telling them _what to say_ is not. Messages are regularly
 > malformed, misinterpreted, and rejected. The list manager suffers.

i think i need semantic clarification:  is "list manager" a person, or
is it the program?  programs don't suffer, people suffer.  i don't understand
how the list-manager-person ever suffers from malformed requests -- they
just get rejected.  i can believe the _user_ suffers, but that's not what
you said.

i guess i would submit that the separate address scheme makes
telling them "what to say" more difficult, rather than less.  the 
'"-request" plus commands' metaphor has been here for a while.
and as you said, telling users to contact -request is easy.  and then
they get a help message, and/or get subscribed by default (a great feature
of qlist, imho).

btw, i figured out what the other list server i've used that honors
Reply-to was -- it's a ListSTAR server (from StarNine).

paul
---------------------
    paul fox, ####@####.#### (arlington, ma)


Subject: Re: early thoughts
From: "D. J. Bernstein" ####@####.####
Date: 24 Dec 1996 09:44:28 -0000
Message-Id: <19961224094428.29979.qmail@koobera.math.uic.edu>

> i don't understand
> how the list-manager-person ever suffers from malformed requests

The most direct way is that the user, after bumbling around for a while,
writes to list-owner to complain. (``How do I subscribe?'')

The second most direct way is that the user, after bumbling around for a
while, has the brilliant new idea of sending his request to the mailing
list. (``Can someone get me off this mailing list!!!!'')

> i can believe the _user_ suffers, but that's not what you said.

Users, damn them, refuse to suffer alone. :-)

> and as you said, telling users to contact -request is easy.

Right. And telling them to contact -subscribe is just as easy, with the
virtue that miscellaneous text in their .sig won't be misinterpreted.

---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.21.