procmail
[Top] [All Lists]

Re: FROM_DAEMON on preventing loops

2008-09-29 21:45:58
Before I go further, thank you for replying.  I feared that I upset people
on the list with so many questions.

Before I look down below, I must ask: have you thought about
simply subscribing to this list at the address you want to
receive it at?  Heck, you could subscribe under two addresses,
and use one to answer and the other to receive (and trash
the other receipt if you wanted).


Good question.  Actually the question was academic in nature in that I have
seen other email not get forwarded and the reason was because of FROM_DAEMON
rule.  I was hoping for a better understanding of the rule and looking for a
good work around.  In the meantime, I have done what you suggested and
simply disable that condition, but that is contrary to the advice given here
before.  I asked how one would write a recipe for this very list to come up
with a specific example that we could work off of.  My current recipe is
very similar to the one that you proposed below and is working fine so far,
but I do worry about possible mail loops in the future under certain
circumstances.

Your suggestion to just subscribe with the new address sounds compelling,
except that I was hoping to have one server (either mine or gmails) have the
definitive and authoritative copy of all of my email.  Since we are only
talking about mailing lists, it is a good option that I may consider.



Hmm.  Maybe you need to set your server up with some sendmail
option that doesn't translate the sender on forwarding.  I don't
run a server, so I don't know more about that.  Are you sure
you aren't accidentally munging the header somewhere earlier
on in your rcfile?


Not that I have seen, and the logs indicate the same.  It is puzzling, and
erratic, however it does seem to be isolated to just the mailing lists, so
again, your first suggestion is looking more and more appealing.



      :0
      * ^List-Id: discussion of the procmail program


      {
       :0

       * !^FROM_DAEMON
       * !^FROM_MAILER
       * !^X-Loop: pelorus.org
       {
       :0fw

       | /usr/bin/formail -A "X-Loop: pelorus.org"

       :0c
       !skip(_dot_)x(_dot_)mobile(_at_)gmail(_dot_)com
       }
      }

      :0
      $DEFAULT


Well, without getting too much into what you did, I'll just
post what I would do.  The best field to filter on for the
procmail list is probably the X-BeenThere header.
Also, I wouldn't rely on one single space for the X-Loop snag,
because mail going out somewhere else and coming back could
have whitespace expanded or compressed by various things
beyond your control.  Easiest is to define whitespace somewher
up above for repeat use:

 SPACE = ' '
 TAB = '       '  # a real tab
 WS = $SPACE$TAB


 :0
 * $  ^X-BeenThere:[$WS]*procmail(_at_)lists[(_dot_)]RWTH-Aachen(_dot_)DE
 {
    :0 c
    * $! ^X-Loop:[$WS]*pelorus[.]org
    | formail -A "X-Loop: pelorus.org" |\
      "$SENDMAIL" $SENDMAILFLAGS 
skip(_dot_)x(_dot_)mobile(_at_)gmail(_dot_)com

    SWITCHRC
 }

If you haven't switched rcfiles before this point, the SWITCHRC
should exit procmail and deposit the message in $DEFAULT automatically
whilst applying the proper locking.

If you have switched rcfiles, then the invocation of SWITCHRC simply
returns you to the previous rcfile.  In that case, or if you
prefer in any event, use, instead, your

  :0:
  "$DEFAULT"


Note that I did not put quotes around $SENDMAILFLAGS.  That was
on purpose.  At least in my tests on my system, quotes there
screws up sendmail.

I have tested this.  It works fine for me.

Dallman


Like I said, I see that you are not using the FROM_DAEMON and FROM_MAILER
conditions.  It has been suggested that these conditions are quite important
because if a message that was forwarded to another server bounces back, some
servers may send the original message back as an attachment, in which case
the X-Loop header would not be seen.  This seems to be an important step to
take to ensure loops do not occur, so I was reluctant to remove those
conditions from my recipes, but it was the only way I could seem to get them
to work.  I was hoping someone here could offer an alternative.  Perhaps a
recipe targeted specifically at the format of a google bounce message?  I
thought about that but for the life of me, I couldn't figure out how to get
a bounce message from a google server.  I tried sending an email to a made
up address, but the bounce message ultimately comes from my own SMTP
server--not google.

I am open to other suggestions.  Failing that, I will go with your initial
suggestion.

Skip



____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail


____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail