autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Handling spam on gnu.org mailing lists


From: Greg A. Woods
Subject: Re: Handling spam on gnu.org mailing lists
Date: Sat, 7 Apr 2001 23:45:24 -0400 (EDT)

[ On , April 7, 2001 at 17:10:34 (-0700), Russ Allbery wrote: ]
> Subject: Handling spam on gnu.org mailing lists
>
> I think the gnu.org -bug lists should be open to all comers.  -bug lists
> are by nature high-noise, and people who can't deal with a bit of spam
> aren't going to be able to deal with the truckloads of poorly specified
> and mostly unusable bug reports either.

That makes absolutely no sense whatsoever.

Bug reports, good or bad (well except maybe those sent from within Emacs
as the poor helpless lusers try to figure out how to exit :-), are
always relevant to the community.

Spam is never welcome nor ever relevant to the community (by definition!).

The dilema of course is that one cannot have one without the other.  If
blocks are implemented at the SMTP level(*) then you cannot easily allow
all messages from any authorised subscriber regardless of whether or not
the subscriber's MTA would otherwise be blocked.  (Not to mention the
confusion amongst MLMs in how posters are authenticated and authorised
-- not all of them use the SMTP envelope sender address as an
authentication token.)

In the end though it only helps to block messages from even subscribers
if their MTAs happen to become insecure or otherwise abused by spammers.
I.e. it does not hurt the community as a whole to block messages from
subscribers should their MTA become insecure.  One way or anther
pressure must be put on all postmasters of all open relays and all spam
havens to clean up their acts and to stamp out spam!  Action at a
community level is one certain way to put such pressure on irresponsible
postmasters.

(*) the SMTP level is the only really effective place for implementing
blocks since it's the only way one can avoid actually having to take
responsibility for the message (and thus avoid having to trust a forged
sender address) and yet at the same time return a hopefully useful
message to the sender indicating the reason for the refusal and perhaps
providing pointers to how the block can be cleared.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]