procmail
[Top] [All Lists]

Re: double copies unwanted

2002-07-09 10:29:01
At 13:05 2002-07-09 +0200, Mailing Manager wrote:


:0:
* ^TO_ciccio(_at_)lastminutetour(_dot_)*
CICCIO

This is a DIFFERENT condition than the one you're using for pluto - the ^TO_ macro regexp will match a variety of other headers - pretty much anything where this address appears as a recipient - To:, Cc:, apparently-to, etc.

When PLUTO *AND* CICCIO receive messages - when the system actually sends two copies through, and where CICCIO is a cleartext recipient, CICCIO is going to receive two copies - AND - because you don't 'c'opy on this recipe, PLUTO won't recieve their copy (this isn't consistent with your complaint, where you indicate that they both get two copies).

The .* at the end is meaningless - zero or more of anything will match if there's nothing (not even a ".com"), or if there's anything - so why match AT THE END? Same applies to your other recipes with that condition.

:0:

This shouldn't really have a lock at this level - it should be on the recipe that actually delivers to a mailbox. Note also that your preceeding delivery recipe should have locking, but does not.

* ^To(_dot_)*pluto(_at_)lastminutetour(_dot_)*

THIS condition however, is that pluto appear on a header line starting with "To" (which for all intents, is the To: field only).

{
:0c
| ./winpopup user
:0
PLUTO
}

Does winpopup even read the WHOLE message? I'm betting not - so procmail goes "oh, there was a write error - the whole message wasn't read, so it must not have delivered successfully, so I'll just KEEP THIS COPY and fall through with it."

Read 'man procmailrc', then add an 'i' to the winpopup flags.

:0:
* ^TO_realaddress(_at_)lastminutetour(_dot_)*
$DEFAULT

What happens AFTER this recipe? Nothing? If so, then WHY explicitly deliver to $DEFAULT if not doing anything at all will result in the SAME $DEFAULT action?

Well, whe i send an email to pluto and put in cc ciccio (nad viceversa) the
mail goes in double copies on both the folder.

This error description is not consistent with your recipe - if Pluto is cc:'d on anything, they won't receive a copy, and if Ciccio is cleartext addressed, the condition for it will match on BOTH received copies of the message, and it won't copy to pluto at all.

I do not want it, but i want that the same email, with to and cc, goes in
both folder one time.

Procmail is not an MTA.

You should enable VERBOSE logging and examing the logging results from when you send a message.




:0
* ^TO_(pluto|ciccio)@lastminutetour\.
{
        # pluto or ciccio is the recipient - HOWEVER, there may be OTHER
        # recipients on a message addressed to one of these chaps!
        # Perhaps we should consider using an MTA for the job of the MTA?

        # first, eliminate dupes (so we have ONE message bopping through
        # for both of these users)
        :0Whc: lastminute.lock
        | formail -rD 8192 lastminute.cache

        # this preserves the "other" copies - if you don't want this, then
        # remove the 'c' flag from the above and remove this recipe.
        :0a:
        lastminute.duplicates

        # messages apparently to ciccio.
        :0c:
        * ^TO_ciccio(_at_)lastminutetour\(_dot_)
        CICCIO

        :0
        * ^TO_pluto(_at_)lastminutetour\(_dot_)
        {
                :0c:
                PLUTO

                :oi
                | ./winpopup user
        }

        # trash anything that remains.
        # (woe be us if there were other recipients!)
        :0
        /dev/null
}


The above recipe has a number of points for failure: specifically, if a copy of the message comes through BCC'd to both users, only ONE of them will receive it, because only ONE should have an apparently-to or similar construct.

The above is totally untested. I suggest you consider using the MTA for what it's good at, and set up separate accounts for your separate users. I suspect that you're dealing with all of this through a single virtual user on your ISP's server, but what you're trying to accomplish is fraught with problems because procmail isn't intended for this sort of stuff - the MTA doesn't hand it a list of all the recipients - at best, it gets the username of the resolved local recipient - which is the account you're running this from, not the email addresses of the recipients.

As someone once said, "it sucks to be you."

---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

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