Hi List/Sean,
Firstly, thank you for such a reply, REALLY appreciated, I'm running
between my work and home systems, so I trust my reply doesn't stuff up
the threading etc.
At 13:35 2003-02-05 +1300, Roland Hill did say:
to go to my wife, kids or me, i.e. I have tried to achieve a multi
user account via a single ISP account.
There will always be issues with doing this. When you get messages
addressed to more than one recipient, you're going to realize them.
Understand. At the moment it is manageable, but in time.....
If you have a fulltime connection with a dedicated IP address, you
could solve this pretty easily. If you have a dedicated IP address,
but a non-persistent connection, you can still manage it easily, and if
you have a dynamic address, you can still manage if you use a DDNS
(dynamic DNS) service, though that has some limitations. What you
should do is register a domain (or get your ISP to assign you a userid
based hostname within their domain: rhill.kl-airport.co.nz for
example), which you would use for your email. Your server gets set up
as the primary MX for that domain, and the ISP is set up as the
secondary MX. Whenever you're offline, the mail queues up at the ISP.
WHen you get online (if you're not online with a fulltime connection),
you register your DDNS entry (if necessary), and submit an ETRN to your
ISP mailserver (fetchmail has an option for this, check out the
manpage), causing the queued email to be delivered to your server.
Once at your server, it's handled _exactly_ as it would be for separate
accounts, because it _is_ destined for separate accounts. This is
*FAR* better than trying to muddle along with a single POP account for
multiple users, where you'll frequently be tackling misdelivered email
because of BCC's and whatnot.
Demand dialing connection, dynamic IP.
If your ISP won't cooperate, see if you've got a friend with a >
dedicated IP address who'll host a backup MX for your mail server. If
you can do this, you'd ditch needing to sort out who the mail is
destined for, and you wouldn't have problems when someone addresses
both you and your wife on a message (for example).
Will investigate. Understand what you are saying.
Just to background a little more. I have .procmailrc files in each of
the home dirs.
.. allowing each local user to filter mail in whatever way they
wish. However, if you're running ~/.procmailrc, you're running them
_as_ that individual user, and therefore, you cannot write to files not
writeable by _that_user_ - such as mailboxes for the other users you're
doing this phantom delivery for.
No wonder I get the errors below.
Having a /etc/procmail/.procmailrc file did not seem to work (but I
will try
It doesn't work because procmail recognizes no such thing. It
recognizes:
/etc/procmailrc
(no leading dot, and that's a file, not a dir)
Man, I hate missing the obvious. Thanks a lot.Was using the Quick Start
guide that seems to focus more on ~/.procmailrc files. Misread the man
pages......now what other excuses can I come up with!
If you put your generic mail filtering stuff there, you could write to
the mailspools of different users. However, there's a better way,
which won't impact local delivery to users which are valid (and also
survives the eventual conversion to a regular SMTP delivery system
without radical changes).
I'd write a procmail script and call it something like "onepop.rc" and
place it in /etc/procmailrcs/ (that dir has special meaning to
procmail, see the manpages), and invoke it from an alias for the local
user where formail is directing the messages, something like so (using
sendmail alias syntax):
onepop: procmail -m /etc/procmailrcs/onepop.rc
(i.e. your fetchmail doesn't deliver to a user mailbox associated with
you, your wife, or your offspring, but to this "phantom" account -
which doesn't need an underlying user account, because there really
isn't one). If your MTA invokes procmail as root (many do, as that is
often what the MTA is running as, seeing that it needs to assume
different userids when it goes to final delivery), then the procmail
script invoked this way (which itself should be owned by root) is
capable of writing to the individual mail spool files (though, it would
be as _root_, so if it _created_ a previously non-existant file, you'd
have ownership issues). HOWEVER, you really don't want to write to the
individual mail spool files - the recipes in the above-named rcfile
should actually forward the mail into the appropriate local user (so
your _locally_ administered - BY THE RECIPIENT USER - .procmailrc file
can take effect):
:0
* some_addressing_condition
! roland
roland should never have cause to send mail into "onepop", so I doubt
this will ever have an opportunity to create a mail loop locally, but
the ~roland/.procmailrc can have added logic there if you ever go to
autoreply to something, or this recipe can have X-Loop logic added to
it.
Will look into this further. Makes sense.
#Red Hat filter 2 EXISTING
:0
* ^Subject:.*Red Hat
* !^X-Loop: seenit6
| formail -A "X-Loop: seenit6" | \
$SENDMAIL -oi roland(_at_)monaro(_dot_)local
Ugh. is "monaro.local" supposed to be the local system? You don't
want to do this for received messages - get them properly delivered to
the user right from the get-go.
At the moment I forward the message (see EXISTING recipe) and use a
formail script(?)
Pipe. Technically, you're delivering the message through a program,
which adds the header, then passes all of that over to sendmail to
deliver it. Which will deliver the message right back through the
procmail filter.
Yep, monaro.local is my "private domain" (for want of a better term).
And yes initially I got mail loop errors until I added the X-Loop. All
this was because of lock failures, and at the time this was my work
around. You advice will now allow me to do it "correctly".
procmail: Lock failure on "/var/spool/mail/roland.lock"
procmail: Error while writing to "/var/spool/mail/roland"
Procmail is being invoked as _what_ user? I'm going to guess as Joe
schmuck, who has absolutely *NO* rights to write to arbitrary files in
/var/spool/mail.
Starts to all make sense now.
If I chmod 666 /var/spool/mail/roland then the "Error while
writing..."
Evil. Pure evil. Your mailbox file should not be writeable by anyone
else. Re: New User: Locking file issue and other bits
Ahhh....thought it was, will chmod it back <sheepishly>
#####################################################################################
This e-mail message has been scanned for Viruses and Content and
cleared
by MailMarshal
For more information please visit www.marshalsoftware.com
#####################################################################################
FTR, these footers are useless - nobody should trust that when someone
claims that their sent email is free from v*ruses, that it really is -
people should rely on A/V scanning at the receiving end coupled with
responsible behaviour.
Sorry. My work email system. Gets planted on every time.
---
Sean B. Straw / Professional Software Engineering
Thanks again Sean.
Regards,
Roland Hill
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail