James Butler | 1 Apr 2009 01:25

Re: Incorrect Resolution of $HOME Variable

> OK, so you changed config.h in contradiction of what config.h says to
> do.

config.h specifies that it *used* to be the place to define SYSTEM_MBOX.
Where that message appears is the place in the code where the definition
for SYSTEM_MBOX used to be, at least as recently as 1999. SYSTEM_MBOX is
no longer explicitly defined anywhere in the source files, and there is no
instruction that equates the MAILDIR variable with SYSTEM_MBOX. The notice
is more of an artifact for old-school users.

Regardless. I have now, again, made the change as you suggest, recompiled
and re-tested:

config.h
#define DEFmaildir "$HOME"

authenticate.c
#define MAILSPOOLDIR "$HOME/Maildir/"

after running make:

autoconf.h
#define MAILSPOOLDIR "$HOME/Maildir/"

The result is exactly as I have reported:

procmail -v
procmail v3.22 2001/09/10
...Locking strategies:     dotlocking, fcntl(), lockf(), flock()
Default rcfile:         /etc/procmailrc
(Continue reading)

Dallman Ross | 1 Apr 2009 01:31

RE: procmail setup simple testing failure

Robert Holtzman wrote Tuesday, March 31, 2009 8:36:

> What does $HOST mean? I can't find it in the list of bash
> variables.  Does it have an assigned value?

Yes.

