procmail
[Top] [All Lists]

Re: How to immediately exit procmail with non-delivery error code?

2000-11-22 15:09:40
sort of like reading this malformatted message.  Margins are AFU.

A few minutes ago I sent a response to just that remark, and
had Yahoo save a copy in my Sent folder, and then I looked
at that copy and it looked perfectly fine, nothing FU at
all. I've changed my default to save copies of outgoing
messages, so if this problem ever recurs I'll have that copy
to tell me whether the FU happened before or after sending
from Yahoo.

<<If you can identify it as spam, file it in a junkmail
folder.>>

On my old ISP it took many hundreds of hours, probably
thousands of hours, of my time to set up filters to
recognize all so-far sources of spam, and still spammers
would find several new ISPs to spam from every week and I'd
have to spend an additional several hours per week tracking
down where to auto-complain for each source. No, I'm not
willing to spend my time carefully setting up filters for
spam only to passively accept it into a folder that occupies
my disk space and takes my time later to get rid of it
somehow. I want every spammer castrated or otherwise
punished so severely that it deters new spammers. And I want
to be paid for the time I spend blocking spam.

Then it took me many hours of my time to deal with
legitimate new e-mail penpals who happened to have accounts
on spam havens such as Sprint or UUNET or AOL, whose
legitimate e-mail had been auto-complained by my spam filter.

<<Possibly consider   running it through an abuse reporting
mechanism (something to analyse the headers and forward it
to the ISP(s) at fault for it).>>

I don't know of any that exists, except spamcop which
charges money for that service, and my own filter that takes
many hours of my personal time per week to maintain. I can't
afford either the money or the time to protect myself from
being harassed incessantly by spammers. On my current ISP, I
have never posed my e-mail address to any public place (such
as UseNet, Web pages, or Yahoo clubs. Even my resume for
seeking employment doesn't have my new e-mail address at my
new ISP). The only people I told my new e-mail address to
were (1) sysadmin here on my own new ISP when I applied for
the account, (2) sysadmin on old ISP when I asked forwarding
to be set up. The only other place where I put my new e-mail
address was in the form when I applied for a Yahoo account,
where no human should ever see that info, and Yahoo
shouldn't divulge that info anywhere. Yet somehow the
spammers still learned my new e-mail address and started
spamming me here. How???

<<It just causes problems for admins - either yours, or of
the ISP who's addresses were spoofed (but whos server may
not have even been used to deliver the message).>>

Although it's possible for some mailer to spoof the IP
number within an address block, listening on an ethernet for
IP numbers that don't really belong to it, it's not possible
for IP numbers to be spoofed on other IP blocks because
routing wouldn't get ACKs back to the mailer host. So I see
no problem with picking the IP number that sent the spam to
my local ISP and harassing the sysadmin of that spamming ISP
until they STOP allowing their customers to harass me with
spam. The problem is it takes nearly an hour of my time to
study the header to get the IP number, and run traceroute to
find out what ISP is really doing that ISP block, and run
WHOIS to get info about the ISP that owns that block and the
sysadmin for that ISP and update my .procmailrc and manually
send a complaint about the spam that already got through
before I had updated my filter to auto-complain about any
additional e-mail from that address block. Then it takes me
more time to update my .procmailrc to reject the autoreplies
that I get every time an auto-complain occurs or I do a
manual-complain. And a good fraction of the time the
administrative contact address in the WHOIS database is
bogus so my complaint bounces anyway and I have to spend
another hour re-doing all that work to find some other
complaint address.

<<my war against spam has been much more successful at the MTA
level - using blackhole features of newer procmail distributions.  Nice
things about doing it that way is that you don't actually recieve the
message body *AND* you do refuse the message at the time they are sending
it (i.e. is it a positive bounce).>>

That's what I want to do.
procmail -v
procmail v3.11pre7 1997/04/28 ...
Can that version of procmail do that for me?
If not, what version are you using that can do it for you?

<<If procmail can see the message, your MTA (Message
Transfer Agent, usually Sendmail) has ALREADY completed the
SMTP transaction, and you have the entire message at your
end.  You can't "refuse" the message at this point, because
the SMTP transaction is complete.>>

