Re: [Dovecot] RFC 3516 - IMAP4 Binary Content Extension
Timo Sirainen пишет: On Mon, 2008-05-19 at 02:48 +0400, Anton Yuzhaninov wrote: Is Binary Content Extension (rfc3516) support planned? It's not in my near-term plans. Where are you planning on using it? Are there some clients that support it? It may be useful in loaded web-mail applications (base64 decoding implemented in C is more cpu/memory efficient than in perl or other web scripting language). And may be we will use this extension in the webmail for our free-mail service (http://mail.rambler.ru) Popular desktop clients AFAIK don't support rfc3516. Is it possible to write plugin for support this extension? -- WBR, Anton Yuzhaninov
[Dovecot] no bookeeping using public folders
Using dovecot 1.0.10. In the config:
namespace public {
separator = /
hidden = no
prefix = Flock/
location =
maildir:/home/baratin/PublicMaildir:CONTROL=~/Maildir/control/Flock:INDEX=/var/dovecot/index/%u/Flock
}
This should be a public mail folder owned by baratin, read only for
all other users. Every user has his/her own control and index area
related to this public folder. I have verified, they are owner and
group of the respective control and index area.
The problem, while using Thunderbird: The read only user can delete
messages or mark then read. But after a new session, all the messages
are still new. Of course, only baratin is the owner.
The problem, while using mutt and IMAP: mutt refuse to change any flag
because the folder is read only. Of course, this is correct.
My question: Why is no bookkeeping maintained for other users,
although every one has his/her own control and index structure ?
Thanks a lot !
Claude
Re: [Dovecot] imap-login processes
On Fri, 16 May 2008, Evaggelos Balaskas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I hope something like this could help you :
# Authentication Cache
auth_cache_size = 10240
auth_cache_ttl = 18000
This may have done the trick! The number of imap-login processes has been
holding around 60 all morning. In case there is a problem in the future I
tested the following script to truss the imap-login processes on Solaris:
for pid in `ps -ef | grep imap-login | grep -v grep | awk '{print $2}'`;
do
truss -o log.$pid -p $pid
done
sleep 20
kill `ps -ef | grep truss | grep -v grep | awk '{print $2}'`
During testing I didn't see anything out of the ordinary, mostly just
sleeping processes.
Thanks for the help everyone!
Bryan Polk
Unix Systems Administrator
Communication and Multimedia Services
FAMU-FSU College of Engineering
[EMAIL PROTECTED]
Re: [Dovecot] [OT] Webmail Recommendation
On fredagen den 11 januari 2008, Mike Brudenell wrote: Whatever you do, DON'T move to Maildir if you are using the Prayer webmail software! We have used Prayer here for many years with the UW IMAP server backend and first Berkeley, then later MBX, format mail folders. When we migrated new users to Dovecoe with Maildir folders we discovered that Prayer does NOT like Maildir folders. The reason is that Maildir folders are dual-purpose: each can contain any mix of messages and sub-folders. However Prayer is intrinsically designed to ONLY work with folders that can contain messages or subfolders, but NOT both. The author of Prayer has (partly thanks to my patches adding UTF-8 and IPv6 support) recently released version 1.1.0 of Prayer which supports dual-use folders out of the box. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) signature.asc Description: This is a digitally signed message part.
Re: [Dovecot] messages downloading repeatedly to mozilla/seamonkey pop3 client
Timo and Mark, It appears that my problem was due to our configuration of the user's several home directories - we had different usernames created for this individual, but two of the home directory definitions in /etc/passwd were unintentionally pointing to the same place, causing the dovecot index files to overwrite each other. We never caught it before using pop3d, because they don't keep index A silly mistake. Sorry to bother you and the mailing list with this - clearly user error. :) Thanks for all your help! Ben On Sat, May 10, 2008 at 1:51 PM, Ben Julian [EMAIL PROTECTED] wrote: Timo, Wow, thanks for checking back on this after all that time. I am actually still having problems, and just working around them by using a script to manually wipe out the inbox and index files for the user with the problem. I tried your suggestion of explicitly setting the mailbox location. It didn't seem to stop the problem, but it is hard to reproduce on demand. By sending the user a lot of forwarded mail, I was able to reproduce the issue once. I left it defined and tried Mark Sapiro's suggestion, adding pop3_lock_session = yes, and so far, so good. I won't really know until a few days of use have passed. I'll be sure to let the list know how it turns out. Thanks for the follow up, guys, totally unexpected. -Ben On Sun, May 4, 2008 at 10:35 AM, Timo Sirainen [EMAIL PROTECTED] wrote: Do you still have this problem? You could try setting mail_location explicitly to see if it changes anything (http://wiki.dovecot.org/MailLocation). On Tue, 2008-03-11 at 17:25 -0400, Ben Julian wrote: Timo, The user can't access the mailbox directly under normal use circumstances. He doesn't have a smb share setup to allow him access to the mbox file. As far as I know, the only program besides dovecot doing editing of the mail is spamassassin, but that happens before the mail is written to the mbox. Perhaps I am misunderstanding your question? -Ben On Mon, Mar 10, 2008 at 9:26 PM, Timo Sirainen [EMAIL PROTECTED] wrote: On Wed, 2008-03-05 at 15:17 -0500, Ben Julian wrote: Mar 3 10:37:00 servername dovecot: POP3(user): mbox sync: UID inserted in the middle of mailbox /var/mail/user (84873 84872, seq=2, idx_msgs=3) This is the main problem, these shouldn't happen. Can the user access the mailboxes directly? See http://wiki.dovecot.org/MboxProblems
Re: [Dovecot] child process killed with signal 11
On May 20, 2008, at 1:00 AM, Zbigniew Szalbot wrote: Hello, Today I have noticed such log entries May 19 23:57:32 relay dovecot: child 40857 (imap) killed with signal 11 I am using v. 1.0.13. Any idea what can be wrong? Dovecot does not die. It seems child processes are being killed. Could you get a gdb backtrace from the crashes? See http://dovecot.org/bugreport.html PGP.sig Description: This is a digitally signed message part
[Dovecot] Disallow folder delete
Is there a straightforward way to disallow the deletion of all IMAP mailboxes? I have a user who's deleted an important IMAP mailbox and I'm now recovering a recent copy from the backup. But I'd rather just blanket disallow all folder deletions. The user is using Thunderbird and this has happened more than once so I suspect Tbird is willing to let a folder get deleted too easily. Perhaps there was a delay in the confirmation dialog and the user clicked ahead and confirmed something he shouldn't have. I'm looking at http://wiki.dovecot.org/ACL and it looks like I should be able to use a group override to disallow x (mailbox delete) but the page says that groups aren't implemented, so I don't know how one says that nobody can do this for any mailbox. I'm using 1.2.rc15 from CentOS 5 (RHEL5 equivalent).
Re: [Dovecot] Disallow folder delete
On Monday, May 19, 2008 4:07 PM -0700 Kenneth Porter [EMAIL PROTECTED] wrote: I'm using 1.2.rc15 from CentOS 5 (RHEL5 equivalent). I think I'm misinterpreting the CentOS package's version number. The package is listed as: dovecot-1.0-1.2.rc15.el5.src.rpm I think that means 1.0 rc15 and RPM packaging version 1.2. From the package changelog: * Fri Dec 22 2006 Tomas Janousek [EMAIL PROTECTED] - 1.0-1.2.rc15 - reenabled GSSAPI (#220582) * Tue Nov 21 2006 Petr Rockai [EMAIL PROTECTED] - 1.0-1.rc15 - update to latest upstream, fixes a few bugs, plus a security vulnerability (#216510, CVE-2006-5973)
Re: [Dovecot] Disallow folder delete
On May 20, 2008, at 2:07 AM, Kenneth Porter wrote: Is there a straightforward way to disallow the deletion of all IMAP mailboxes? I have a user who's deleted an important IMAP mailbox and I'm now recovering a recent copy from the backup. But I'd rather just blanket disallow all folder deletions. The user is using Thunderbird and this has happened more than once so I suspect Tbird is willing to let a folder get deleted too easily. Perhaps there was a delay in the confirmation dialog and the user clicked ahead and confirmed something he shouldn't have. I'm looking at http://wiki.dovecot.org/ACL and it looks like I should be able to use a group override to disallow x (mailbox delete) but the page says that groups aren't implemented, so I don't know how one says that nobody can do this for any mailbox. Using global ACLs gets you closer at least. You can define: acl = vfile:/etc/dovecot/acls Then having /etc/dovecot/acls/.DEFAULT probably does something.. But I don't remember if it applies to all mailboxes or just those on the root level or what. I should look into this some day and make all of them possible. :) PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] RFC 3516 - IMAP4 Binary Content Extension
On May 19, 2008, at 9:59 AM, Anton Yuzhaninov wrote: Timo Sirainen пишет: On Mon, 2008-05-19 at 02:48 +0400, Anton Yuzhaninov wrote: Is Binary Content Extension (rfc3516) support planned? It's not in my near-term plans. Where are you planning on using it? Are there some clients that support it? It may be useful in loaded web-mail applications (base64 decoding implemented in C is more cpu/memory efficient than in perl or other web scripting language). And may be we will use this extension in the webmail for our free- mail service (http://mail.rambler.ru) Popular desktop clients AFAIK don't support rfc3516. Is it possible to write plugin for support this extension? I think a plugin would be possible, since it's possible to add dynamically more FETCH handlers using imap_fetch_handlers_register(). With v1.1 this is even easier because you can use lib-mail/message- decoder.h to have Dovecot decode the base64/qp parts. Hmm. Although it forces translating charset to UTF-8, which isn't wanted with BINARY. I guess that part could have been made optional in the API.. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Looking for suggestions: How to strip attachments from mails
Hi Jason, On Friday 16 May 2008, Jason Fesler wrote: I'm looking for a way to strip attachments from incoming mails on the server. http://detach.optimism.cc/ works in line with procmail or similiar. It is not a standalone server; but instead acts as a filter. I use it in front of my mailing lists, so that attachements are not sent out. Thank you very much for your suggestion. I gave 'detach' a try, and saw that you contributed to it :) It does exactly what I need. I set it up as a transport for postfix. The script that gets called by postfix also takes care about delivery (pipe through dovecot's 'deliver' after the detaching is finished, or, in case of an error during the detachment process, pipe the original message (including attachments) through 'deliver'. I didn't want to install procmail, because I need dovecot's sieve plugin for all other filtering needs... I've got one problem though (which I reported to Ryan Hamilton): detach doesn't handle attachments with filenames that contain non-ASCII characters well. I don't know anything about perl, so I didn't dig deeper yet... Would you perhaps be interested in looking into the issue? I couple this with demime to further reduce the remaining text to plain text ( http://scifi.squawk.com/demime.html - uh oh, host not responding.. and I don't see an alternate location for it). For me it's just about getting those attachments to some SAMBA share - the rest of the mail should stay as it was. Thanks again for that hint, Patrick. -- STAR Software (Shanghai) Co., Ltd.http://www.star-group.net/ Phone:+86 (21) 5427 7799 x 826 Fax: +86 (21) 6485 0071 PGP key: https://stshacom1.star-china.net/keys/patrick_nagel.asc Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005 signature.asc Description: This is a digitally signed message part.
Re: [Dovecot] Disallow folder delete
On 5/19/2008 Kenneth Porter wrote: I have a user who's deleted an important IMAP mailbox and I'm now recovering a recent copy from the backup. But I'd rather just blanket disallow all folder deletions. Thats pretty drastic - I'd have a rebellion on my hands if I tried that here. There's only so much you can do to protect people from their own stupidity. I'd say this is one thing you do NOT want to do - otherwise, you're gonna have people bugging you all the time to delete folders for them. I'm using 1.2.rc15 from CentOS 5 (RHEL5 equivalent). Actually, that would be 1.0rc15 - and it is way old, time to upgrade... atrpms.net has current versions...
Re: [Dovecot] Disallow folder delete
On Monday, May 19, 2008 9:43 PM -0400 Charles Marcus [EMAIL PROTECTED] wrote: Thats pretty drastic - I'd have a rebellion on my hands if I tried that here. The userbase is small, and I'd even be willing to set this up for one user were that to happen. Most users aren't that sophisticated and aren't creating folders in the first place. (Their inboxes tend to be horribly huge because of it.) I'm using 1.2.rc15 from CentOS 5 (RHEL5 equivalent). Actually, that would be 1.0rc15 - and it is way old, time to upgrade... atrpms.net has current versions... How hard is the upgrade? Just install the new RPM, or is there any configuration to update? (I'm currently using a pretty stock installation that uses mbox in /var/spool/mail (for inbox) and /home/user/mail. I did see 1.0.13 in Rawhide, so I figure I'd just grab the SRPM and build/package against the RHEL libraries.
