Hello everyone. I apologize for the delay in my response. Don was extremely
helpful in helping me fix my problem that I was having. I meant to reply
earlier to post details of the problem and what the fix was. But, we lost
our T-1 due to a Broadcast storm that occured at our ISP, which brought
down our T-1 for a bit. :/
here is my original recipe:
:0
* ^(X-Spam-Flag: YES|Subject:.*\[SPAM\])
! spamcop(_at_)courtesy(_dot_)com
The new recipe:
:0
* ! ()\<spamcop(_at_)courtesy\(_dot_)com\>
* ^(X-Spam-Flag: YES|Subject:.*\[SPAM\])
! spamcop(_at_)courtesy(_dot_)com
Basically, after discussing it with Don, my first recipe had a problem that
caused a mailloop. What was causing this was, the one condition I had, to
match either
X-Spam-Flag: or [SPAM] in Subject: matched the message when it was
forwarded. So it keep getting forwarded, over and over. Not exactly what I
wanted. :)
I learned a valuable lesson here from Don:
"Whenever you auto-reply, auto-ack, auto-forward, auto-anything, you *must*
have loop detection."
Which I did not have, hence, a mailloop.
In the new recipe, the ! negates the condition and the () protects the
token from being misinterpreted.
So in the new recipe, it's saying, the message must not match
spamcop(_at_)courtesy(_dot_)com anywhere in the headers, and must also match
X-Spam-Flag: Yes or Subject: [SPAM].
So, the first time email comes through, it passes both conditions and is
forwarded.
I've tested this several times, and it is working like a charm now. No
problems at all.
I have much to learn about Procmail but im very excited.
I want to thank Don for helping me resolve this problem. I've learned a lot
here and wanted to share what I learned with others so if they come across
something similar, they can use it to their benefit.
Jason
At 07:51 PM 10/9/2003 -0400, you wrote:
On 9 Oct, David W. Tamkin wrote:
| Don Hammond wrote:
|
| > Is it possible that postfix is smarter
| > than sendmail about the way it interfaces with procmail as LDA? Could
| > it be waiting around to find out that "delivery" was actually a forward
| > and that it's going to create a loop?
|
| If you mean, "Does Postfix, like qmail, refuse to deliver to an address
| that already appears in a Delivered-To: header, while sendmail doesn't
| care?" the answer is yes.
|
I've had some contact off-list with Jason, who has indicated he'll
summarize for the list once he completely understands it. I suggested
to him, even though there didn't seem to be much interest in the
thread, there's always the possibility that a lurker or two has
something to gain.
It was in fact the procmail recipe that needed fixing, and not postfix,
dns, hosts files or any of the other conspiracy theories I concocted.
I hate it when I spend a lot of time guessing all kinds of contorted
problems, and it turns out to be the the simplest of things that didn't
even occur to me until the last minute. Well, it did occur to me and I
mentioned it as a deficiency, but not as the cause of the problem.
Adding loop detection apparently fixed the problem, though we'll wait
for Jason to clarify that after he's had a chance to work it out some
more.
Whether it was the Delivered-To: header or not, I don't know, but that
sure seems like a sensible feature. Whatever it was, postfix did an
admirable job of mnimizing the effect. It's not fun deleting a couple
thousand messages when you create a loop. I know. :-(
--
Email address in From: header is valid * but only for a couple of days *
This is my reluctant response to spammers' unrelenting address harvesting
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail