procmail
[Top] [All Lists]

Re: Mailing list problem

1997-11-10 20:58:00
At 06:55 PM 11/10/97 -0700, William McClatchie wrote:

[snip - recommendation to filter known-sourced mail, then save remainder
for later processing]

True.  However, she is willing to risk this since in a 48 hour period this
idiocy generated close to 1M of unwanted email. Definately unnacceptable
and extremely hard to go through to find random good things. And since
her ISP charges for exceeding the quota - storing it until free isn't an
option. 

Have you tried piping the messages through gzip?  On the recipe delivery
line where you'd normally be tossing it into a folder do this instead:

|/bin/gzip -9fc >> $MAILDIR/checkme.gz

(path to gzip as appropriate, and make sure you have it too)

This will compress each message as it comes in (and since most are TEXT, it
does a fine job - MIME, OTOH is one of the best ways to mailbomb someone
since it doesn't compress well - but the indirect bombing via mailing lists
doesn't do this), reducing the disk space required, usually dramatically.
Done in conjunction with something like the following at the end of your
.procmailrc, you could have a header file you could quickly rummage through
looking for valid messages to add to a procmail recipe, then run:

        gzip -d -c checkme.gz | formail -s procmail -m recipe.rc

(note that if the recipe delivers into the checkme.gz file on any
condition, then you should look to MOVE the file before running this
process, and use the moved version.  In fact, this would be a good idea
anyway, as newly delivered mail may appear in the end of the gzip file
while you're doing this - and since your ultimate goal is to be able to
eliminate junk, you'll want to know that after you've processed a gzipped
mail file, you can delete it without accidentally whacking new mail).

# If not handled already.  You might add to this a condition checking to see
# if the message has certain list characteristics.
:0
* LASTFOLDER ?? ^^^^
{
        # Save the message in case we need to retrieve it.
        :0c:
        |gzip -9fc >> $MAILDIR/checkme.gz

        # copy headers for easy browsing - including being able to identify
        # lists you're being subscribed to.
        :0h
        checkme.log
}

<general musing>
Personally, I'd like to see more lists implement an "X-Subscription-Info:"
type header - containing an email address for un/subscribe, or a URL with
said info.  Imagine the reduction in bozo messages asking how to unsub...
</musing>

In the long haul, your best bet with dealing with this problem is to stamp
out the offender - bring this harrassment to the attention of their ISP and
get their account closed.  Repeat as necessary.  Most of the mailing lists
should have some record of the submission request.  Even if forged, the
abuser probably has their IP address in the headers somewhere (and if the
person is actively subscribing your friend to so many lists and actually
WORKING at covering their tracks, apparently you've REALLY crossed them).
Most people who stoop to these immature harrassment tactics aren't bright
enough to fully cover their tracks.

Another alternative to having to manually deal with unsubs on certain lists
is once you've identified filterable characteristics of the lists, BOUNCE
them.  Most semi-intelligent listserv implementations will unsub you if
they get repeated bounces.  Yea, not nice to the listserv maintainer - but
then, if perhaps they'd implement a subscription verification system, it
wouldn't have been a problem to begin with.

:0
* some_listmatching_condition
{
        #may expose your .forward - but if you're bouncing lists, it probably
        #doesn't matter much.
        EXITCODE=67

        # save header for examination.
        :0 h
        bounce.log
}


You've got a sticky situation.  You can't simply ditch all unrecognized
mail - you need to be able to review potential refuse first, and take
action on anything which doesn't belong (because you certainly don't want
to continue getting the non-wanted lists till the end of eternity - you
should want to unsubscribe from them to simplify your mail).

---
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.

 Sean B. Straw / Professional Software Engineering
 Post Box 2395 / San Rafael, CA  94912-2395

<Prev in Thread] Current Thread [Next in Thread>