procmail
[Top] [All Lists]

Re: New User: Locking file issue and other bits [Part 2]

2003-02-06 12:05:25
At 14:11 2003-02-06 +1300, Roland Hill did say:
> You don't want to be using /etc/procmailrc for splitting up your one pop
> account for delivery to local users - leave /etc/procmailrc for "real"
> email really being delivered to local users like a NORMAL system would.

Okay.

BTW, I don't mean to imply that your email situation is "abnormal" - plenty of people use one physical mailbox and try to split it up, although it remains fraught with issues. "normal" above means "processed just like a regular mail host", since what you're doing involves a bit of kludging which a regular mail host wouldn't be employing.

By keeping the kludge out of the files involved with a regular mail delivery (/etc/procmailrc is part of that for LDA operation of procmail), you isolate the kludge so that it doesn't interfere with regular email. Some day when you get your host connected as a standard mail host (fulltime, with dedicated IP, or even diaulup with a dynamic IP using a dyndns service and SMTP ETRN to "tickle" your backup MX to dump its spool to you), you won't have to change anything about your local email, excepting for your sender rewrite rules.

> I've BCC'd this message to a plussed version of your gen.nz address.  See
> if you don't see something in the headers.

Saw the plussed address in the header, but I only received 1 copy of
your post that I assume came from the list? Or did you only BCC it, and
therefore I got it with the plussed address?

Your mail filtering may have tossed one of the copies. Messages from the list will carry various list-based headers (view the headers of THIS message, and you'll see the better part of a dozen headers associated with it). The BCC'd copy would not bear any of those identifiers.

You should note that the To: was the list address, and I *did* send it here. Since I used BCC: to send the copy to the plussed address, the *ONLY* reason you would have seen the plussed address in the headers is if you received the copy I sent via BCC (your s*bscription to the procmail list should be at your regular pop address, right?). This confirms that plussed addressing works with your ISP account (which, not coincidentally, is exactly why I sent the BCC in the first place), and that you're capable of seeing the plussed address on the message you receive (although there are probably cases where you won't) -- even on BCC'd messages (which is critical when using a single physical account to distribute email to multiple recipients).

Since the BCC'd message would have arrived directly from my mail server to your ISP, and the list-bound copy would have travelled from my mail server to the procmail list server, and from there to your ISP, they would have arrived as two separate messages in your account. If I'd Bcc'd a plussed address on a message with a plain copy to you as well, *ONE* message would actually be transferred from my mail server to your ISP mail server (and recognizing both the envelope recipients as being the same physical mailbox, your ISP would probably have places them in there as a single message, which is one of the rubs with using a single pop account for multiple users), but that's not how I sent the message.

Check your fetchmail logs perhaps?

The plus-based onepop.rc file I included in my previous post should be a workable file for you if you change your addressing to use the plussing. Put that file in /etc/procmailrcs/onepop.rc, make the change to your MTA aliases (as previously mentioned):

onepop: "|/usr/bin/procmail -m /etc/procmailrcs/onepop.rc"

I believe that I may have accidentally omitted the leading pipe ('|') in the alias I sent the first time - that's required to indicate delivery to a program. Also, so that paths aren't an issue, you should explicitly specify the path to your procmail binary ('which procmail' will tell you what it is on your system).

Rebuild your aliases hash (however postfix makes you do this -- with sendmail, I have a makefile which I've used since long before some distributions included anything similar which rebuilds aliases, virtusertable, and other hashes, and as necessary will HUP the mailer daemon).

All of the above can be put into place before you make changes to your fetchmail (well, should be anyway, since if fetchmail attempts to deliver to an alias that doesn't exist yet, that's not good). Gut the content of your /etc/procmailrc (which shouldn't be used for this pop splitting process), and change fetchmailrc to send messages to the local user "onepop" (or, provided you change the text on the LHS of the alias above, to whatever insane looking not-likely-to-ever-be-encountered-in-nature username -- and there is no requirement that the onepop.rc filename match the alias name, FTR), then send a message to your POP account using a plussed address and see where it shows up. As written in the plussed onepop.rc, anything not specifically identified as being to you or "offspring" (my term for children <g>, though my wife is due in June), will be forwarded to the local user account for your wife.

Thanks so much for your time Sean. A friend of mine highly recommended
this list - now I know why.

I enjoy helping people who have an interest in working to arrive at a solution.

I've a drastically different opinion of the folks who pop in and post asking for someone else to write their scripts for them from the ground up because they've got no interest in reading the manpages or learning procmail, and then continue to post their requests (like, daily) when they get no response. You'll see a sarcastic side of me (and some of the other regulars) now and again when someone posts demands.

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