Jason Gunthorpe <email@example.com> writes:
> I know our listmasters are fairly busy, I *really* urge someone to write
> up a script that can implement this. I'd envision it being fairly simple,
> runnable as a pipe from procmail and return OK, DROP or DEFER. The mailer
> queue can be used to hold and retry the message for a fair time. This
> would drop in fairly easially to the existing rc.spam I think.
ok, I'll give it a shot.
Some naive questions -
1. I should make the script reentrant because a single procmail lock
would be too slow.
2. murphy is the main mailing machine, but other machines can deliver
too, right? (I'm just guessing that by the MX records.) How do you
keep the mailing list subscription lists up to date? Could a
whitelist be kept up to date in the same fashion?
3. The lists of people who are subscribed to the mailing lists are
kept where on murphy? I think /var/list/*/dist ? (Permission are
funky in /var/list btw, not consistent from list to list.) Reading
them and the whitelist on every invocation would be too slow. The
script could keep a db file or something and update it when a mailing
list was added to. It would check the mtime of the files to decide
when that should happen. It looks like there may already be some
rotation going on of /var/list/*/dist? How does that work?
4. Testing. First, arrange that mail to firstname.lastname@example.org
(or something like that) is delivered to this rule. That's the
address for replies to the challenge. Then create a new list for
testing that we filter through this script. Then when the script is
working to everyone's satisfaction, we can filter all the lists
- Re: Spam
- From: Jason Gunthorpe <email@example.com>