procmail
[Top] [All Lists]

Re: New User: Locking file issue and other bits

2003-02-05 01:15:17
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.

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.

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

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.

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)

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.

- Phase 1 of plan: "Drop" mail in /var/spool/mail/<user>

A typical .procmailrc file I created:

PMDIR=/etc/procmail

IMO, this is inappropriate for .procmail files located in user dirs. I realize why you're probably doing it, but you want to avoid this.

#Red Hat filter 1 NEW
:0:
* ^Subject:.*Redhat
/var/spool/mail/roland

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

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.

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.

DEFAULT=/var/spool/mail/rachel

Yea, that'd work for defining a default user.

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

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