courier-imap / procmail / SquirrelMail with IMAP subfolders.

I am having trouble setting up IMAP subfolders using courier-imap and
procmail. I'm using Debian (testing), courier-imap_4.1.1, procmail3.22. I'm
using SquirrelMail as a test IMAP client.

I would like to create a subfolder for all mail sent to a specific address
(say thing@example.com). I've used SquirrelMail to set up a new folder
(called "test1").

I've added the following to /etc/procmailrc:

:0
* ^TO.*thing
.test1/

and sent a test email to user "thing". This seems to have been delivered:

proxy:/home/paul/Maildir# ls -aR .test1
.test1:
. .. courierimapacl courierimapkeywords courierimapuiddb cur
maildirfolder new tmp

.test1/courierimapkeywords:
. ..

.test1/cur:
. ..

.test1/new:
. .. 1158149774.4533_0.proxy

.test1/tmp:
. ..

proxy:/home/paul/Maildir# cat .test1/*db
1 1158149650 1

Here is an extract of the procmail log:

procmail: Match on
"(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently (-Resent)?)-To):
(.*[^a-zA-Z])?).*thing"
procmail: Assigning "LASTFOLDER=.test1/new/1158149774.4533_0.proxy"
procmail: Notified comsat:
"paul@0:/home/paul/Maildir//.test1/new/1158149774.4533_0.pro xy"
From XXXXX@paulcager.org Wed Sep 13 13:16:14 2006
Subject: thing2


But when I try to look at the test1 folder in SquirrelMail I get an error:

ERROR: Could not complete request.
Query: FETCH (FLAGS UID RFC822.SIZE INTERNALDATE BODY.PEEK[HEADER.FIELDS
(Date To Cc From Subject X-Priority Importance Priority Content-Type)])
Reason Given: Error in IMAP command received by server.




I'm not sure what means; is procmail not creating the correct structure in
the Maildir? I'd be grateful for any help.


Here is a transcript of a telnet session I did, to try to gather some
diagnostic information.


proxy:~# telnet localhost 143
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP
ready.
Copyright 1998-2005 Double Precision, Inc. See COPYING for distribution
information.
a001 CAPABILITY
* CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS
a001 OK CAPABILITY completed
a002 LOGIN paul XXXXXXXX
a002 OK LOGIN Ok.
a003 NAMESPACE
* NAMESPACE (("INBOX." ".")) NIL (("#shared." ".")("shared." "."))
a003 OK NAMESPACE completed.
a004 EXAMINE INBOX
* FLAGS (NonJunk $Forwarded $Label1 \Draft \Answered \Flagged \Deleted \Seen
\Recent)
* OK [PERMANENTFLAGS ()] No permanent flags permitted
* 610 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1157659120] Ok
* OK [MYRIGHTS "acdilrsw"] ACL
a004 OK [READ-ONLY] Ok
a005 EXAMINE INBOX.test1
* FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS ()] No permanent flags permitted
* 1 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1158149650] Ok
* OK [MYRIGHTS "acdilrsw"] ACL
a005 OK [READ-ONLY] Ok

Re: courier-imap / procmail / SquirrelMail with IMAP subfolders.

Paul Cager wrote:
> I am having trouble setting up IMAP subfolders using courier-imap and
> procmail. I'm using Debian (testing), courier-imap_4.1.1, procmail3.22. I'm
> using SquirrelMail as a test IMAP client.
>
> I would like to create a subfolder for all mail sent to a specific address
> (say thing@example.com). I've used SquirrelMail to set up a new folder
> (called "test1").
>
> I've added the following to /etc/procmailrc:

Just as a comment:

/etc/procmailrc is the system global procmailrc file which normally is
run with root privileges, or at the very least with the same privileges
as your mail daemon. The mail daemon has to run as a privileged user so
that it can deliver messages to various users on the system and be able
to switch it's user id's to that of the recipient before delivery, or
before invoking a user space ${HOME}/.procmailrc file.

When you put a delivering recipe into the global procmailrc file,
procmail will normally drop privileges and switch it's user id to that
of the recipient user id if that can be determined. However if it can't
be determined what the local username should be, then I suspect that
procmail in this case will deliver the message, but might just leave the
ownership of the file set to that of "root" or whatever username your
mail daemon used when procmail was invoked.

A mail message addressed to "thing" would need a corresponding username
of "thing" on your system in order for procmail to drop privileges
before delivery. The username of "thing" could also be an alias that is
mapped to your username which would be fine. sendmail and/or procmail
would be able to determine the correct user in that case. There really
isn't enough information provided here to more than guess at what is
going on.

>
> :0
> * ^TO.*thing
> .test1/

This is telling procmail to deliver the message to a directory instead
of to a file. In this case, since procmail was not given a specific
filename to use for the delivery, procmail will make up a filename and
deliver the message to that. An example of this is in the procmail man
pages with the example of how to have procmail keep a backup delivery
cache of the last 500 or so messages.

If this directory happens to not look to procmail like a MAILDIR then it
will create on the fly some sub directories called "new", "tmp", and "cur".

procmail in this case will create a unique filename and place the
message in that filename under the "new" directory it just created. This
is done so that if mistakes are made, such messages will not be lost,
but you may have to do some digging to find the messages.

>
> and sent a test email to user "thing". This seems to have been delivered:
>
> proxy:/home/paul/Maildir# ls -aR .test1
> .test1:
> . .. courierimapacl courierimapkeywords courierimapuiddb cur
> maildirfolder new tmp
>
> .test1/courierimapkeywords:
> . ..

