[lug] List status?
wallen at boulder.nist.gov
Wed Jun 28 14:20:54 MDT 2000
On Fri, 23 Jun 2000, David wrote:
> This is a problem that I have run foul of. It is easy to subscribe to
> this list and then not be able to unsubscribe. That is the condition
> under which I am subscribed at present; when I next want to change any
> of my options I shall have to ask Wayde to do it for me.
> 1. Have a machine at home, an ISP, and dynamic IP addresses; i.e., the
> plainest, simplest, cheapest, connection.
> 2. Travel at little bit so that you find that a net-based
> re-directable address (NBRD) seems like a good idea. You go
> somewhere, you send your mail somewhere; you change your ISP, you
> send your mail to the new ISP. Provided that the net-based
> service provider does not go under (impossible !), or some such,
> it is a very nice system because the people who contact you need
> not know that you move, and you still can use all of the
> advantages of having your mail fielded by someone else - your home
> machine is turned off (otherwise you use .forward). You do need
> to make sure that the Reply-to field is set to NBRD when you send
> out stuff, or else it goes somewhere, which may, or may not, work.
> 3. From home, crank up Linux and the browser, and contact the BLUG
> software and tell it that you would like to subscribe and that
> your address is NBRD - which is the address that everyone gets
> from you, of course. Note that this message is transmitted to the
> network from ISP, not NBRD.
> 4. The request is accepted and you start receiving all the stuff.
> 5. One day, months later, you decide to post a listing yourself, or
> to change an option, or unsubscribe. You get a rejection because
> you are transmitting from ISP, not NBRD.
I'm not exactly sure how I should, respond to this. First of all, you
should be able to unsubscribe yourself from any address you've subscribed.
The new system uses the subscription address and a password to provide
subscribe/unsubscribe authentication. It doesn't care what computer you
do it from. This is different, and I think better, than the old majordomo
listserver that only allows you to make changes from the address that you
originally subscribed from. With the older software, what you say above
would have been more true.
The difficulty that you seem to be having has to do with the way you are
treating the redirect-able addressing. This particular e-mail was sent
with a "from:" address of dajo at frii.com. I believe that you expect your
e-mail to be sent to you at dajo at a-vip.com. To this end you usually set
your "Reply-To" header to the dajo at a-vip.com address. This creates an
ambiguity in your header. Should the system allow posting from
dajo at frii.com from where the message appears to originate or should it
make the assumption that the message is really from the dajo at a-vip.com?
Remember that the idea here is simply to prevent unwanted spam postings.
Yes, we do get those by the way. If we choose to allow anything with a
reply-to header of dajo at a-vip.com through then we also are allowing
reply-to: dajo at a-vip.com
through too. As such, the list chooses to allow postings only from
recognized sources, as opposed to recognized return destinations.
To the best of my knowledge the mailman server (what we are using know)
treats the reply-to line the same as all of the other servers we've used
(majordomo and smart-list). You also should be aware that many mail
clients will also fail to recognize your "reply-to" header. Why not
simply set the "from:" header to the address you want to use and be done
with it? That is what most everyone else does.
Also, since the system allows you to turn off mail delivery options you
can subscribe any number of valid addresses for posting purposes and just
receive posts at one. The older majordomo software didn't allow for this.
> The BLUG software violates my first maxim of software construction:
> "Software should not become confused simply because the user is confused."
Ahem! I assume you've heard the old "garbage in, garbage out" phrase? I
know of NO software, or person for that matter, that can read the users
(wallen at boulder.nist.gov)
More information about the LUG