List Security

As no doubt almost everyone on the list is aware, we have an annoying
individual ( who has been causing mischief on the
list. Since this is not the first time he has done so I have taken the
liberty of banning his e-mail address (he removed himself from the list
shortly after sending these messages). Of course, there is nothing I can do
should he choose to sign up for another free e-mail address. However, on
the forgery point I would note:

(1) It is possible to forge e-mail in a fairly trivial fashion, but unless
you are really good at it, there are tell-tale signs that it is a forgery.

(2) It is trivial to forge someone’s information via the web interface. The
text in the Lyris documentation is pretty clear on this:

"When a member joins using the web interface, ListManager can ask the person
to pick a personal password. A personal password is useful for mailing lists
where security is important. If no password is defined for a user, then
other people can enter the web interface as that person by typing in their
email address. Requiring each user to have a personal password adds
considerable security to your mailing list. "

I have increased the security setting to require a password. I would
strongly suggest that everyone on the list set a password so that their
identities cannot be easily forged via the web interface.

(3) I have tried to add passwords for those users that appear to have been
abused by this individual today. The list membership is considerably larger
than that, however, so I’d strongly suggest that EVERYONE set a password for
their account. To set your own password you send an e-mail to saying:

set pw=

If you don’t know what your password is, send an e-mail to saying:

query ntdev

These steps should minimize the chance that this will occur again, but I
hope that everyone understands that the e-mail we use today was invented in
a kinder, gentler world where everyone knew everyone else. Those churlish
enough to play games like this were ostracized. We’re still using the same
basic system, but with people who love to cause problems.

As Mark Roddy points out, the best thing to do is to ignore them to the
extent possible - I’m not ignoring them, I’m trying to make this behavior
more difficult in the future, without dismantling the list or making it
essentially unusable.


Assistant NTDEV/NTFSD ListSlave