At 18:45 2000-11-21 -0800, Mary Smith wrote:
of spam, which consumed thousands of hours of my time.
.. sort of like reading this malformatted message. Margins are AFU.
if I bounced it, it'd sit 3-5 days in the queue on my
own ISP before landing in my own sysadmin's box, who would
get mad at me. (This is because the return address on spam
is almost always a bogus address on some host that
doesn't even accept SMTP connections.)
... and is part of the reason why replying to spam isn't worth the
effort. If you can identify it as spam, file it in a junkmail
folder. 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). DO NOT reply to it, or try to bounce it. 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).
Ultimatley, 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).
I'm now on an ISP where procmail is the mailer, so I
Actually, it is the LDA - Local Delivery Agent, but whatever.
reject spam and it'd sit 3-5 days on the spammer's ISP
instead of coming into my own ISP at all.
Uhm, no. 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.
man pages and can't find any reference to those exit
codes for rejecting e-mail. I find no mention of error codes
man procmailrc
search for 'EXITCODE'. Then run:
man sendmail
search on 'exit'. You should get a section listing exit statuses that
sendmail uses. These are defined in sysexits.h (check /usr/include/)
Particularly interesting ones are:
#define EX_NOUSER 67 /* addressee unknown */
#define EX_NOHOST 68 /* host name unknown */
In procmail, you'd use these by setting EXITCODE manually.
See 'man procmailex':
EXITCODE=67
If you search the procmail archives, you'll find numerous references to
this. However, this merely attempts to bounce the message (as sendmail
will get the impression it wasn't deliverable). As you note, many bounces
don't work, and they piss off your sysadm.
Welcome to the real world. It isn't a utopia here.
EXITCODE even has it's very own section in the Procmail FAQ.
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 ?
:0
* somecriteria
{
EXITCODE = 67
:0
/dev/null
}
(though I'd suggest you file suspect messages in a junk folder, rather than
simply trashbinning them)
deliver, and perhaps also a text message saying something
like "presumed spam rejected, if not spam please re-send to
my Yahoo address instead".
Well, that last bit adds a twist - you cannot define the error message
which sendmail will send back if you actually hope to simulate an error
when exiting. Thus, you must generate an auto-reply, and try to make it
look like a bounce. Again, the FAQ has a link to a resource for that as well.
Just so we know we're on the same page here, the FAQ I am referring to
(with an anchor to the exitcode section) is:
<http://www.ling.helsinki.fi/~reriksso/procmail/mini-faq.html#exitcode>
Note: On this ISP, I receive legitimate e-mail from
only two sources:
My girlfriend, and my ISP's customer support etc.
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.
temporary-failure mode so that it'll keep re-trying
for 3-5 days so I have time to notice some mistake and change
It shouldn't really try to send it for 3-5 days unless you or the remote
site have a connectivity issue. 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.
One additional question: When e-mail arrives, it spews
the From
and Subject lines and the first five lines of body
'man biff'
'man in.comsat'
Procmail has a setting for "comsat", to enable/disable notifications on
mailbox deliveries. You'll need to get assistance from someone else on
that one though -- mail notifications annoy me since I get so much email,
and so I deliberatley disable such things. How to selectively enable it
isn't part of my plan.
but don't want to be bothered with if it's spam I'm
rejecting anyway.
generally speaking, I'd think if you're trashbinning or bouncing it, you
shouldn't get a notification, but I may be wrong. Barring anything else,
you could probably selectively enable comsat for those deliveries which
interest you.
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail