Jason Gunthorpe <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] (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 through it. Guy