The sysadmin on my ISP told me that procmail is the MTA,
that there's no Sendmail involved, so if I errorcode the
message then it never gets received. But I don't know how to
set up my .procmailrc to do that, which was what I'm asking
about.

man procmailrc
search for 'EXITCODE'.
When I looked yesterday, it didn't find anything. Now it does:

       EXITCODE    When procmail terminates and this variable has
                   been set to a positive numeric value, procmail
                   will use this as the exitcode. ...

So how do I force procmail to terminate immediately without
delivering the mail and without continuing through the rest
of the .procmailrc, so that exitcode will take effect now?
There's no further mention, no list of numeric values or names:

Pattern not found  (press RETURN)

man sendmail

How is that going to help if my sysadmin says sendmail is
NOT being used here for receiving e-mail, only procmail?

man procmailex

All it says is:
              EXITCODE=""
              TRAP="exit 1;"   # The trailing semi-colon is important
                               # since exit is not a standalone program
and
              EXITCODE=1
neither of which is shown as part of a recipe so I don't
know the correct syntax for making either part of a recipe.

EXITCODE=67

But where do I put that in the recipe to make it NOT deliver
the mesage but immediately terminate the procmail program?

<<If you search the procmail archives, you'll find numerous
references to this.>>

I spent about five hours yesterday manually eyeballing the
archives for November (to date), and all of October and
September, and didn't find anything that looked relevant.
Since keyword search of the man pages didn't turn up
anything at all, obviously I didn't have the right keyword
to do an automated search of the archives by keyword. I'll
now try searching for keyword EXITCODE, starting at 10:19
PST, and see if anything useful turns up.

{{set the EXITCODE variable to the desired exit code and
then tell procmail to throw away the message, either by
delivering to /dev/null or, more efficiently though more
obscurely, by unsetting the HOST variable.**}}

Ah, so that's the trick: Normally delivering to /dev/null
will accept the message and exit procmail, but if I first
set the error code, then even though I delivered it to
/dev/null the MTA will think it failed to deliver so signal
back to the sending host that it wasn't delivered, causing
either a non-delivery notice or a will-keep-trying notice
depending on whether the error code indicated a permanent or
temporary nondelivery condition?

If I unset the HOST variable, how do I make procmail exit
immediately at that point instead of continuing to process
other recipes down further through .procmailrc?

{{** Unsetting the HOST variable, or setting it to a value
that doesn't match the hostname of the machine upon which
procmail is running causes ... procmail will simply give up
and exit with the specified exitcode, ...}}

So does this exiting happen immediately as a side-effect of
unsetting the HOST variable, like before the next line of
.procmailrc is examined, or does it just get unset and later
during processing of the next recipe procmail notices
something is amis and exits?

{{If your MTA is sendmail, you can use the exitcode listed
in the /usr/include/sysexits.h file on your system to
indicate to sendmail why you rejected the message.}}

Suppose that I didn't understand my sysadmin correctly when
he seemed to tell me back in June that we aren't running
sendmail at all, but are running procmail, so if procmail
exits with error code then the message hasn't been received
by our ISP at all? Suppose what he really meant to convey is
that procmail runs in realtime underneath sendmail or other
SMTP listener while the SMTP connection is still, before the
SMTP listener acknowledges successful transmission of the
message, so if it errors out then the SMTP connection is
closed either without any ACK at all or with explicit NAK of
some kind of error? Then maybe the following is relevant:

 *      EX_TEMPFAIL -- temporary failure, indicating something that
 *              is not really an error.  In sendmail, this means
 *              that a mailer (e.g.) could not create a connection,
 *              and the request should be reattempted later.

#define EX_TEMPFAIL     75      /* temp failure; user is invited to retry */

So putting it all together, should I write the following?

:0
* Whatever condition, or omit this line if unconditional.
{
  EXITCODE=75
  /dev/null    #Or replace this line with just HOST=0 or HOST or something ?
}

Or does it need to say this (note one extra :0 line)?

:0
* Whatever condition, or omit this line if unconditional.
{
  EXITCODE=75
  :0
  /dev/null    #Or replace this line with just HOST=0 or HOST or something ?
}

Or can I put both the exitcode and host on one line like this?

:0
* Whatever condition, or omit this line if unconditional.
{ EXITCODE=75 HOST }

Would that be dangerous if my sysadmin has configured
procmail to run with my own .procmailrc before some system
default procmailrc, so if I do that it aborts my own
.procmailrc and begins processing the system default instead
of exiting immediately?

{{grep '^Mlocal' /etc/sendmail.cf         ## does it say "procmail"?   )}}

On my ISP it says:
Mlocal,         P=/usr/local/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=10/30,
R=20/40,
Does that look correct? Those flags etc. are inscrutable to me, a mere user.

{{http://www.procmail.org/jari/pm-tips-body.html#technical_matters}}

{{{the code that you will be using mostly is EX_NOUSER or
EX_NOPERM. It tells to the sender of UBE to "piss off and
delete me from your list; I'm not here"}}}

Yeah, but does anybody actually believe this would EVER
cause my address to actually be deleted from the list of six
million e-mail addresses that is re-sold to every new
spammer and to thousands of suckers who receive the SIX
MIILLION ADDRESSES advertisement as spam?? I'd rather have
the mailer on the spam-condoning ISP to be tied up three to
five days repeatedly trying to deliver e-mail to each of
those six million addresses, every one of which has a spam
filter which says EXITCODE=75 "temporary problem, try again
later".

{{{Had SENDMAIL determined the user didn't exist (password
file / aliases / virtusertable.txt), then it would have
rejected the message right when the remote was doing SMTP
RCPT. But the user WAS valid, and so it accepted it.}}}

What happens if SMTP RCPT was accepted, and THEN something
went wrong and sendmail or the whole system or the whole
InterNet crashed and the message BODY couldn't be totally
received? (I'm not talking about spam, I'm talking about
normal e-mail here.) Does the message just get lost, or is
there some kind of later acknowledgement in SMTP that says
the whole message was delivered successfully, so if that
later ack doesn't occur then even though SMTP RCPT was
successful the message is still retained at the sender's
host and re-tried later when the net is back up?

So if procmail does an ERRORCODE to indicate temporary
failure, won't that be seen by the sending host as something
going wrong after SMTP RCPT but before confirmation of full
message text delivered, hence retain original message and
re-try sending later?

{{{By the time Procmail has the message, you've completely
accepted the message,}}}

So there's no way that procmail can effectively refuse to
accept the mail from presumed-spammers, even if the SMTP
connection is still open at the time procmail is invoked??

{{The long term fix is for procmail to act as an LMTP server
for sendmail.  It can then pass not only a full SMTP
extended error code, but also a short line of descriptive
text. ... LMTP support in procmail is in alpha condition,}}

I think that's what I want. Too bad it's not available.
I want any legitimate sender (mistakenly presumed to be spammer) to see:

... while talking to mydomain.com.:
RCPT To:<myaddress(_at_)mydomain(_dot_)com>
<<< 450 Requested mail action not taken: presumed spam, but if not then try
myYahooAddress.
<myaddress(_at_)mydomain(_dot_)com>... Deferred: 450 Requested mail action not 
taken:
presumed spam, but if not then try myYahooAddress.
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old

and of course any real spammer doesn't spend any time
looking at bounces so will never learn my Yahoo address, but
presumally the spam-condoning sysadmin will see six million
such pre-bounces somewhere on his system if I and everyone
else uses this defense against spam.

I've heard of something like a POP mailer or somesuch, never
used any myself, but the thing I understood about them is
that e-mail is never transferred to the user's machine until
the user authorizes it. So spam simply sits on the server
until it expires. What I want is the same idea but back one
level. E-mail sits on the machine of the person who
originally sent it, until the destination machine gets
permission from the user to accept it. So my own ISP would
maintain a list of people trying to send me e-mail who
haven't yet been authorized to send me e-mail, and once or
twice a day I'd glance at this list and see if any are
non-spammers, mark those to accept e-mail, and mark all the
rest to absolutely reject the next time they try an SMTP
connection. But if procmail did this by writing each attempt
in its log, I could glance at the log once or twice a day to
look for anything that isn't spam that didn't get accepted,
update my .procmailrc once or twice a month when there is in
fact such a legitimate new e-mail penpal, and otherwise be
contented that all those spammers are paying for disk space
to hold their spam that isn't yet delivered.

*** Interrupted by new spam, complained via spamcop:
   Yum, this spam is fresh!
   Spam report sent to: hillion(_at_)gz(_dot_)cngb(_dot_)com
   Spam report sent to: abuse(_at_)concentric(_dot_)net
   Spam report sent to: postmaster(_at_)cnc(_dot_)net

{{> OEC=$EXITCODE #save the current exit status of procmail
{{> EXITCODE=67
{{> (a bunch of spam-discarding recipes)
{{> EXITCODE=$OEC #reset the exitcode for the rest of the recipes..

Hey, that's a neat trick, wish I knew it during the previous
four years I was spending so much of my time developing spam
filters. I could have auto-complained and ALSO made the
spammer think that delivery to my address had failed.

Now 12:26 PST and I'm exhausted after spending two hours
doing that search of the archive and learning that procmail
can't do what I want at all so all my time has been wasted,
yesterday and today, plus many hundreds of hours the last
four years. I want all spammers put to death!!

Back to replying to your message now...

combination that does NOT deliver mail but DOES
immediately exit procmail with an error code indicating failure to
Why not successfully deliver to /dev/null ?

Because that would be a successful delivery, whereas I want
delivery to fail so the sending ISP/host will hold onto the
message and retry, both to punish spammers (occupying their
disk with the message for 3-5 days) and to allow for
legitimate penpals whose messages have been (temporarily)
rejected but if I notice their attempt and failure in the
log within 3 days I can fix my .procmailrc to belatedly
accept it (to a real mailbox file, not to /dev/null).

But from what I gleaned above, I can have my cake and eat it
too, i.e. eat the e-mail into /dev/null but pretend like I
didn't by setting EXITCODE=67 so I still have it re-trying
for 3-5 days so I haven't really lost it if it turned out
not to really be spam??

Note that despite all my many hundreds of hours developing
spam filters using procmail, spammers have gotten about
eighteen megabytes of spam past my filters (before I started
using procmail, or by switching to twenty new ISPs per day
to bypass my filters, or after I moved to this new ISP where
I don't yet have any .procmailrc installed because it was
too much work on the other ISP). Given that maybe 95% of
spam was being rejected by my filters, I estimate a total of
fourty megabytes of spam was attempted at me, so it is NOT
an option to accept all spam to a side folder "just in case"
some of it is not spam. I really do want it kept on the
originating ISP's disk at the spammer's expense, not on my
own ISP's disk at my expense. I really do want all e-mail
from unknown sources kept on the originator's computer until
such time as I explicitly give permission for it to be moved
across the SMTP link to my own account on my current ISP.

<<I'd suggest you file suspect messages in a junk folder,
rather than simply trashbinning them>>

So I should give spammers permission to fill up my disk
quota and cause me to either lose my account or pay extra
money for extra storage or have my sysadmin bitching at me
for being over quota or delete lots of my own personal files
to make room for spam or have some system daemon
automatically pick random files of mine to delete because
I'm over quota? NO WAY!!!

How about I find where UUNET's and Sprint's main offices are
located and arrange that all municipal waste is deposited
into their office at their expense, each with a bogus return
address on it so they are unable to return it to sender, and
let them pay for office space that is wasted with garbage
filling it, and let THEM spend their time looking through
all that municipal waste looking for their regular
snail-mail and manually discarding all the rest?

<<Commonly referred to as "green listing" or (less PC)
"white listing". ... 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.>>

I'm already burned out for today. I'm going to stop now and
take a nap for the rest of the available day. Three and a half
hours responding to this one e-mail has exhausted me already.

__________________________________________________
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