<<Commonly referred to as "green listing" or (less PC)
"white listing". <P> This has been discussed in great detail
on the procmail list on a number of occasions. Search the
archives for one of these terms, and you should find what
you're looking for.>>
At 17:43 PST I'm starting my search... {{Result for query
"green listing" (p1 of 2)}} Not a lot of hits on that term.
{{found 3 matches in 2 files.}} One of which was YOUR
suggestion that I search the archives for that term, and the
other of which was just a general suggestion to have a green
list, nothing about how to accomplish it. {{Result for query
"white listing" (p1 of 2)}} Again one hit on your saying I
should look for it, and the only other hit was:
{{> * 84: free insertion of linear-white-space (which permits folding
{{> * 87: Then follows a percise listing of the lexical tokens of a
{{> structured
Nothing in the archives at all to help me with either term.
The good news is it's 17:50 now so it took me only 7 minutes
to come up dry.
<<It shouldn't really try to send it for 3-5 days unless you
or the remote site have a connectivity issue.>>
I want to pretend like there's a connectivity issue between
the spammer's machine and my own ISP's machine, so the
spammer thinks if he keeps trying he'll eventaully succeed
in harassing me, but the sysadmin there seeing six hundred
thousand such retries figures out it's bad to keep the
spammer as a customer, and it takes the spammer's ISP
several days to clear out the mail queues so maybe changes
policies to not let spammers get accounts in the first place
in the future.
<<In reality, unless you are the sysadm, once you've bounced
it, or otherwise put a message into the queue, you're not
about to pull it back.>>
If the spammer keeps trying to send me spam repeatedly for
3-5 days, and my .procmailrc is acting like communication is
failing at first, but later is changed to accept retries
from non-spammers, I'm not pulling anything back, I'm simply
ceasing to play 'possum any more on legitimate e-mail.
man biff
This info is useless for my purpose because it depends on a
global setting Y or N, and if two e-mail are arriving
simultaneously so that two clones of procmail are running
concurrently, one from a spammer and another from my
girlfriend, I don't want the spam clone to globally disable
biff so that I don't get any notification of my girlfriend's
e-mail.
man in.comsat
No manual entry for in.comsat
<<Procmail has a setting for "comsat", to enable/disable
notifications on mailbox deliveries.>>
Does biff/comsat notify (bleep&spew across my VT100 screen)
only when procmail thinks the incoming e-mail was actually
delivered, not when it aborts because HOST is unset? If the
e-mail is delivered to /dev/null, does it notify or not?
(This question is for anyone who knows, not necessary the
person I'm directly responding to.)
<<you could probably selectively enable comsat for those
deliveries which interest you.>>
Can I do that locally for only the current procmail clone
and any biff/comsat spawned by it, but NOT for other
procmail clones that might be running concurrently due to
two e-mail arriving simultaneously over different
simultaneous SMTP connections?
OK, I've finished reading your message and looking up what I
could and noting anything possibly useful and asking further
questions. The question of biff notification is of secondary
importance. The main question is whether on this Unix system
(FreeBSD 2.2.2-RELEASE) if procmail passes back a temporary
communications breakdown EXITCODE=75 to whatever program
(Sendmail or whatever) is managing the SMTP connection, will
the SMTP connection have a temporary failure passed back to
the spamming host, like we received your message but have no
place to put it so please don't delete it from your queue
just yet, try sending it to us sometime later after we have
time to fix the temporary problem?
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail