On 20 Nov, Matthew G. Saroff wrote:
| Hi,
| My ISP has instituted an ORBS-type (actually ORBZ)
| filtering system, which dumps everything that comes from
| bad IPs. They have Procmail installed as an MDA.
| As I deal with thousands of potential email contacts,
| this means that I could miss emails are legitimately intended
| for me (I typically see about a 3% false positive rate).
| Is there a way at the system level to allow individual
| users to opt out?
| I am assuming that one could test for the presense of a
| file that a user could put in his home directory before dumping
| this stuff to /dev/null, but I would not know how to implement
| this on a system wide .procmailrc file?
| What would be the technique? I'm assuming that it would
| be something like this:
|
| :0h:
| ! ? test -r $HOME/.deleteorbs
| [a script using nslookup or a regularly updated list of IP numbers]
I haven't used ORBZ myself (yet), but the "correct" way to use these
services is at the MTA level (sendmail, postfix, what have you) so the
checking is done while the SMTP conversation is taking place. If that's
how they've implemented it, then the messages aren't being bit bucketed,
and in fact aren't getting to procmail at all. The sender is denied
access at the time of the SMTP connection. The only thing I can think of
off the top of my head to possibly circumvent the ORBZ stuff is a
"SPAMFRIEND" entry in sendmail's access.db (or the equivalent if it
exists in their MTA). I haven't used it, but it might do what you want
[possibly in conjunction FEATURE(`delay_checks')?]. It's beyond my
personal experience and, of course, beyond the scope of this list. But
it might give you something to talk to them about.
I suppose it's possible they could be implementing this through procmail
instead of the MTA, but it would surprise me. That would incur
additional overhead for little or no gain AFAICT. But one possible gain
might be to facilitate a hook to allow users to opt out as you desire.
You'd have to take that up with them because they'd be the ones to
implement it. If it is a procmail thing, and you're looking for
suggestions to take to them, I have only one thought. Whatever test is
done - whether a list of users to (in|ex)clude, or a file test as in
your example - they would want to do it before the ORBZ stuff is done
rather than before delivering to /dev/null. Why do the processing if
you know it's going to be ignored? I'd add users to a file to test at
the top and, if they're in that file, DROPPRIVS and skip immediately to
their ~/.procmailrc. But again, it seems very unlikely to me that this
is the way it's being done.
--
Reply to list please, or append "6" to "procmail" in address if you must.
Spammers' unrelenting address harvesting forces me to this...reluctantly.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail