At 10:24 2003-02-06 +1300, Roland Hill wrote:
On Thu, 2003-02-06 at 07:30, Professional Software Engineering wrote:
> At 03:41 2003-02-05 -0700, LuKreme wrote:
>
> >:0
> >* ^Subject:.*Redhat
> >! roland
>
>
> Note that my suggestion to run the fetchmail delivery through an aliased
> user (which invokes procmail directly) circumvents issues with
> /etc/procmailrc generic filtering (where it appears all these filters are
> getting stuffed), since when you forward to a local user, it doesn't route
> back through the "onepop.rc" script - it gets delivered through local
> filtering. If you simply put a recipe like the above into
/etc/procmailrc,
> it'll loop. Seems that Roland is already aware of that, but I don't think
> his kreminess is recognizing that at the moment.
Yep, tried this again - just in case, but you guessed it a mail loop.
>
> Thus, the onepop.rc script needs only to focus on trying to split up
> delivery among the multiple users of the one pop mailbox - *NOT* to
> actually perform individual mailbox filtering (unless of course, filtering
> on subjects is how some messages are being identified as being for a
> certain recipient, which is unfortunate if so).
So, even though I now have a global procmailrc that has root privileges,
I won't be able to deliver to a users mail spool (as seems to have been
demonstrated in my last message)?
You shouldn't be attempting to deliver directly into a spool
file. procmail really doesn't expect to be running as a bogus user.
Separate this pop mailbox fetching from local users. by setting up
fetchmail to deliver to a "onepop" (or whatever) ALIAS, which invoked
procmail, *THAT* rcfile (*NOT* /etc/procmailrc ) can *FORWARD* the message
to the appropriate user, who would simply deliver into their mailspool, or
run through a user-administered procmailrc.
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.
If that is the case then obviously I will implement the onepop.rc script.
It's the way to do it.
All outgoing mail goes through a sender_canonical rewrite in postfix to
an address that my ISP recognizes. Coming in I have to catch it with a
filter. The reason why it is manageable at the moment is the bulk of the
mail goes to my wife and I have it set up that all mail goes to her
unless picked up by a filter (won't bore you with how I do it, and I'm
going to modify it and use the DEFAULT= setting once things settle
down).
Suggestion: if you cant' get separate POP accounts with the ISP, and
you're not keen on setting up your own mail domain, check to see if your
ISP supports PLUSSED addressing.
OTOH, I don't know that postfix actually supports it. I use sendmail, and
have been happy with it for years.
let's assume that your (shared) isp address is "foobar(_at_)someisp(_dot_)tld"
a plussed address would be like:
foobar+roland(_at_)someisp(_dot_)tld
foobar+wife(_at_)someisp(_dot_)tld
foobar+offspring(_at_)someisp(_dot_)tld
Your onepop.rc file would conceivably look something like:
:0
* ^TO_foobar\+roland@
! roland
:0
* ^TO_foobar\+offspring@
! offspring
# basically, anything that isn't plussed to a recognized address above would
# be sent to your wife - her own plussed address, as well as the unplussed
# version of the pop address.
:0
! wife
Of course, first you have to determine if your mail system supports plussed
addresses, and if it exposes the address in the headers. Then, you'll need
to change your s*bscriptions to mailing lists to use your plussed address
(and your rewrite would need to plus them - but at least each user would be
rewritten to a separate address), but from there on out, you have separate
addresses, even if they continue to resolve to one POP mailbox at your ISP.
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.
---
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