To see what vars procmail runs, you can do this:

 1:20am [~] 33[0]> procmail -m DEFAULT=/dev/null SHELL=/bin/sh 'LOG=`env`' /dev/null < /dev/null
 TZ=Europe/Berlin
 LINEBUF=2048
 COMSAT=no
 LOGNAME=dman
 HOME=/net/u/1/d/dman
 PROCMAIL_VERSION=3.23pre++     # don't worry, nobody but me and its author has this version
 SENDMAILFLAGS=-oi
 SENDMAIL=/usr/sbin/sendmail
 SHELLFLAGS=-c
 MSGPREFIX=msg.
 LOCKEXT=.lock
 SHELLMETAS=&|<>~;?*[
 HOST=panix5.panix.com
 PATH=/net/u/1/d/dman/bin:/bin:/usr/local/bin:/usr/bin
 DEFAULT=/dev/null
 SHELL=/bin/sh

Dallman
Dallman Ross | 1 Apr 2009 01:51

RE: Incorrect Resolution of $HOME Variable

James Butler wrote Tuesday, March 31, 2009 23:12:

> When I tried modifying config.h as:
> 
> #define DEFmaildir "$HOME/Maildir/" <= with the trailing slash
> 
> All I got were "Cannot treat as directory" errors. As soon as
> I removed the trailing slash, the error went away and procmail
> was able to create subdirectories, etc. as noted in my earlier
> messages.

That's because you already have an mbox file sitting there.
You can't treat as a directory a name that is already assigned
to a file!

I thought I wrote this to the list a few days ago.  You need
to delete your mbox file under there before the maildir+
stuff will work.

Dallman
Robert Holtzman | 1 Apr 2009 08:16
Picon

RE: procmail setup simple testing failure

On Wed, 1 Apr 2009, Dallman Ross wrote:

> Robert Holtzman wrote Tuesday, March 31, 2009 8:36:
>
>> What does $HOST mean? I can't find it in the list of bash
>> variables.  Does it have an assigned value?
>
> Yes.
>
> To see what vars procmail runs, you can do this:
>
> 1:20am [~] 33[0]> procmail -m DEFAULT=/dev/null SHELL=/bin/sh 'LOG=`env`' /dev/null < /dev/null

Thanks. I didn't realize it was a *procmail* variable.

--

-- 
Bob Holtzman
A fair fight is the result of poor planning.
Michelle Konzack | 1 Apr 2009 11:20

Re: procmail setup simple testing failure

Hello Juan,

Am 2009-03-31 09:15:47, schrieb Juan Martin:
> Hi,
> 
> My system environment is:
> 
> OS:Debian etch

Better is to switch to Lenny

> MAILDIR = $HOME/mail/

Should be:

MAILDIR=$HOME/mail
DEFAULT=$MAILDIR

> rc.testing
> #
> # testing rc
> #
> 
> :0 :

Maildir does not need locking

> * ^Subject:.*test
> testing/

(Continue reading)

Michelle Konzack | 1 Apr 2009 12:04

Re: Incorrect Resolution of $HOME Variable

Am 2009-03-31 14:25:33, schrieb James Butler:
> i.e. Why would procmail create Maildir folders in /home/user/Maildir/user,
> instead of just creating them in /home/user/Maildir?

This ERROR sound very logic to me since  you  have  defined  the  SYSTEM
default directory from

    /var/spool/mail/
to
    ${HOME}/Maildir/

which mean, instead of creating a

    /var/spool/mail/${USER}

you get the

    /home/${USER}/Maildir/${USER}

thing.  I am now using  procmail  since  over  9 years  in  a  bunch  of
different (and very complicated configurations) but  I  have  never  had
such error.

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant

(Continue reading)

James Butler | 1 Apr 2009 19:34

Re: Incorrect Resolution of $HOME Variable

> Am 2009-03-31 14:25:33, schrieb James Butler:
>> i.e. Why would procmail create Maildir folders in
>> /home/user/Maildir/user,
>> instead of just creating them in /home/user/Maildir?
>
> This ERROR sound very logic to me since  you  have  defined  the  SYSTEM
> default directory from
>
>     /var/spool/mail/
> to
>     ${HOME}/Maildir/
>
> which mean, instead of creating a
>
>     /var/spool/mail/${USER}
>
> you get the
>
>     /home/${USER}/Maildir/${USER}
>
> thing.  I am now using  procmail  since  over  9 years  in  a  bunch  of
> different (and very complicated configurations) but  I  have  never  had
> such error.
>
> Thanks, Greetings and nice Day/Evening
>     Michelle Konzack
>     Systemadministrator
>     24V Electronic Engineer
>     Tamay Dogan Network
>     Debian GNU/Linux Consultant
(Continue reading)

Charles Gregory | 1 Apr 2009 22:35

Re: Incorrect Resolution of $HOME Variable

On Wed, 1 Apr 2009, James Butler wrote:
> I had thought that this was true: default $HOME = /var/spool/mail/user

Actually, no THAT should never be true. $HOME should always in some way 
equate to the user's home directory. So $DEFAULT would = the above, but 
$home should *always* be the user's 'home' path from the password file
until you explicitly define it.

> modified $HOME = /home/user [my system shows this for 'echo $HOME'] 
> therefore: $HOME/Maildir/ = /home/user/Maildir/ But procmail does 
> something different, in my case: $HOME/Maildir/ = 
> /home/user/Maildir/user/Maildir/ This is my main question: Why would 
> procmail add the extra 'user' substructure when it comes time to deliver 
> a message?

The 'clue' comes in the repetition of "Maildir/". Clearly for this to 
happen, the word "Maildir" is REPEATED in TWO different specifications 
that are concatenated to make the final result. If $HOME is correct, then 
we must presume the concatenation occurs in steps:

$HOME + "Maildir/" + "user/" + "Maildir/"

With "user/" appearing in the middle, it can be said that some portion of 
procmail's logic has been 'convinced' that $HOME + "Maildir/" is of the 
same level of specification as "/var/spool/mail/". Procmail wants to 
append a "user/" then the specified folder, "Maildir/" from a third 
location.

So why does procmail think $HOME/Maildir/ is equivalent to 
/var/spool/mail? SELinux issues? chroot issues?
(Continue reading)

James Butler | 2 Apr 2009 01:20

Re: Incorrect Resolution of $HOME Variable

> Actually, no THAT should never be true. $HOME should always in some way
> equate to the user's home directory. So $DEFAULT would = the above, but
> $home should *always* be the user's 'home' path from the password file
> until you explicitly define it.

Of course, you are correct. $HOME comes from (in my case) /etc/passwd

> The 'clue' comes in the repetition of "Maildir/". Clearly for this to
> happen, the word "Maildir" is REPEATED in TWO different specifications
> that are concatenated to make the final result. If $HOME is correct, then
> we must presume the concatenation occurs in steps:
>
> $HOME + "Maildir/" + "user/" + "Maildir/"
>
> With "user/" appearing in the middle, it can be said that some portion of
> procmail's logic has been 'convinced' that $HOME + "Maildir/" is of the
> same level of specification as "/var/spool/mail/". Procmail wants to
> append a "user/" then the specified folder, "Maildir/" from a third
> location.
>
> So why does procmail think $HOME/Maildir/ is equivalent to
> /var/spool/mail? SELinux issues? chroot issues?

Excellent! This reflects what I am seeing with 'procmail -v':

Your system mailbox: $HOME/Maildir/user

Note that this is verbatim ... $HOME is presented exactly like that,
without being resolved.

(Continue reading)

zhang zhengquan | 3 Apr 2009 08:45
Picon

possible to procmail all existing fetched mails?

Dear procmail community,
I have a not functioning so well .procmailrc and I would like to try
to sort the mails already popped again. Could anyone give me some
pointers on this?

Thanks,

--

-- 
Zhengquan

Gmane