procmail
[Top] [All Lists]

Re: How to prevent this mail loop

1997-07-28 22:29:00
At 08:21 PM 7/28/97 -0500, Matthew G. Saroff wrote:
Hi,
      I've set up my procmail to forward all incoming mail to another
address (there's some mail that I need to stay current on).
      Unfortunately, some sort of mail loop gets set up.  

My comments are down below the trimmed message body.

My Procmail recipe:
#forward copies of everything to my work mail 
:0c
!saroff(_at_)vs(_dot_)lmco(_dot_)com

Pretty simple here.  Now, does the vs.lmco.com address have procmail
running there too?

---------- Forwarded message ----------
(Much repeating headers from the loop snipped)

Well, were they repeating patterns of headers presented here?  The nature
of the repeat may be of importance - two servers could be bouncing a
message back and forth.

Received: from mbox.vs.lmco.com (mbox.vs.lmco.com [138.209.240.12]) by
pcans1.pca.net (8.8.3/8.6.9) with ESMTP id TAA15021 for 
<msaroff(_at_)pca(_dot_)net>;
Mon, 28 Jul 1997 19:55:43 -0500
Received: from localhost by mbox.vs.lmco.com (8.8.5/VS-1.21)
      id TAA00373; Mon, 28 Jul 1997 19:51:15 -0500 (CDT)
Date: Mon, 28 Jul 1997 19:51:15 -0500 (CDT)
From: MAILER-DAEMON(_at_)vs(_dot_)lmco(_dot_)com (Mail Delivery Subsystem)
Subject: Returned mail: Data format error
Message-Id: 
<199707290051(_dot_)TAA00373(_at_)mbox(_dot_)vs(_dot_)lmco(_dot_)com>
To: <msaroff(_at_)pca(_dot_)net>
Auto-Submitted: auto-generated (failure)

The original message was received at Mon, 28 Jul 1997 19:50:43 -0500 (CDT)
from msaroff(_at_)[207(_dot_)136(_dot_)42(_dot_)18]

  ----- The following addresses had permanent fatal errors -----
saroff(_at_)poseidon         
   (expanded from: <saroff(_at_)vs(_dot_)lmco(_dot_)com>)

Personally, if I was running the mail system in question, I'd be expanding
the name to a long domain, not some runted local domain.  Their
perrogative, but that expanded name doesn't mean crap outside of their
local mailer config.

  ----- Transcript of session follows -----
554 saroff(_at_)poseidon         ... Cannot send 8-bit data to 7-bit 
destination
501 saroff(_at_)poseidon         ... Data format error

Looks like your friendly people at pca.net (where I'm _assuming_ this error
was mailed from, since you kindly trimmed the top of the message header)
turned off the 8-bit support in their sendmail config.  Chances are, they
did this because they figured it would increase/maintain existing
compatability with other systems.  I've yet to see disabling 8-bit RECEIVES
to affect much other than BREAK things from some systems mailing 8-bit data.

  ----- Original message follows -----
--SNIP--
  ----- Original message follows -----

Why two original separators?


Received: from mail1.socomm.net (root(_at_)mail1(_dot_)socomm(_dot_)net 
[207.15.160.25]) by
pcans1.pca.net (8.8.3/8.6.9) with ESMTP id EAA01114 for
<msaroff(_at_)pcans1(_dot_)pca(_dot_)net>; Mon, 28 Jul 1997 04:54:08 -0500
From: accounts2(_at_)checksxpress95(_dot_)com
Received: from mail1.socomm.net
(1Cust124.max44.san-francisco2.ca.ms.uu.net [153.34.230.124]) by
mail1.socomm.net (8.8.5/8.8.2) with SMTP id EAA27366; Mon, 28 Jul 1997
04:25:43 -0500
Received: from mailhost.noreply.com (ppp3.noreply.com [208.9.77.62]) by
(from root(_at_)localhost) by emout07.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) with
SMTP id GAA00422 (8.8.5/8.6.5) with SMTP id GAA08062 for
<entrepreneur(_at_)smallbusiness200(_dot_)com>; Mon, 28 Jul 1997 02:24:38 -0600 
(EST)

these out-of-order received lines are usually a dead giveaway of SPAM.  The
two headers AFTER the From: line are bogus - they're unattached to each
other, AND the first one is a transfer to itself.

X-UIDL: 2610431056a78aeb1b138fda427c9a5e

Another SPAM identifier:  Check your mail logs and see how many VALID
messages you've recieved which have X-UIDL in the header.

[snip - this is a HUGE SPAM - did you really need to forward the BODY to
the list?]

Now, simply put, your mail loop problem is a function of forwarding MAILER
messages which are reporting failures in the forwarding mechanism.  I
suggest you nab these forward bounces, and toss them into a local file,
rather than attempt to forward them again.

You'd place such a recipe preceeding the forwarding one you have above.
Also, I presume you're aware that the recipe you have above works on a COPY
of the message - so another copy continues to be processed by any local
scripts.

This is completely non-debugged, and just belted out here in response to
your problem.  Even if the specific syntax is wrong, the procedural concept
should be about right:


# Change these as appropriate for your script.
LocalMailer = MAILER-DAEMON(_at_)vs(_dot_)lmco(_dot_)com
FwdAddress = saroff(_at_)vs(_dot_)lmco(_dot_)com

# If the message is from our local mailer, AND the body contains reference to
# our FORWARD address (not the local address), file it as an inter-system
# bounce - attempts to forward THIS message will be troublesome.
# filtering stops here if it is a bounce.
# YES, this could be implemented a lot better than it is here, but I don't
# have the time to work out an elegant solution for you.
:0:
* $^FROM.$LocalMailer
* $B ?? $FwdAddress
bouncefile

# forward copies of everything to an alternate site
# At least stuff that isn't bounce reports on THIS forward operation.
# which should be taken care of BEFORE we get here anyway.
:0c
! $FwdAddress

# any additional recipes which you might normally perform.
# if none, then remove the 'c' flag on the preceeding recipe.

---
 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

<Prev in Thread] Current Thread [Next in Thread>