LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
David Boyes <[log in to unmask]>
Sun, 9 Jul 1995 14:13:03 -0500
text/plain (47 lines)
> Now, my question is: can you setup a site-wide filter
 
Yes. Revised LISTSERV allows the postmaster/maintainer of a
specific site to refuse service to any address, including
blocking entire sites if necessary (the SERVE command does accept
wildcards, eg *@AOL.COM or *@penet.finet.fi). It's not often
done, and in some other people's opinion, never done wisely, but it's
very effective in most cases.
 
> share this information with each other, and so the site-wide delete can
> be followed with site-wide filtering at all the major sites - and basically
> take care of the bogus subscribers quickly and efficiently.
 
This has always gone on informally, however the problem is with
propagation delay -- the filtering information list propagates at
the same rate as the bozo posting/spam, and is usually after the
fact, so the damage has already been done. This is the essential
problem with the current spam detector -- aside from an
occasional false positive, the information can't pass from server
to server fast enough to prevent some of the spam postings from
going out unchecked. In some ways, it might make sense to abandon
NJE connnectivity for LISTSERV completely and add a process that
maintains a live TCP connection to all the DISTRIBUTE backbone
servers to do out-of-band notification like this.
 
> This idea applies to net-wide deletes as well as net-wide filtering;
> done informally with a mailing list.  And any site that was uncomfortable
> with the net-wide effect could elect not to be on the mailing list.
 
To be effective, it would have to be global in scope -- the weak
link in the chain theory would apply with a vengeance here. Also,
the security for invoking something like this would have to be
pretty serious in order to avoid malicious use -- perhaps some
sort of one-time password scheme generated by the originating
server and a dual query-response approach for the credentials
required for the user. Denial-of-service attacks would be a
significant problem here.
 
> be done carefully.  And there are considerations for how such things
> 'scale up', as Eric likes to remind us.   But it happens infrquently
> enough that it ought to be manageeable.
 
Realistically, as the unwashed masses get net access, it's only
going to get worse. Stopping it now is essential, while the
problem is relatively small. In a year, it's not going to be a
small problem any more.

ATOM RSS1 RSS2