On Mon, 12 May 2003, Manuel Kasper wrote:
> > So if the impending move of the lists was the reason not to bother setting
> > up the "Reply-To:", that's no longer an issue. :-) Right now it's
> > necessary to edit the address manually when replying to a post.
> Yes, and that will stay this way because I read this:
Not accessible right now (DNS failure).
> and found that they're right - I can live with the fact that people have
> to think twice before posting anything to the list. :) Besides, other
> lists behave in the same way, too (including soekris-tech and
> freebsd-small), and every better MUA has got a "Reply All" function, so
> that issue is settled as far as I'm concerned.
I've been using *many* mailing lists for *many* years (as well as
administering a couple myself), and it's always been considered
appropriate to point the Reply-To at the list. After all, the point of a
"discussion" list is to "discuss". :-) Sure, there's an occasional
dissenter, but the overwhelming majority prefers not to do extra work in
the most common case (replying to the list).
In the present setup, one is offered two options:
1) Reply to the originator *only*.
2) Reply to the list *and* the originator, causing the originator to get
two copies (unless one manually removes the redundant address).
With the Reply-To included, one then gets three options:
1) Reply to the list *only* (including the originator *once* via the
2) Reply to the originator *only*.
3) Reply to both.
I fail to see how the latter setup is inferior. In fact, I thought that
was so obvious that I assumed the omission of the Reply-To was just an
oversight, not a deliberate choice.
Based on what I saw looking at the archives, omitting the Reply-To on the
Soekris list doesn't seem to discourage posting enough to keep it from
being a high-traffic list. :-)
> OK, you've got a point there. But all those commercial boxes don't throw
> you in a shell prompt without any help and with most of the common UNIX
> commands missing. If someone (possibly me if I found the time ;) were to
Wanna bet? :-)
SnapGear treats the manual as some sort of state secret, not publishing it
on their website, and not even being very willing to send you a copy when
asked. You have to talk to a sales rep just to find out that the
capability exists, since they don't include it in the published feature
list (they almost lost at least one sale by hiding that). There are no
man pages, and the way you find out what commands exist is to do "ls
/bin". The commands aren't even identical to what you find on other
systems, since it uses ucLinux on a ColdFire (no MMU). BTW, they do
include "tip", so it's possible to Telnet into the box and then connect to
a serial port (though "tip" has too many transparency problems to run
EMacs (or even Kermit!)).
Alcatel at least makes their "CLI Manual" available for download, though
they don't include it with the modem.
In the m0n0wall case, the FreeBSD man pages are available online where
anyone with a browser and a net connection can read them, so you're
already ahead of SnapGear. :-)
> write a more or less user-friendly console frontend to those diagnostics
> functions with a simple menu like the serial console menu, I'd agree to
> having console access. Or the existing console menu could simply be
Making them "user-friendly" would most likely cost flexibility, though.
If you're really paranoid about someone getting confused by a shell
prompt, then it might be better just to make it an unadvertised option in
the console menu. As far as Telnet/SSH goes, in general someone
knowledgeable enough to use that kind of access in the first place should
be expected to know what to do once they're there. Even SnapGear has
Telnet access enabled by default; they just don't tell you what to do with