I'm trying to configure listhandler to track the mailing lists I have setup with mailman, however I've run into a few problems.
The first of which is that I cannot figure out how mailhanlder/imap_open handles local mbox files, such as the ones mailman places (in Debian) in /var/lib/mailman/archives/private/[list].mbox/[list].mbox. I tried just putting that file in the "Folder" option for mailhandler, which saves so long as the webserver process user owns the file. However, if I try to use the retrieve function I get the following error:
warning: imap_open(): Couldn't open stream /var/lib/mailman/archives/private/announce.mbox/announce.mbox in /usr/share/drupal/modules/mailhandler.module on line 22.
I've also tried leaving off the filename, and just using the directory in the Folder option, but it produces the same results. Any ideas? List handler mentions mbox INBOX files as an option, but is that a typo? Is this even possible?
Comments
If the web server process can
If the web server process can't read the mbox then mailhandler can't either. Also, check that your version of PHP comes with imap support.
--
Drupal services
My Drupal services
I'm pretty sure I've met both
I'm pretty sure I've met both prerequisites.
Apache appears to run as www-data on Debian:
I have the file chmod'ed 666 and owned by www-data:
-rw-rw-rw- 1 www-data www-data 4.2K Mar 31 01:21 announce.mboxAnd I have php4-imap installed.
Also, if I print out imap_errors(), I get:
Can't open mailbox /var/lib/mailman/archives/private/announce.mbox/announce.mbox: no such mailboxDo you have to pass imap_open() a directory/folder, or should a mbox file work? I've tried looking through the php docs, but they only mention the ability to open mboxes, they don't actually give examples of how to.
I think the permissions of th
I think the permissions of the directory in which the mbox is located need to be considered, too. Also, mailman is rather picky about which permissions its files should have. I'd consider to copy the mbox file periodically to another, better accessible place and find a way that decides which messages are new. Or (and probably better) impelement a mailfilter (maybe based on procmail) that copies the mails to that list to a accessible folder.
--
Drupal services
My Drupal services
I made a directory within /va
I made a directory within /var/www (docroot) and copied the mbox there. I chmod 777'ed everything (including the directory) and tried to no avail. I even tried putting the mbox in /var/www but it produced the same results.
I'm putting
/var/www/mboxor/var/www/test/mboxin "Folder:" in the options for the mailbox, I'm assuming this is right?As I said, Apache runs as www-data, so I tried doing a
su www-dataand vi'ing the file, which works. I would think that would confirm that yes, the webserver can read and write the file.I can get past the configuration page where it checks the permissions on the file, it's the "retrieve" operation that it's failing on.
Do you, or anyone else for that matter, have this working somewhere? Has anyone else been able to confirm that, yes, mailhandler works with standard unix mbox files?
I think your permissions shou
I think your permissions should allow that operation
I had this working a while ago and the code didn't change that much recently. I also had added the option to use unix mailboxen to mailhandler. I still suspect that your imap support might not be present in some way. Check out phpinfo().
--
Drupal services
My Drupal services
'../configure' '--prefix=/usr
'../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs' '--with-regex=php' '--with-config-file-path=/etc/php4/apache' '--disable-rpath' '--enable-memory-limit' '--disable-debug' '--with-layout=GNU' '--with-pear=/usr/share/php' '--enable-calendar' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db4' '--with-iconv' '--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext' '--enable-mbstring' '--with-pcre-regex=/usr' '--enable-shmop' '--enable-sockets' '--enable-wddx' '--disable-xml' '--with-expat-dir=/usr' '--enable-yp' '--with-zlib' '--without-pgsql' '--with-kerberos=/usr' '--with-openssl=/usr' '--with-exec-dir=/usr/lib/php4/libexec' '--disable-static' '--with-curl=shared,/usr' '--with-dom=shared,/usr' '--with-dom-xslt=shared,/usr' '--with-dom-exslt=shared,/usr' '--with-zlib-dir=/usr' '--with-gd=shared,/usr' '--enable-gd-native-ttf' '--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6' '--with-png-dir=shared,/usr' '--with-freetype-dir=shared,/usr' '--with-imap=shared,/usr' '--with-imap-ssl' '--with-ldap=shared,/usr' '--with-mcal=shared,/usr' '--with-mhash=shared,/usr' '--with-mm' '--with-mysql=shared,/usr' '--with-unixODBC=shared,/usr' '--with-recode=shared,/usr' '--enable-xslt=shared' '--with-xslt-sablot=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr' '--with-ttf=shared,/usr' '--with-t1lib=shared,/usr'
IMAP
IMAP c-Client Version 2001
SSL Support enabled
Kerberos Support enabled
As far as I can tell imap support looks a-ok.
Well, then I am out if guesse
Well, then I am out if guesses. Sorry.
--
Drupal services
My Drupal services
Tis ok, I'm going to see if I
Tis ok, I'm going to see if I can find some way to get the mailman archives via pop3 or imap.
Resolution?
evan_d,
I'd really like to know if you solved your configuration problems? I'm struggling to get Mailhandler + Listhandler + Mailman configured to work together as well. I'm specifically trying to use the local mailman.mbox folders in the Mailhandler confuguration but continually am receiving:
warning: imap_open(): Couldn't open stream /var/lib/mailman/archives/private/discuss.mbox/ in /usr/share/drupal/modules/mailhandler.module on line 22.
and at ths same time:
Mailhandler could not access local folder: discuss@mydomain.com
Now, this appears to be a permissions problem, but I've made the folders world r/w for now just to see if that's the case and it doesn't appear to be.
Any help would be appreciated.
Thanks
imap_open can't open mbox files via absolute path?
I'm having the same problem. Investigating a little, it looks as though the PHP imap_open function is based on the UW c-client library. The docs for that (here) talk about a "black box" mode, in which an apparently absolute pathname would be interpreted as being relative to a mail folders directory. I'm wondering if that could be the problem, and that you'd either have to turn off black box mode, or figure out what c-client thinks is the mail folders directory and put a link to the mailbox there. I don't know how to configure c-client, though, since I'm not using any other part of the UW imap suite.
There are too many unknowns here for me, so for now I'm pretty much giving up and am busy setting up a dummy IMAP account to make it work. Seems like a waste, though.
If anyone knows how to make direct reading of mbox files work, please spill the beans!
mailhandler is a Drupal
mailhandler is a Drupal module. All its file actions are executed with the permissions of the webserver. It probably doesn't have access to the mailman mbox files. You need to copy them elsewhere.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Doesn't seem to be permissions
Just as evan_d did above, I've tried copying the mailbox file to the web server root (the same directory as drupal), as well as setting the permissions to 777 and, just for good measure, changing file ownership to www-data:www-data (the Apache user on Debian). None of that helped.
I've also tested with some PHP code which calls imap_open directly, which gives the same result. I can access mail folders via the IMAP server, but calling imap_open with an absolute pathname to a copy of a mailman mailbox (like "/var/www/mbox") fails.
This makes me wonder whether it's something to do with the c-client library on Debian (stable/sarge). Investigating that possibility, I found that the README that comes with the debian package includes the following:
I attempted to set the configuration option described to override this (in /etc/c-client.cf), but it didn't help. However, the whole issue of direct mbox support seems pretty iffy in the c-client library.
absolute path to mbox file requires recompile on Debian
OK, I can pretty much put this to rest now. PHP's open_imap function is based on the UW imap c-client library, and digging through the c-client sources for Debian stable/sarge, here's what I found:
As mentioned in my previous post, the Debian c-client package is built with a compile-time option which disables mbox file paths beginning with "/". They also are not allowed to contain "..", "//", or "/~" anywhere.
Although the Debian README claims that you can override this setting via a config file, /etc/c-client.cf, examining the sources indicates that the config option which allegedly supports this does not exist. (To be certain, I also checked using "strings" against the compiled library.)
Looking at the code related to the C variable which controls this setting makes it clear that there is no way, with the binary package, to override the compiled-in restriction. The only config option which does affect this setting, "set restrict-mailbox-access", can only increase the restrictions, not decrease them; but the maximum restrictions have already been compiled in.
In short, changing this setting requires compiling the c-client library from source.
Details for anyone who cares:
The C variable which controls this setting is "restrictBox" in src/osdep/unix/env_unix.c. In the original UW imap source, it's set as "restrictBox = NIL", but in a patch named 10_disallow_escaping_home.diff, Debian changes this to "restrictBox = -1".
The Debian README for the package mentions a config option "set restrictedBox", but no such config option exists in the code, not even in the Debian patches.
The only relevant option is "set restrict-mailbox-access", which is also handled in src/osdep/unix/env_unix.c. This code only sets bits in restrictBox, it doesn't ever clear them, so cannot be used to relax the restriction.
Finally, the code which validates the mailbox path and enforces the restriction is in the function "mailboxfile", also in env_unix.c.
Thanks!
Thanks, Ton, for your sleuthing. I was having an "imap_open(): Couldn't open stream" problem after Site5 replaced a crashed server with one that had a different (newer) build. Prior to this, absolute paths to the mailbox worked fine in Mailhandler, but they stopped working on the new server. The solution was to give Mailhandler a path relative to my "mail" folder, and to give it a POP3 port number of 110 (previously, "0" worked). Even though Site5 say they use CentOS Linux, not Debian, it looks like the same problem.
working now
hello,
thanks for your post. it works now. i did the following on debian gutsy
1. apt-get build-dep libc-client2002edebian
2. apt-get source libc-client2002edebian
3. cd uw-imap-2002edebian1
4. rm ./debian/patches/10_disallow_escaping_home.diff
5. dpkg-buildpackage
6. dpkg -i ../libc-client2002edebian_2002edebian1-13.2_i386.deb
7. added webserver user to mailman group (possibly potential security whole)
8. added a mailbox with the path settings (debian gutsy) /var/lib/mailman/archives/private/MAILBOXNAME.mbox/MAILBOXNAME.mbox
9. testing retrieval of messages works
thanks a ton again.
sebs
Having the same problem...
Has anyone resolved the "Mailhandler could not access local folder: discuss@mydomain.com" issue? I've been posting everywhere but no one is responding.
Help of any kind is greatly appreciated.
sort of solution
Hi,
having the same problem on a phplist installation, I found this post telling me this issue has to do with absolute path.
So I tried to use relative (to apache user's home) :
with "www-data" the apache user calling imap_open and "/var/www/" it's home directory.
Then
worked well.
Then I tried to soft link the real mailbox
Then
produces the warning
which is good enought for me.
WARNING: If you try this bad practice be SURE the mailbox is not accessible by any url !!! as apache user's home is mostly the default DocumentRoot...
I know this is dirty but i hope it helps someone before a better resolution.