procmail
[Top] [All Lists]

Re: unsubscribe

2010-03-10 21:06:50
At 02:20 2010-03-11 +0100, Michelle Konzack wrote:
Am 2010-03-10 09:15:25, schrieb Professional Software Engineering:
> Same goes for digest replies (either by
> Subject line, or bloated bodies), etc.  S:N is greatly improved, and
> the listadmin has a lot less to deal with.

How do you deal with this?  Can you share scripts or such?

They're pretty large at the moment, and deployed on only two sites - on my own servers, and on the system where the automotive lists are. I did not, nor do I currently, have the time to draft up the more complete documentation necessary to make it a package which could easily be employed by others. One of those "eventually" projects. The filters have been in service for near 10 years now, with periodic tweaks.

I use "courier-mlm" and "procmail" and it begins the same way...

The list site is using sendmail, majordomo, and procmail. I call the front-end "seneschal" which itself is more or less a synonym to majordomo. Where majordomo is invoked via sendmail aliases, the seneschal stuff basically wraps around it:

listname: "|/usr/bin/procmail -m /etc/procmailrcs/seneschal/seneschal.rc \"/etc/majordomo/wrapper resend -l listname -h host.domain.tld -C /etc/majordomo/majordomo.cf listname-out\" listname"

The listname-owner alias invokes a similar construct, providing a bounce-management preprocessor which identifies nonmember submissions, spam, truncates digest bounces (why should the listadmin have to suffer), and making an effort to categorize the nature of the various bounces - MBFULL, CONFIGPROB, HARDBOUNCE (unknown addresses, etc). Also able to selectively filter out repetative bounces coming from some sources for a short period (like the dreaded "5 day" bounce - someone's domain goes off the air, and while an admin can purge the subscriber, there's still all the PRIOR messages sitting in the queue that will continue to retry and eventually bounce - while best to deal with this at the MTA level, it's a bit more involved to purge individual recipients from a queue without affecting delivery to the other held-up recipients).

Various recipes are defined within separate files, and depend upon list-specific configurations (so different listadmins on the same system can "participate" with different filters - there's no provision for listadmins to tweak the settings themselves, but at least it's broken out to the separate lists and not an all-or-none affair).

I am thinking on deactivating the DIGEST stuff.  This idiots send realy
respond with ONE line and attach a 100 kByte DIGEST!  And, they are not
only Windows-Users.

#---------------------------------------------------------------
# digest.rc
#
# DOMAIN GENERIC

# Define the filter ID
FILTER_ID="DIGEST"

# A script to identify and handle digest reposts.

# this rule checks the subject for a digest type subject heading
# and bounces the message back to the submitter instructing them
# to properly copy the subject from the message to which they are
# replying (prefixed with "Re: " if it isn't already).
# an alternative identification method (not implemented at present)
# would be to count the number of occrrences of "Subject:", "Date:"
# and "From:" lines within the body of the message, and it it exceeds
# a threshold, it would be deemed a digest repost.

:0
* $ FILTER_OPTIONS ?? [         ]$FILTER_ID\>
* ! ^FROM_MAILER
* ^Subject:.*digest V[0-9]+ #[0-9]+
{
        BOUNCEMSG="digest.msg"
        BOUNCESUBJ="Digest message posting"

        # Include bounce handler code
        INCLUDERC=bouncer.rc
}

#---------------------------------------------------------------

I have other filters in place for identifying an abundance of quoted lines (referred to as "bloat"): add up points for quoted content, subtract points for new (unquoted) content, along with an allowance, and ignore blank lines.

As the above recipe should indicate, I have a generic include that handles sending the bounce messages (which may also send an advisory to the listadmin).

---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail

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