Empty directory, has nothing to do with procmail.

>
> .test1/cur:
> . ..

Empty directory, this one was created by procmail on the fly.

>
> .test1/new:
> . .. 1158149774.4533_0.proxy

A directory with one file in it. This is where your message landed. The
directory was created on the fly by procmail in this case.

>
> .test1/tmp:
> . ..

Empty directory, also created on the fly by procmail.

>
> proxy:/home/paul/Maildir# cat .test1/*db
> 1 1158149650 1

The contents of file: courierimapuiddb

The filename implies that it's a database of user id's used with imap,
it has nothing to do with procmail.

>
> Here is an extract of the procmail log:
>
> procmail: Match on
> "(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently (-Resent)?)-To):
> (.*[^a-zA-Z])?).*thing"
> procmail: Assigning "LASTFOLDER=.test1/new/1158149774.4533_0.proxy"

The LASTFOLDER assignment shows what filename the message was delivered
to. In this case that looks like

/home/paul/Maildir/.test1/new/1158149774.4533_0.proxy

I suggest cat that file to see if it contains your test message.

> procmail: Notified comsat:
> "paul@0:/home/paul/Maildir//.test1/new/1158149774.4533_0.pro xy"
> From XXXXX@paulcager.org Wed Sep 13 13:16:14 2006
> Subject: thing2
>
>
> But when I try to look at the test1 folder in SquirrelMail I get an error:

I'm not familiar with SquirrelMail, however if there is a permissions
issue such that SquirrelMail can't read the file because the file or the
directory that it's in isn't owned by your user account due to the
delivery method you used from the global procmailrc file, then I can see
where that might create some issues. It also may be just that since you
delivered the message to a directory instead of to a file folder,
SquirrelMail just doesn't know where to look for it.

I would need more information to be able to troubleshoot this further.
Based on what you've said so far, that is my best guess.

>
> ERROR: Could not complete request.
> Query: FETCH (FLAGS UID RFC822.SIZE INTERNALDATE BODY.PEEK[HEADER.FIELDS
> (Date To Cc From Subject X-Priority Importance Priority Content-Type)])
> Reason Given: Error in IMAP command received by server.
>

As a suggestion, you may be able to increase the level of log
information in your client which may shed some light on this. You'll
have to look in the documentation to see if you can do that. Most such
clients do have a method to do this sort of thing.

>
>
>
> I'm not sure what means; is procmail not creating the correct structure in
> the Maildir? I'd be grateful for any help.
>
>
> Here is a transcript of a telnet session I did, to try to gather some
> diagnostic information.
>

> [snip]

Hope this helps.

--
Regards
Garen

Re: courier-imap / procmail / SquirrelMail with IMAP subfolders.

On Wed, 13 Sep 2006, Paul Cager wrote:

PC>
PC> I've added the following to /etc/procmailrc:
PC>
PC> :0
PC> * ^TO.*thing
PC> .test1/
PC>
PC>
PC> But when I try to look at the test1 folder in SquirrelMail I get an error:
PC>

If you have delivered to a directory called ".test1", then the mail will
not be the directory called "test1"

--
Alan

( If replying by mail, please note that all "sardines" are canned.
There is also a password autoresponder but, unless this a very
old message, a "tuna" will swim right through. )

Re: courier-imap / procmail / SquirrelMail with IMAP subfolders.

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-19651-1158186235-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Paul Cager writes:

> But when I try to look at the test1 folder in SquirrelMail I get an error:
>
> ERROR: Could not complete request.
> Query: FETCH (FLAGS UID RFC822.SIZE INTERNALDATE BODY.PEEK[HEADER.FIELDS
> (Date To Cc From Subject X-Priority Importance Priority Content-Type)])
> Reason Given: Error in IMAP command received by server.
>
>
>
>
> I'm not sure what means; is procmail not creating the correct structure in
> the Maildir? I'd be grateful for any help.

It means that Squirrelmail has a bug, and sent an invalid IMAP command to
the server. The message sequence identifier list is missing from the FETCH
command, according to Squirrelmail's own logs.

Report this as a bug against Squirrelmail.


--=_mimegpg-commodore.email-scan.com-19651-1158186235-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBFCIT7x9p3GYHlUOIRAmWIAJ9M0pxYOLk5dhLMWKeYVBGOogXXfQCf ekv1
vA9WLZPUh4VoZw69+49PJgc=
=ZESL
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-19651-1158186235-0001--

Re: courier-imap / procmail / SquirrelMail with IMAP subfolders.

Garen Erdoisa wrote:
> Just as a comment:
>
> /etc/procmailrc is the system global procmailrc file which normally is
> run with root privileges, or at the very least with the same privileges
> as your mail daemon. The mail daemon has to run as a privileged user so
> that it can deliver messages to various users on the system and be able
> to switch it's user id's to that of the recipient before delivery, or
> before invoking a user space ${HOME}/.procmailrc file.
>
> When you put a delivering recipe into the global procmailrc file,
> procmail will normally drop privileges and switch it's user id to that
> of the recipient user id if that can be determined. However if it can't
> be determined what the local username should be, then I suspect that
> procmail in this case will deliver the message, but might just leave the
> ownership of the file set to that of "root" or whatever username your
> mail daemon used when procmail was invoked.
<>


Thank you - that was, indeed, the problem. The directories had been
created with the correct ownership, but procmail had created the file
with root ownership, so imap couldn't read it. I'm feeling a bit silly -
that was something I should have checked, but I had convinced myself
that the problem *must* have been with the IMAP conversation itself...

Thanks again.