>
> Does anybody think that we ought to line up and seriously bomb
> candid cams?
> I imagine with the collective bandwidth we have on this group we
> could take
> turns, say two a day for a month, and bring this spam shooting
> loser to his
> sorry knees. I will start on Monday from our backup t-1, I will scan his
> network and spend the rest of the day sending malformed packets
> to any live
> host I can find.
>
> Advice to the Wise!
>
> NEVER, NEVER SPAM A LIST FULL OF ISP's, SYSADMIN's, and OTHER IP
> WISE TYPES,
> IT IS STUPID!
>
> -V
Not only would this be illegal, but wouldn't it be stooping to his level? I
say we ignore the post and work with Ipswitch to improve the list server
software to better filter this type of garbage. I host a rather large
assortment of mailing lists all based on IMail and have been speaking with
Ipswitch on and off since November regarding upgrading the Listserv
capabilities. Recently I have had a very nice conversation with their lead
programmer regarding this and I think we can all hope for some improvements
very soon (Thank you!!!)
I think this event perfectly illistrates the weakness of the IMail
listserv--there is no way to filter this garbage out if a spammer takes the
extra step of actually subscribing to the list (which this individual
evidently did).
Here is a list of suggestions I made recently for upgrading the listserv
capabilities. Can anyone else think of any others that I might have missed?
- Administrator should be able to sub or unsub individuals via email without
listserv intrepreting command as a request to unsub/sub administrator.
Current method of requiring alias accounts is not really workable because
many people having trouble do not send subscribe requests that can be
forwarded and parsed. They require a manual subscription, which in turn
does not automatically send that person a subscribe notice.
- Would like to see auto-confirmations/authentications of subscription
requests. But not when a list admin subs someone via email. Not sure if
this matters at all, but right now IMail throws an error if there is any
other text in body of email when someone subscribes. Even a single > causes
an error (no such list).
- Deny all attachments to a list. Innumerable times we receive complaints
of list attachments. Although you can turn these off (non-text attachements
only) in digest mode, we need a way to deny attachements of any kind to mail
or digest mode.
- Administration of all list settings via email. Would like to be able to
have distributed list admins set commands/settings for their list directly
from email. Would be a time saver over having to visit the list admin site
for every list, but would like to also retain the abililty to configure
lists via the panel as well. It might be hard to do this with the various
text files (header, trailer, subscribe, etc..) so I guess just stick with
the other settings. If you can figure a way to update/modify the text files
through email I highly recommend it.
- would like to send auto-confirmations/authentications of unsubs. But not
when a list admin unsubs someone.
- Automatically remove indivuals for bounced posts. Remove people
automatically if account has been closed or domain not found. Remove people
after a predetermined number of bounces (set by admin) when mailboxes are
full.
- ARCHIVE!!!! Need a text based archive BAD! Posts should be parsed on a
nightly or predetermined basis (set by admin) to be archived as text files.
You could perhaps look at something along the lines of MHonArc.. try adding
it to your cgi suite.
- People placed in Kill file should not receive kill notices (unauthorized
poster) sent as a result of post.
- Subscription requests sent to private lists automatically forwarded to
list owner, who can then subscribe them via email, or ignored.
- Some form of twit mode. "twit mode" is a rather useful tool to use on
those bothersome people who always seem to stir up trouble on a list.
Setting twit mode would allow them to post to a list, but ONLY they would
see their post... just like setting ignore in IRC, except that it's set for
everyone on the list. The individual has no idea that they are not being
seen by anyone else and believes that they are simply being ignored.
Eventually they go away. It's perhaps a more PC way of dealing with
troublemakers than putting them in a kill list.
- Enable complete disablement of the list command. By this I mean
individuals should not be able to retrieve a list of the lists hosted via
the mail server.
- Automatic alphabatizing of lists, subscribers, etc...
- Would like lists to post subjects at the beginning of each digest. By
this I mean the posts comprising a digest should be parsed and their
subjects added in sequential order at the top of every digest. Also old
digest directories should be deleted after digests have been sent and all
posts archived... see archive request.
- Would like to see some "throttling" capability added that would limit
customers ability to send more than an arbitrary number of messages in a
given hour. The arbitrary number should be set by the mail admin. Also,
might think about including a day variable so the list admin can set up a
probationary period where users could not send over a number of posts to the
list for a number of days.
- Improved moderation capability. By this I mean I would like posts to be
scanned for phrases or words and have those posts held while letting others
through without a moderator having to approve every post him/herself. I'm
basically talking about foul language, or urls which point to adult sites...
something along this line.
In further discussion between Ipswitch we came up with one additional
improvement:
- Open Private List - open for all to subscribe, but only those with the
password can post? I think that sort of flexibility would be useful for
virtual board meetings conducted through email. Members of an association
could subscribe, and listen in on the conversation, but not post on the
list.
Another suggestion was recommended to me this morning as well.
- Adding ODBC support for mail list archiving, which would allow some really
neat app server archiving capabilities.
-----
Anthony
