|
Re: How to immediately exit procmail with non-delivery error code?
2000-11-23 15:43:31
Damn, and there I was saying I wasn't going to reply further. Please
forgive me.
At 18:31 2000-11-22 -0800, Mary Smith wrote:
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
My comment about searching the archive on one of those terms was made with
the apparently overextended assumption that you might actually try slight
variants of them such as "white list" and "whitelist" (the latter produces
a dizzying array of applicable matches). I suggest you go back to the
archives and give it a concerted effort.
Took me longer to recover from the hysterical laughter and type this than
it did to actually try the search with some variants.
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
The spammer isn't hanging around checking out the status of each sent
message. Heck, they deliberatley forge headers so they DON'T get the
bounces. Bouncing/requeueing mail in this fashion _WILL_NOT_ in any way
affect the vast majority of spammers.
<<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.
As I explained, they're not going to attempt redelivery based on your
bounce. At the same time, they're not going to strip your address out of
their database. The real spammer has no clue that your address (or
thousands of others) ever bounced. It isn't like postal bulk mail where
the sender has a vested financial interest in eliminating dupes and
returns, because they're paying for postage - here they aren't paying
postage at all, and they're not using their own systems, so failed
deliveries don't faze them.
You did at some point state that you wanted to be able to take a message
and deliver it if you determined that it was accidentally being flagged as
spam when it wasn't really. How do you plan to do this if you don't store
the messages locally (because of quota issues or whatever). In order to
examine the messages to determine which ones you might want to keep, you've
got to expend time *AND* have the messages to examine. Sure, the logfile
could give you bits of info.
As already pointed out by another lister - even if the remote server does
requeue the message for another delivery attempt, it isn't like you're
filling their queue up with hundreds or thousands of messages - you're just
keeping that ONE message in their send queue. Meanwhile, each time they
send it, YOUR ISP is taking a bandwitdth hit for accepting the delivery.
Consider this: Spammer (A) decides they want to screw with Mary and get her
account closed on ISP1 (B), so they use an open relay at ISP2 (C) to send a
spam - a really big, juicy spam with a 1MB attachment (their PDF catalogue
or whatever) - for simplicity, the 1MB is assumed to be the whole size of
the email, not the actual size of the attachment. Now, as it happens, ISP2
has a fairly standard configuration of sendmail (albeit, older or
misconfigured, since it is an open relay), which will attempt delivery for
5 days, at 15 minute queue intervals.
Now, the spammer (A) dials up to the internet through their throwaway
cheapo account with ISP3 (D) and injects their spam into (C) for delivery
to thousands of people, including you at (B). (A) then disconnects from
(D) and gets on with their life, watching Star Trek or something.
Now, (C) delivers the message to a bunch of places, most of which simply
accept the message and that's that. However, when it delivers the 1MB
message to (B), (B) then passes that WHOLE message to procmail, which
decides to refuse it, and it bounces back to (C) -- depending on the
configuration of (B), this may be simply a header bounce (short and sweet),
or it might be the WHOLE message. Now, (C) gets this bounce, and if it was
to be delivered to the _sender_ of the message, it'll probably fail and
bounce a message back at (B) saying "unknown user" or something to that
affect. The POSTMASTER at (B) gets this message, and that's that. If
however, the bounce from (C) to (B) was formed 'properly' such that (B)
would be requeueing the message, then it does so - 15 minutes later, (B)
starts the process over again - sending another 1MB bomb coming down the
line at (C).
Assuming that 15 minute requeue and the 5 day period, this one spam you
reject in this fashion would generate 480MB of mail traffic from (B) to
(C), and quite possibly an equal amount of traffic from (C) to (B).
Of course, a message size of 1MB was an extreme example - so let us replace
the 1MB figure with something more along the size of a typical spam, say
25KB, and assume you get only 10 spams a day (from your own posts, I
imagine this is a very conservative figure), then once this is in swing,
your requeue scheme will involve 120MB of _junk_ email traffic per day
(once you have the requeues from the previous days tacked onto the requeues
for today). And this is only counting the inbound junk, not your server's
replies to them.
If you just trashbinned them, your daily junkmail would be 250KB of network
traffic.
If you succeeded in implementing your requeue scheme, I'd be very surprised
if your sysadm didn't kick you off of their system pronto. 120MB is about
15Kbits/sec _constant_ throughput (when tcp/ip packet overhead is factored
in). If your ISP has a T1 (1.5MBps) to their mail server, your stunt is
sucking up 1% of their total bandwidth. To what purpose?
Basically, you're screwing your own ISP just as much as the remote one --
and while your own ISP might not be able to control what goes on at the
remote ISP, they _can_ do something about what goes on within their own server.
This info is useless for my purpose because it depends on a
global setting Y or N, and if two e-mail are arrivin
It is the applicable system feature for what you're trying to
accomplish. I'll bet if you were to search on the terms "procmail",
"biff", "comsat", and "notify", you'd find some stuff related to the
featuure (which doesn't seem to be widely used by most people anyway). You
can call it useless if you want. I'll call it trying to be helpful.
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
If COMSAT is disabled in procmail, it should avoid notifying you on
delivery _for that message_. Try reading the manpage...
Procmail doesn't "spawn" biff/comsat - (in.)comsat is a daemon running on
the server, biff is a utility to set whether you want the notifications,
and COMSAT as a setting in procmail defines whether procmail will send a
notification to the daemon that it delivered a message.
two e-mail arriving simultaneously over different
simultaneous SMTP connections?
.. delivered by two separate invocations of procmail. The settings within
one invovation are unique to that invocation.
Thus:
COMSAT=no
:0
* ^freakychick
{
COMSAT=yes
:0
!hotpants
}
:0
* ^weedhead
/dev/null
freakychick should cause a notification, while anything else - including
weedhead, shouldn't. Someone who actually uses COMSAT for something other
than simply disabling notifications will probably be able to answer this
much better.
(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
Not exactly. Sendmail will generate a whole new email message which it has
to deliver to the sender. Perhaps you need it in a more visual example:
The postman comes down the street and opens your mailbox (sendmail) and
fully inserts the letter and closes the door and turns away to continue
along to the next house, at which time, your kid (procmail) takes the
letter out of the mailbox and opens it up, determines it is junkmail, and
writes "return to sender - not at this address" on the outside. he then
places it back in the mailbox to wait for the postman to come by again, or
drops it in the neigbourhood mailbox on the corner, which the postman picks
up mail a while later from, and delivers it to the original sender.
(though it isn't the remote postman picking up mail from your server, it is
your server sending it to theirs).
The postman doesn't hand your kid the letter, he puts it through sendmail,
and then when your kid gets it, the postman isn't part of the picture.
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?
Not from procmail you won't. If there was a _real human_ at the far end,
they might elect to manually re-queue their message to you, but that's it.
As for your "FU" comments elsewhere - for the record, I don't recall ANYONE
in this forum (least of all me) encouraging you to use procmail to do the
bounce scheme you're describing, nor do I recall anyone here making you
expend _hundreds of hours_ dealing with spam. If it hadn't been for the
"FU", I might have been inclined to spend the time to write up some test
scripts and bounce messages between a few of my servers to see exactly how
procmail/sendmail would interract.
Most of the people who've been using procmail for years have already been
up and down the road of how to deal with spam, and you'll find that most of
them will agree that replying to it isn't a good idea. It is ultimatley a
waste of resources - network bandwidth and your time. You're better off
trashbinning spam. If you're ever in a position to sysadm, then you'll
have additional tools (and headaches) at your disposal. In the meantime,
perhaps you can convince your current sysadm (the one who is somehow using
procmail as an MTA) to set up the sendmail (which they're not running),
with rulesets for RBL, RSS, ORBS, etc, to toss mail coming from known open
relays. This blocks the mail from even being accepted at your server.
---
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
|
|