procmail
[Top] [All Lists]

Re: why dead.letter?

1996-08-15 15:45:14

Ok - here is my recipe, changed only so slightly:

:0
* ^TOold-listname
* !X-Loop: $LOGNAME(_at_)$HOST
        {
        WHOSENT=`formail -xFrom:`

        :0c
        stragglers

        :0fb
        |cat $HOME/Lists/address.change; sed -e 's/^/\> /'

        :0fh
        |formail -I"Subject: LISTNAME AUTO-REPLY (address has changed)"\
                         -I"X-Loop: $LOGNAME(_at_)$HOST" 

        :0
        ! $WHOSENT
        }

The point is that ppl are still sending mail to 
old-listname(_at_)old-server(_dot_)com
and I have set a forward at old-server.com to send the mail to the
new-listname address, and send a copy to me.  My recipe should 
warn these stragglers that the address has changed.

What is more of a nuisance than a problem is that it always creates
a dead.letter file.

In response to my question as to how I could make it stop, 
Alan K. Stebbens <stebbens(_at_)sgi(_dot_)com> said:

    > This recipe generates a dead.letter file every time it runs.
    > Is there some way I can stop it from doing that?  

Sure.  Make sure that it gets delivered.



It DOES deliver the mail AND it creates a dead.letter.



The recipe seems conditional on "old-listname".  Does mail get delivered
normally if addressed to other than "old-listname"?



Yes, and I have a number of recipes that work perfectly in the
same .procmailrc file.


    >         WHOSENT=`formail -xFrom:`;

Trying to use "From:" to discover who sent the mail is not very
reliable.  It works, mostly.  Try using this recipe fragment for greater
reliability:

    WHOSENT=`formail -rtzxTo:`

Formail -rt generates a reply header, using all available information in
the original mail message.  The "zx" options extract the value of the
resulting "To:" header, which is the "best" reply address.



This would always put the mail in a loop, since the the 'To:'
is the old-listname address.  It's always to the same address;
the from is the only address that varies.


I wonder whether this is a sendmail, and not a procmail, problem.

Kevin Kelleher
kevink(_at_)concorde(_dot_)com

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