At 13:00 2000-11-22 -0800, Mary Smith wrote:
> sort of like reading this malformatted message. Margins are AFU.
A few minutes ago I sent a response to just that remark, and
[snip]
It was a comment in passing. Don't get 'em in a bunch.
<<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
Tip: don't try to match spammers based on their source addresses -- match
them on other criteria of their email messages - from x-mailers to missing
headers, to a select (or not so select) group of domains in a raw text file
used to match against the headers (like subjects).
There are also people maintaining spam filters written in procmail, which
all you have to do is go get the filters and install them, rather than
fretting over how to write such things.
would find several new ISPs to spam from every week and I'd
I really like RBL systems - rejects at the SMTP session. There are some
programs for implementing RBL checking from within procmail too, but at
that point, your server has already accepted the message - the RBL merely
allows you to trashbin it knowing it is from a known spam relay server.
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
My scripts send me a summary daily - if I feel so inclined, I can scan
though it and see if anything of import might bave been nabbed.
punished so severely that it deters new spammers. And I want
to be paid for the time I spend blocking spam.
Must be some sweet ganja you have there.
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
I suspect either you get a LOT more email than I do, of you're going about
fighting spam in the wrong way. I only get uptight about the spams that
get through my defences - and those, it takes just a minute or two to pull
a mostly canned response from a template file in the return email which is
forwarded to each of the appropriate addresses for the message (abuse@ and
ARIN/RIPE/APNIC contacts for IP blocks).
If you really are spending hours dealing with spam each day, is would seem
like the trivial amount that spamcop might be charging would be well worth it.
spammers still learned my new e-mail address and started
spamming me here. How???
Your account could be a basic name format (joe@ bob@, etc), in which case,
spammers are already blasting messages at them hoping to score a hit or two.
The spam might be from forwarded messages.
The account may have previously existed.
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
It is _trivial_ to set up an rDNS entry to make a host appear to belong to
someone elses' domain, in which case the vast majority of people are going
to send an abusive complaint to "abuse(_at_)domain(_dot_)com", because they see the
domain right there in the headers.
no problem with picking the IP number that sent the spam to
my local ISP and harassing the sysadmin of that spamming ISP
Most of them don't speak English: easily 50% of the spam I review is coming
out of servers in China (the spam itself isn't necessarily Chinese) - I
have a mind to just block all .cn (and .tw, .kr, etc) domains from
SMTP. Most of the other spams are routing through what are obviously
dialup accounts.
until they STOP allowing their customers to harass me with
spam.
Most often, not their _customers_ - it's someone abusing an open mail
relay. OTOH, if they do have an open relay, stick it to 'em, because they
need incentives to close the relay.
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
MS, arthritis, double amputee, what? It doen't take an hour to look into
the headers of a message. Really.
That's what I want to do.
procmail -v
procmail v3.11pre7 1997/04/28 ...
FTR, 3.15 (2000/08/25) is the current release.
Can that version of procmail do that for me?
If not, what version are you using that can do it for you?
Procmail isn't an SMTP agent - *SENDMAIL* is. As I said, I do RBL'ing from
the MTA, not the LDA.
The sysadmin on my ISP told me that procmail is the MTA,
that there's no Sendmail involved, so if I errorcode the
Your sysadm has been raiding your weed stash.
PROCMAIL IS NOT AN MTA. IT DOES NOT SPEAK (E)SMTP.
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.
And which was answered. But what you need to realize is that if you're
processing the message with procmail, your server HAS received the message.
> man procmailrc
> search for 'EXITCODE'.
When I looked yesterday, it didn't find anything. Now it does:
Your computer is on ganja.
> man sendmail
How is that going to help if my sysadmin says sendmail is
NOT being used here for receiving e-mail, only procmail?
Your sysadm is blowing a cloud of smoke at you.
But where do I put that in the recipe to make it NOT deliver
the mesage but immediately terminate the procmail program?
Do you, like read the _whole_ email before expecting the answer at the
top? I did answer this question.
<<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
Time to ditch the 110 baud teletype.
/dev/null the MTA will think it failed to deliver so signal
back to the sending host that it wasn't delivered, causing
Procmail signals the program which spawned it, most typically sendmail -
your sysadm may not be using sendmail, but he sure as heck isn't using
procmail to get the message OFF of his system. PROCMAIL IS AN LDA.
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?
procmail halts on delivery. If it believes it has delivered the message,
it terminates -- it doesn't run the rest of your filters. If you
explicitly deliver to /dev/null, you have _delivered_ the message.
So does this exiting happen immediately as a side-effect of
unsetting the HOST variable, like before the next line of
It should. Keep in mind, I don't use procmail to bounce messages, but the
following should be valid:
:0
* ^somecriteria
{ EXITCODE = 67 ; HOST }
.procmailrc is examined, or does it just get unset and later
during processing of the next recipe procmail notices
something is amis and exits?
Any two invocations of procmail are unaware of each other, except when it
comes to checking lockfiles - and even then, procmail doesn't know (or
care) if the file is locked by another invocation of procmail, or your mail
reader, or what...
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?
Let me say it again - if procmail has a message to handle, your ISP has in
fact ACCEPTED THE WHOLE MESSAGE from the sender, and the sender is NOT
still connected to the system waiting to see if delivery is successfull or not.
#define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */
Even if it were valid, do you want the sender to retry? I don't think so.
: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 ?
}
Use EXITCODE=67 - that is by far the most common error code used.
:0
* Whatever condition, or omit this line if unconditional.
{ EXITCODE=75 HOST }
Hock a semicolon between them.
default procmailrc, so if I do that it aborts my own
.procmailrc and begins processing the system default instead
of exiting immediately?
If there is a system default .procmailrc, it should be executed BEFORE yours.
{{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.
Clue time: sendmail.cf is the ConFiguration file for uhm, what program?
BTW, the flags are well documented in the SENDMAIL documentation.
"Mlocal" means "Mailer - Local" (as in "Local Delivery Agent").
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
NO, which is exactly why you shouldn't bother trying to bounce spam in the
first place. I distinctly recall advising that in my first post.
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".
The problem here is that your server gets choked up, and the net as a whole
does as well. This isn't playing nice with the rest of the internet. If
some joker started doing this with me, and I noted it in my system logs,
I'd just fix the problem: block them out at the router.
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.)
The system logs at either end would have an error akin to "NOQUEUE: Null
connection from ...", essentially meaning, it turned around to get the
message to queue, and there was nobody there anymore.
Does the message just get lost, or is
there some kind of later acknowledgement in SMTP that says
The sender knows they didn't successfully send the message, and will
probably try to resend it.
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?
NO. If procmail has the message, it has the WHOLE message, and the SMTP
session has already been completed.
{{{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??
It simply does not work this way. Ranting about it in this forum WILL NOT
CHANGE ANYTHING.
... 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:
This sort of error is exactly what you'd accomplish in SENDMAIL. Of
course, as a mere system _user_, rather than an _admin_, you have no say
whatsoever on the configuration of sendmail.
Perhaps you should get yourself a Linux box and set it up. Oh, that'd deal
with your storage quotas too.
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
Why would you want to continue attempting delivery?
and of course any real spammer doesn't spend any time
looking at bounces so will never learn my Yahoo address, but
You'd be a fool to give it to them anyway.
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.
Well, I just took a quick show of hands here at my server room, and nobody
here is going to be jumping on THAT bandwagon.
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.
Go write an RFC for it then. Procmail has nothing to do with it, so this
won't be the forum to discuss it in.
look for anything that isn't spam that didn't get accepted,
update my .procmailrc once or twice a month when there is in
The average joe user - who would need to get some benefit from this whole
mechanism - doesn't use procmail. And the sysadm doesn't want mail
stockpiling in their mail queue because other servers are selectively
declining to take the messages at the current time.
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.
Door swings both ways - there are plenty of sysadms who'd just as soon
throw your message away if it can't be delivered in short order. Besides -
the spammers are doing theft of services - taking advantage of ill-secured
servers - they're certainly not PAYING for their email, so this merely
screws some guy in the middle, who has a big enough headache to deal with.
> >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
You're not getting the point here. Delivering to /dev/null means the
message has been thrown away (so you're not going to see it) - and THAT
flags procmail that is has finished processing this message. HOWEVER,
since ERRORLEVEL has been set, when it terminates, it hands back that
return value to the program which called it (whether your ISP wants to
claim that procmail is your MTA or not).
delivery to fail so the sending ISP/host will hold onto the
message and retry, both to punish spammers (occupying their
Simply put, the protocols DO NOT WORK THIS WAY. Sorry, you're out of
luck. SMTP issues (the connection between the mail servers) are BEYOND THE
SCOPE OF PROCMAIL anyway.
log within 3 days I can fix my .procmailrc to belatedly
accept it (to a real mailbox file, not to /dev/null).
The average user isn't going to waste their time with this manual check
protocol.
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??
No, you THREW your copy away in the trash (/dev/null). Again, I might
point out that as I originally commented, discarding the messages outright
isn't really a good move if you're concerned that they might be valid - if
you DO save them to a mailbox, you can post-process it if you determine the
filters trashed something they weren't supposed to.
Also, this won't have the remote system trying to re-deliver the message
either.
Note that despite all my many hundreds of hours developing
spam filters using procmail, spammers have gotten about
Spend a few hours reading up on procmail and a few appropriate RFCs. It
might help.
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
I think you should just give up on email, and go back to pen and paper if
it really is this discouraging...
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"
Duh, you don't keep it forever. There are recipes for rotating archives -
keep it for a couple of days or whatever. You can also compress messages
(pipe through gzip).
<<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
If you really get this much junkmail on a daily basis, then you may as well
give up now.
Your disk space problems aren't my problem. I advised a course of action
which you _can_ employ. You won't be able to make the foreign mail server
hold the email message for you for some indefinate period of time.
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.
I would suggest that you look for a different venue to vent then, because I
can assure you that I didn't find the above worth three hours of anyone's
time - I can sum it up like "dammit, I want it to work this way" over and
over and over.
I don't plan on replying further - it won't be a productive expenditure of
anyone's time.
---
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