Re: majordomo

At 21:58 2001-11-14 -0500, Paul Chvostek wrote:
> I know.  I've been launching /usr/local/bin/wrapper from a recipe
> for some time now.  The question was whether it is *wise*,
It is only un-wise if you implement filters in a haphazard manner (I am not 
suggesting this is the case, but merely that is the only real 
concern).  Majordomo is merely a program recipient of the mail - in MANY 
ways, it is indiferent from how one might invoke procmail from a .forward 
file...
> and if anyone had come up with recipes to watch inbound messages to
> avoid having majordomo process junk mail.
Nothing specifically for that.  But as I previously stated, the _SAME_ 
rules you'd apply to regular mail would apply there.  Try any one of the 
several anti-spam procmail kits there exist already.
> I simply removed the alias, then created a ~majordom/.procmailrc with:
>
>  :0
>  |/usr/local/majordomo/wrapper majordomo
Ah, well this works ok for the majordomo administrative address -- the 
individual lists have several parameters which need to be passed, and thus, 
that escaping the quoted original parameter allows you to pass the 
majordomo stuff as $1 to the procmail script, which is much easier than 
maintaining several separate scripts, or messing with a home directory for 
each list...
> > Ditch spam before it gets into majordomo.  That's not the purpose of the
> > filter set I just implemented for an associate (running several large
> > international mailing lists), but pretty much the same principles which
> > apply to filtering your own mailbox would apply there
>
> So I take it you don't have specific recommendations, then?
Well, if you want to put it that way.  No, nothing specific - I'm not 
writing your filter, and I'm not using procmail to do what you're trying to 
accomplish.  I'd be mildly surprised if many others are actually using 
procmail in conjunction with majordomo - not that it's a novel concept.
Virtually all of the recommendations which apply in this forum for regular 
spam filtering should apply for pre-filtering something bound for a mailing 
list processor - such as I mention above, using a canned anti-spam 
package.  The message is like any other, with the exception that the 
envelope sender has been changed (if it has an owner-listname alias at least).
> Actually, it's not even that.  I'm trying to block messages to MAJORDOMO,
> not messages to the lists.
Your original message did not make this clear - "majordomo" is a list 
processor, and without specifying that you're processing only the primary 
administrative address, it would be taken to assume the whole lot of 
majordomo lists on a server.
> Here's what I came up with, but I want feedback on it before I put it
> into production.
Suggestion: change the majordomo alias, like so:

majordomo:              "|/usr/local/majordomo/wrapper majordomo",testuser


With 'testuser' being where you place your testing version of the majordomo 
procmail filters.
You can test your filters on live traffic for a while without impacting the 
real majordomo processing (yes, this means you don't have to fake up 
messages to test with - they arrive 'naturally').  When you're comfortable 
with your filters, having had an opportunity to fine tune them according to 
the messages you may have tripped up on during testing, you can set it up 
as the actual majordomo preprocessor.
(Of course, at the back end of your test filters, you shouldn't actually 
pass the message into majordomo, just emit to the logfile that this is what 
you would have done, then throw away the message -- just as you shouldn't 
bounce things to senders from the test message -- just log what your action 
would have been, or if you really feel like it, bounce it to a monitoring 
mailbox).
>  # transferred from aliases.majordomo...
>  :0
>  * ^TO_majordom(_at_)it(_dot_)ca
>  ! majordomo-owner
I presume you're saying "send me a copy of everything anyway, even if it's 
spam" ?
>  # places where majordomo might get mail
>
> MYDOMAINS="((it|cuic|microlab|actionnow)\.ca|(int|canadian|actionnow)\.org|it-mail\.net|ca-unlimited.com)"
You missed an escaped dot, as if it matters.

>  # filter by recipient
>  :0:
>  * ! ^TO_(_at_)${MYDOMAINS}
>  spamtrap
Uhm, read 'man procmailrc' on ^TO_ (and ^TO) -- that'll catch X-Envelope 
and Apparently-To headers (which may or may not exist in your case, but if 
they do, they'll exist on any message which the majordomo 
receives).  Simply put, you should do fine checking for a cleartext'd 
recipient:
* ! ^To:(_dot_)*majordomo(_at_)${MYDOMAINS}

Because there's inherently no legit reason someone should be CC'ing or 
BCC'ing commands to majordomo.  People deliberatley mail it to send a 
command.  Granted, cc and bcc work currently, since majordomo doesn't care 
how it was addressed so long as it was invoked, but the point is, ask 
yourself why anyone would cc or bcc majordomo (perhaps they'd be sending a 
command to it and copying to themselves for reference, but swapping 
addresses -- to: themselves, cc: majordomo (weird way to do things, but 
some users have been known to do weird things) - you could still handle 
that by just putting in a standard or construct on the header  ^(To|Cc): -- 
but bcc, WHY would anyone think of bcc'ing a list?  On my own lists, I 
specifically ditch messages where the list is receiving a Bcc'd message, 
because either it is a crosspost (someone mailing multiple lists, or a 
bunch of friends AND a list - either way, I don't want them -- but that's 
on a LIST, not the listprocessor address), or it's spam.  Requiring a 
cleartexed recipient (preferrably only as To:) should ditch a lot of spam 
for you.
>  # filter by content (approximately)
>  :0 B:
>  * !    ^[      ]*(end|\
>         (un)?subscribe|\
>         (new)?(info|intro)|\
>         (new|write)?config|\
>         signoff|cancel|approve|passwd|which|who|\
>         mkdigest|lists|help|get|index|auth)
>  spamtrap
Uhm, what about the possibility that these keywords might appear in the 
SUBJECT?
>  # hand it to majordomo
>  :0
>  |/usr/local/majordomo/wrapper majordomo
>
> Anybody see any problems with it?  Is it safe to assume that any
> legitimate email for majordomo will contain at least one majordomo
> command in the body?
That's a judgement call - if someone sends a blank message (which may still 
include their .sig, so empty body isn't a valid definition for "blank"), 
they might expect to recieve a help response (which majordomo won't give 
them - but then it'd at least RESPOND).  As written, these people will get 
shuttled into the spamtrap...
---
 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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail