Re: [Dovecot] dovecot.org moves to a new server
On Mon, May 21, 2007 at 10:04:11PM +0300, Timo Sirainen wrote: Yes, there were some problems with it. I think it should work now once DNS caches expire (max. 20h). Although I don't get it why the A record doesn't disappear from .org root servers. But looks like it doesn't cause problems there anyway. It's ok now, thanks! Geert
Re: [Dovecot] Replication plans
Hi list, OpenLDAP uses another strategy, which is more robust aka needs less fragile interaction between the servers. We have been thinking very long about replication. The requirement is to have a backup computing center in distant location, so replication has to work over a WAN connection (latency!) and must be able to recover from failures. This in mind we came to the conclusion that the strategy OpenLDAP is using would be the best to come up with and would be not too difficult to implement (we even started experiments which showed that this would be feasible). BTW, Oracle's replication mechanism (DataGuard) also works in a similar way, ie. by transferring the transaction logs to the backup and replaying them there. Cheers, Jörg
Re: [Dovecot] Quota handling - opportunity for new Feature?
On 5/22/2007 Charles Marcus ([EMAIL PROTECTED]) wrote: Now, obviously, this would all have to be configurable (I'm guessing this would all live in the Quota Plugin - or maybe it would be an alternate Quota plugin) - off by default, etc... Also, let me be clear... I am not the 'sys admin from hell'... what I am talking about are corporate situations where corporate policy *requires* quotas, and requires that they be enforced. Personally I don't like quotas - but, I do understand the reasons for them. I have one client that has users who regularly email themselves 25+MB messages with pictures of their kids, new house, dog licking himself - and end up with 5+GB of email, most of which is crap like this. Multiply this user times 50, or 100, or 1000 - and backups become really unwieldy, just so Jim can keep 5GB of pictures of his dog in his email. So, of *course* you would have rules in place to deal with the genuine situation where someone needs more storage, and you allow for this. But, if this FR were implemented (or even implementable), at least the users would have consistent, meaningful instructions that are automatically provided if/when they go over quota. Your over-quota status message could also inform them of the procedure for requesting additional storage. -- Best regards, Charles
Re: [Dovecot] Quota warning message ala courier
On Mon, 2007-05-21 at 08:49 +0200, Ralf Hildebrandt wrote: I have to face it, my users are retards: * either they're using crap MUAs which will not display their quota to them * or they're using POP with leave mail on server and will never notice their quota, unless it's too late * and once their quota is exceeded, their mails will bounce -- they'll never notice that, though. Thus I need a feature in dovecot that will tell them via email: Level1: You ALMOST exceeded your quota, you're at 90% now Level2: You're very close to exceededin your quota, you're at 95% now Level3: Would you please clean up now? You're at 99% now http://dovecot.org/patches/quota-warning.patch would do it, assuming you're not using filesystem quota. I'm not exactly sure how its configuration went. It's described somewhere in this mailing list. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Updated v1.1 and summer plans
Timo Sirainen wrote: Webmail.us will be sponsoring my Dovecot development for this summer. Other companies are also welcome to participate in the costs. Participation gets you: - listed in Credits in www.dovecot.org - listed in AUTHORS file - you can tell me how you want to use the feature and I'll make sure that it supports it (within reasonable limits) For already implemented v1.1 features, see http://www.dovecot.org/list/dovecot/2007-April/021974.html Some of those features require some more testing (new SORT and THREAD code especially) and a bit of fixes to mailbox list indexes. Otherwise I think it's working pretty well already, I've been using it for a long time for my own mails. Upcoming v1.1 features, more or less implemented in this order: what's the plan for the 1.0 series? it'll be 1.0.x release soon and ofter or ...? yours. -- Levente Si vis pacem para bellum!
[Dovecot] Courier migrating issues: indexes, maildirsize, update query
Hi, (my first post to the list) I'm in the process of testing Dovecot to see whether it meets our needs to replace our current Courier setup which serves well over 100.000 mailboxes (pop3 and imap: mysql with NFS) So far dovecot seems pretty straight forward; however I ran into a couple of things that I'm curious about. 1. What's the deal with dovecot.index/dovecot.index.log/dovecot.index.cache. I understand Dovecot uses this for POP3 primarily but this will no doubt cause a lot of overhead on our platform. Also getting this to work with our NFS setup would be a pain (locking etc.). I've been following this discussion: http://www.dovecot.org/list/dovecot/2006-January/thread.html#10758; and it ends with C. Malony suggesting that an disable index option would be in place; but no further action is taken. Basically I want to get rid of the index files (courier also doesn't use any). Any suggestions; will there be a disable-index option? 2. One of the reasons we want to get rid of Courier is because the maildirsize is often incorrect. Whether this is because of a bad Courier implementation or NFS issues or whatever, I haven't figured out yet. But I'd like to test this function in Dovecot; but there seems to be very little documentation. I read the link http://wiki.dovecot.org/Quota/Dict but this info is too scarce. Any pointers on where to go? 3. In our MySQL setup we have a field with the latest poptime and pophost (IP). This info can come in handy when troubleshooting or filtering out inactive mailboxes. With our Courier setup this field gets updated by a rather elaborate script that checks the logs and runs updates queries. I could get this to work for Dovecot; but with Dovecot being more actively in development, I wonder could this be a feature; like after a user_query, another update query? Cheers, Jan
[Dovecot] deliver rejection message
Currently the typical rejection message is: - Your message was automatically rejected by Dovecot Mail Delivery Agent. The following reason was given: Quota exceeded. - Then there is MDN + message headers in other MIME parts. But of course there sucky clients that can't display MDNs and users get confused. Any suggestions how to improve this message? I'm not sure if the Dovecot Mail Delivery Agent even needs to be in there. How about something like: - Your message to [EMAIL PROTECTED] was automatically rejected: Quota exceeded. See the attachment for the original message's headers. - And should I change this for v1.0.1 already? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] shared folders
On Tue, 2007-05-22 at 15:27 +0200, David Obando wrote: Dear all, I would like to use shared folders but I'm not quite sure whether Dovecot supports it the way I want it: -user A should be able to share a folder with users B, C, D -B, C and D should have read-access to this folder Did anyone implement shared folders like this? Dovecot v1.1 will have a better and easier support for shared mailboxes. But it should be possible to do what you want with v1.0 too: 1. Create symlinks to the shared maildir and make sure the filesystem permissions are wide enough so that all the users can read/write to the directories. 2. Enable ACL plugin and create dovecot-acl file limiting the users' access to read-only. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] need some help please
On Tue, 2007-05-22 at 08:39 -0700, Scott Silva wrote: Timo Sirainen spake the following on 5/22/2007 5:38 AM: On Mon, 2007-05-21 at 16:09 -0700, Scott Silva wrote: # Protocols we want to be serving: imap imaps pop3 pop3s # If you only want to use dovecot-auth, you can set this to none. #protocols = imap imaps pop3 pop3s /quote So this is NOT the default, although the conf file states such? Where did you get the config file? The default config file that comes in tarball is the same as in http://dovecot.org/doc/dovecot-example.conf and there's no pop3 in the protocols line. If some distribution changed that, it should be fixed. This was from an RPM created in one of the CentOS add-on packagers. I ran a dovecot -n against this being commented and un- commented and didn't see any difference. The packager must have found a way to change the defaults. Can that be done at compile time or could the code have been modified? Yes. So I guess the Centos package really changed the defaults and there's no problem. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Updated v1.1 and summer plans
On Tue, 2007-05-22 at 16:48 +0200, Farkas Levente wrote: what's the plan for the 1.0 series? it'll be 1.0.x release soon and ofter or ...? v1.0.1 will be released soon. I'm mostly just waiting to see if one user's problems go away with http://hg.dovecot.org/dovecot-1.0/rev/4e4572280ef1 If I don't hear back in a few days I guess I'll do the release. Well, now that you mentioned it I built also 1.0.1rc tarball for people to test: http://dovecot.org/tmp/dovecot-1.0.1rc.tar.gz It has only small changes so I don't think it can break anything. Other 1.0.x releases will come then if bugs are found. Probably even after v1.1.0. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Updated v1.1 and summer plans
On Tue, 2007-05-22 at 00:52 +0800, M1 wrote: Dear Timo, How about managedsieve? I think it'll have to wait for v2.0. Especially because I want it to be distributed in dovecot-sieve package, not in the main dovecot package. This just isn't possible without the larger changes that v2.0 brings. signature.asc Description: This is a digitally signed message part
[Dovecot] Quota handling - v2 - updated FR
This revised proposal for a Feature Request is the result of my desire to implement quotas, but not have the attendant headaches that inevitably accompany its implementation. Ralf Hildebrandt wrote: I have to face it, my users are retards: Is there any other kind of user? ;) snip Thus I need a feature in dovecot that will tell them via email: Level1: You ALMOST exceeded your quota, you're at 90% now Level2: You're very close to exceededin your quota, you're at 95% now Level3: Would you please clean up now? You're at 99% now What I'd *really* like to see implemented is something along the lines outlined below - but of course, this will depend entirely on whether or not Timo thinks it is doable - or desirable... I'm thinking this would be best handled by the Quota plug-in - either as part of the current one, or as a separate/different one... *** 1. Have a 'special' user-specific folder (by special, I mean like the Drafts, Sent, Templates folders) that dovecot controls. For purposes of this FR, call it the 'over-quota' folder. Question: could the .tmp folder be used for this? No sense in reinventing the wheel if necessary... and then if someone migrated from dovecot to something else, and messages were left in there from an over-quota condition, that other solution would most likely just move these to .new the first time it ran, right? Or, possibly, could dovecot create a new one maybe, .oqt (for over-quota), and store the queued messages there until the over-quota condition was rectified? Anyway, the main thing is, this folder should be essentially hidden from the user so they do *not* have access to it, and should temporarily hold messages that come in that are unable to be delivered due to an over-quota condition. *** 2. Make dovecot aware of and use a special 'Quota Status' message that it uses to inform a user that they are over quota. This message should be able to be customized, with variables (like, for example, it should list the messages that are currently being prevented from being moved to the Inbox - including, optionally, the Subject, the sender, date/time, attachments, size, etc - as well as provide general quota information (ie, how close to or over quota they are, and how much they'd need to delete or move to Local Folders to allow delivery of all of the messages being held), and lastly, any custom information the System Admin wanted to provide - like, maybe, specific instructions for how to move messages to Local Folders, how to request additional storage allowance, etc. *** 3. When user is over quota, have LDA deliver to the folder referenced above (# 1) - (yes, accept the message for final delivery from the sending mta), and then update the Quota Status message and move it to the Inbox. Optionally, a bounce/notification could be generated to the sender, informing them that their message is being 'held in queue' or something to that effect, due to the recipient being over-quota. *** 4. Once the user deletes enough mail to come back under quota, dovecot would then move messages from the 'over-quota' folder to his Inbox. Ok, again, am willing to hear *valid* reasons how/why this is a terrible idea... :) -- Best regards, Charles
Re: [Dovecot] dovecot + ldap tls
On Wed, 2007-05-23 at 13:58 +0300, Timo Sirainen wrote: dovecot: May 22 15:48:31 Error: auth(default): LDAP: ldap_start_tls_s() failed: Can't contact LDAP server Does it manage to get a TCP connection at all (check with eg. tcpdump), or is the error message just bad? I checked OpenLDAP's sources to see if there's any way to get usable error messages. Looks like the only way is to compile it with debugging enabled. Then it'll log everything to stderr. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] index-related crash in dovecot 1.0.0
Hi Timo, Timo Sirainen [EMAIL PROTECTED] schrieb am 16.05.2007 15:58:06: On Wed, 2007-05-16 at 13:44 +0200, [EMAIL PROTECTED] wrote: dovecot: 2007-05-16 13:30:09 Error: IMAP(6126360): file index-mail-headers.c: line 260 (index_mail_parse_header): assertion failed: (part != NULL) I'm still not sure how you managed to cause this, but I think this will fix it: http://dovecot.org/list/dovecot-cvs/2007-May/008821.html This patch fixes the issue. Thank you for your support. Jörg -- Sicherheit - Verfügbarkeit - Kontinuität - IT-Service-Management von ScanPlus GmbH Tel. +49 731 92013 150 Lise-Meitner-Straße 5, D-89081 Ulm, Germany Fax. +49 731 92013 29 150 Web: http://www.scan-plus.de/ Mail: [EMAIL PROTECTED] -
Re: [Dovecot] Courier migrating issues: indexes, maildirsize, update query
Hi Timo, Thanks a lot for the quick response (you sure are active on the list). I wasn't aware of the PostLoginScript option I will sure give this a try. So from what I understand Dovecot isn't there yet either when it comes to quota handling (maildirsize). I'll give it another thought on what will work best for us. About the indexes; this thoroughly confusing. I don't understand why Dovecot IMAP wants to use index files for a maildir++ implementation (this seems to defy the point of a maildir). Therefore I figured these files were used for POP3. But you made this clear now; that it is indeed used for IMAP. Still I can't get it to work (index=memory) this is my line: mail_location = maildir:/var/spool/mail/%1u/%2u/%u:INDEX=MEMORY I added INDEX=MEMORY later; all was working fine before. Now however IMAP or POP3 no matter what I do; the dovecot.index files are still generated. I kill the dovecot daemon; remove the index files, start the deamon and either way (POP3 or IMAP) the indexes will re-appear after connecting to a mailbox. (Note: this isn't a NFS caching thing). With a trace I can see these files are created: 9634 rename(/var/spool/mail/t/e/test-05/dovecot.index.log.newlock, /var/spool/mail/r/o/roka-05/dovecot.index.log) = 0 9634 rename(/var/spool/mail/t/e/test-05/dovecot.index.tmp, /var/spool/mail/r/o/roka-05/dovecot.index) = 0 9634 rename(/var/spool/mail/t/e/test-05/dovecot.index.cache.lock, /var/spool/mail/r/o/roka-05/dovecot.index.cache) = 0 Cheers, Jan -Oorspronkelijk bericht- Van: Timo Sirainen [mailto:[EMAIL PROTECTED] Verzonden: woensdag 23 mei 2007 13:39 Aan: Jan van den Berg CC: dovecot@dovecot.org Onderwerp: Re: [Dovecot] Courier migrating issues: indexes, maildirsize,update query On Wed, 2007-05-23 at 12:57 +0200, Jan van den Berg wrote: I'm in the process of testing Dovecot to see whether it meets our needs to replace our current Courier setup which serves well over 100.000 mailboxes (pop3 and imap: mysql with NFS) So far dovecot seems pretty straight forward; however I ran into a couple of things that I'm curious about. 1. What's the deal with dovecot.index/dovecot.index.log/dovecot.index.cache. I understand Dovecot uses this for POP3 primarily I guess you meant to say for IMAP, which is correct. but this will no doubt cause a lot of overhead on our platform. Yes, they bring a bit too much extra overhead for standard download +delete POP3 users. v1.1's indexes will work better with POP3 (and most likely also with NFS). Also getting this to work with our NFS setup would be a pain (locking etc.). I've been following this discussion: http://www.dovecot.org/list/dovecot/2006-January/thread.html#10758; and it ends with C. Malony suggesting that an disable index option would be in place; but no further action is taken. Basically I want to get rid of the index files (courier also doesn't use any). Any suggestions; will there be a disable-index option? Have you read http://wiki.dovecot.org/NFS? You can anyway disable indexes with appending :INDEX=MEMORY to mail_location setting, but it's probably not such a good idea. POP3 requires that the messages' virtual sizes are known. Dovecot initially calculates by reading the whole message's contents and then storing the size to dovecot.index.cache file. If you've disabled indexes, it means that all the messages' contents are read at the beginning of each POP3 session. Courier solves this by keeping the message sizes in courierpop3dsizelist file. I'm thinking about doing something similar for Dovecot v1.1 also. Alternative way would be to add the file's virtual size into the maildir filename itself (see ,W=vsize in http://wiki.dovecot.org/MailboxFormat/Maildir), but Dovecot doesn't add them internally (but it does use them if they exist) and I'm not sure how to configure other MDAs to do this. 2. One of the reasons we want to get rid of Courier is because the maildirsize is often incorrect. Whether this is because of a bad Courier implementation or NFS issues or whatever, I haven't figured out yet. But Dovecot's maildirsize implementation works like Courier's, so it's probable that it's just as broken with NFS: /* We rely on O_APPEND working in here. That isn't NFS-safe, but it isn't necessarily that bad because the file is recreated once in a while, and sooner if corruption causes calculations to go over quota. This is also how Maildir++ spec specifies it should be done.. */ I'd like to test this function in Dovecot; but there seems to be very little documentation. I read the link http://wiki.dovecot.org/Quota/Dict but this info is too scarce. Any pointers on where to go? Dict quota doesn't work very well with multiple simultaneous connections either with v1.0. This has already been fixed for upcoming v1.1 though. So, I don't think Dovecot's POP3 implementation is going to help you in any way. Some people are even using Dovecot IMAP +
Re: [Dovecot] Quota handling - v2 - updated FR
Charles Marcus wrote the following on 5/23/2007 4:30 AM -0800: This revised proposal for a Feature Request is the result of my desire to implement quotas, but not have the attendant headaches that inevitably accompany its implementation. Ralf Hildebrandt wrote: I have to face it, my users are retards: Is there any other kind of user? ;) snip Thus I need a feature in dovecot that will tell them via email: Level1: You ALMOST exceeded your quota, you're at 90% now Level2: You're very close to exceededin your quota, you're at 95% now Level3: Would you please clean up now? You're at 99% now What I'd *really* like to see implemented is something along the lines outlined below - but of course, this will depend entirely on whether or not Timo thinks it is doable - or desirable... I'm thinking this would be best handled by the Quota plug-in - either as part of the current one, or as a separate/different one... *** 1. Have a 'special' user-specific folder (by special, I mean like the Drafts, Sent, Templates folders) that dovecot controls. For purposes of this FR, call it the 'over-quota' folder. Question: could the .tmp folder be used for this? No sense in reinventing the wheel if necessary... and then if someone migrated from dovecot to something else, and messages were left in there from an over-quota condition, that other solution would most likely just move these to .new the first time it ran, right? Or, possibly, could dovecot create a new one maybe, .oqt (for over-quota), and store the queued messages there until the over-quota condition was rectified? Anyway, the main thing is, this folder should be essentially hidden from the user so they do *not* have access to it, and should temporarily hold messages that come in that are unable to be delivered due to an over-quota condition. Would seem to me that this would then require quota management over the .oqt folder. What happens if someone is on an extended vacation/leave-of-absence, or leaves the company or ISP and the account is not removed? The .oqt would continue to grow indefinitely. I guess one could implement a max .oqt folder size, but then that would duplicate what quota is already doing anyway. *** 2. Make dovecot aware of and use a special 'Quota Status' message that it uses to inform a user that they are over quota. This message should be able to be customized, with variables (like, for example, it should list the messages that are currently being prevented from being moved to the Inbox - including, optionally, the Subject, the sender, date/time, attachments, size, etc - as well as provide general quota information (ie, how close to or over quota they are, and how much they'd need to delete or move to Local Folders to allow delivery of all of the messages being held), and lastly, any custom information the System Admin wanted to provide - like, maybe, specific instructions for how to move messages to Local Folders, how to request additional storage allowance, etc. *** 3. When user is over quota, have LDA deliver to the folder referenced above (# 1) - (yes, accept the message for final delivery from the sending mta), and then update the Quota Status message and move it to the Inbox. Optionally, a bounce/notification could be generated to the sender, informing them that their message is being 'held in queue' or something to that effect, due to the recipient being over-quota. *** 4. Once the user deletes enough mail to come back under quota, dovecot would then move messages from the 'over-quota' folder to his Inbox. Ok, again, am willing to hear *valid* reasons how/why this is a terrible idea... :) I think a system that simply warns a user like Ralf outlined above seems a better solution to me, and is more resilient and less likely to cause admin headaches due to account maintenance oversights. Just my 2 cents... Bill
Re: [Dovecot] Courier migrating issues: indexes, maildirsize, update query
On Wed, 2007-05-23 at 14:36 +0200, Jan van den Berg wrote: About the indexes; this thoroughly confusing. I don't understand why Dovecot IMAP wants to use index files for a maildir++ implementation (this seems to defy the point of a maildir). Hmm. I suppose I should write a wiki page about the index files.. Done: http://wiki.dovecot.org/IndexFiles Still I can't get it to work (index=memory) this is my line: mail_location = maildir:/var/spool/mail/%1u/%2u/%u:INDEX=MEMORY I added INDEX=MEMORY later; all was working fine before. Now however IMAP or POP3 no matter what I do; the dovecot.index files are still generated. What do you use as userdb? If you return mail from there it overrides mail_location. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Updated v1.1 and summer plans
Timo Sirainen wrote: On Tue, 2007-05-22 at 00:52 +0800, M1 wrote: Dear Timo, How about managedsieve? I think it'll have to wait for v2.0. Especially because I want it to be distributed in dovecot-sieve package, not in the main dovecot package. This just isn't possible without the larger changes that v2.0 brings. Please do put a manageSIEVE interface formally on the roadmap. (I'd vote for v1.1, but I understand the technical issues that may push it to 2.0). SIEVE really isn't useful without a manageSIEVE interface or a shell. It would be very nice to have it in the official dovecot packages, rather than as an add-on developed by another group. The efforts of others who have added manageSIEVE support as a bolt-on are appreciated, but an official version would be preferable. Regards, - Brian
Re: [Dovecot] Quota handling - v2 - updated FR
Hi Bill, Anyway, the main thing is, this folder should be essentially hidden from the user so they do *not* have access to it, and should temporarily hold messages that come in that are unable to be delivered due to an over-quota condition. Would seem to me that this would then require quota management over the .oqt folder. No reason that this couldn't be configurable, but that isn't how I would implement it. The purpose of this - for me - is to insure that *no* mail is rejected or lost because of an over-quota condition. What happens if someone is on an extended vacation/leave-of-absence, or leaves the company or ISP and the account is not removed? I neglected to mention, but of course these quota status messages should also be provided to a designated admin account... The .oqt would continue to grow indefinitely. I guess one could implement a max .oqt folder size, but then that would duplicate what quota is already doing anyway. Just notify the admin. If the admin is so incompetent that they don't check their system logs and have themselves designated for being notified of conditions like this, then they're going to have many more problems than just a ever-growing .oqt directory. I think a system that simply warns a user like Ralf outlined above seems a better solution to me, and is more resilient and less likely to cause admin headaches due to account maintenance oversights. Well, definitely this is better in one sense - it is implementable now... :) But, one of my clients simply refuses to consider rejecting mail due to over quota - so, this is the only way I can think of to guarantee this for him - and, to be honest, I really like the idea of doing it the way I'm describing. It just seems cleaner, and provides more consistent and reliable end-user feedback/notification... But, no response from Timo yet so maybe he doesn't like the idea... ;) Anyway, thanks for your thoughts, -- Best regards, Charles
[Dovecot] Public Namespace and ACLs with pure virtual users
hi!
i would appreciate to have some comments on my below scenario:
# from the config
userdb static {
args = uid=vmail gid=mail home=/vmail/%d/%n
}
namespace public {
separator = /
prefix = All/
location = maildir:/vmail/%d/all/Maildir:CONTROL=~/Maildir/control/
all:INDEX=~/Maildir/index/all
inbox = no
hidden = no
}
namespace private {
separator = /
prefix =
location = maildir:~/Maildir
inbox = yes
hidden = no
}
# end config
the public namespace is also the maildir of the user [EMAIL PROTECTED].
a sieve skript is dropping mail for [EMAIL PROTECTED] to the appropriate
maildir within this maildir/namespace (e.g. .Support/)
first of all: this works to some point but is such a configuration
valid? can a public namespace be the maildir of a user?
if a new mail for [EMAIL PROTECTED] comes in, all subscribed users (of
this domain) can view it and it is marked as /Seen individually.
the important feature to me: the /Seen flags are managed per user as
configured in the public namespace
now the problem:
the whole mail system runs with one uid/gid and virtual users, which
has the effect that some user can delete mails in the public
namespace or drop mails into it, create folders etc. this is not
wanted. i wanted a read-only public namespace. so i decided to use
acls. as namespace prefixes are ignored i needed to create them
globally. my first try was:
/etc/dovecot/acls/Support:
owner lrwstiekxa
authenticated lr
which lead to the result that other users than [EMAIL PROTECTED] cannot
manipulate the public namespace at all, including setting their /Seen
flag. that was the first surprise to me as i thought this flag would
be managed seperately in the users homes.
after a (very short) thought i came to this (allow setting the /Seen
flag for others):
owner lrwstiekxa
authenticated lrs
which lead to another unexpected result: the /Seen flag is now set
globally. if one user marks a mail /Seen, it is /Seen for all other
users too.
where is the problem? except for the iso/osi layer 8 problem i am
aware of...
marc
Re: [Dovecot] May 21 09:13:14 mail dovecot: imap-login: No authentication sockets found
On Mon, 2007-05-21 at 22:31 +0300, Timo Sirainen wrote: On Mon, 2007-05-21 at 09:21 -0400, [EMAIL PROTECTED] wrote: I started getting this message this morning: May 21 09:13:14 mail dovecot: imap-login: No authentication sockets found .. What Dovecot version? The error message means that Dovecot's login_dir (/var/run/dovecot/login) was cleaned. A few other people have been having this problem, but I haven't yet found out any bugs in Dovecot that would cause it. Except before v1.0.rc29 if you tried to start Dovecot while it was already running it would do this. Actually I was wrong. I fixed it for dovecot -n and dovecot -a, but actually trying to start Dovecot while it's already running will wipe out the login directory. I'll go fix this for v1.0.1. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Quota handling - v2 - updated FR
This revised proposal for a Feature Request is the result of my desire to implement quotas, but not have the attendant headaches that inevitably accompany its implementation. Ralf Hildebrandt wrote: I have to face it, my users are retards: Is there any other kind of user? ;) snip Thus I need a feature in dovecot that will tell them via email: Level1: You ALMOST exceeded your quota, you're at 90% now Level2: You're very close to exceededin your quota, you're at 95% now Level3: Would you please clean up now? You're at 99% now What I'd *really* like to see implemented is something along the lines outlined below - but of course, this will depend entirely on whether or not Timo thinks it is doable - or desirable... I'm thinking this would be best handled by the Quota plug-in - either as part of the current one, or as a separate/different one... *** 1. Have a 'special' user-specific folder (by special, I mean like the Drafts, Sent, Templates folders) that dovecot controls. For purposes of this FR, call it the 'over-quota' folder. Question: could the .tmp folder be used for this? No sense in reinventing the wheel if necessary... and then if someone migrated from dovecot to something else, and messages were left in there from an over-quota condition, that other solution would most likely just move these to .new the first time it ran, right? Or, possibly, could dovecot create a new one maybe, .oqt (for over-quota), and store the queued messages there until the over-quota condition was rectified? Anyway, the main thing is, this folder should be essentially hidden from the user so they do *not* have access to it, and should temporarily hold messages that come in that are unable to be delivered due to an over-quota condition. *** 2. Make dovecot aware of and use a special 'Quota Status' message that it uses to inform a user that they are over quota. This message should be able to be customized, with variables (like, for example, it should list the messages that are currently being prevented from being moved to the Inbox - including, optionally, the Subject, the sender, date/time, attachments, size, etc - as well as provide general quota information (ie, how close to or over quota they are, and how much they'd need to delete or move to Local Folders to allow delivery of all of the messages being held), and lastly, any custom information the System Admin wanted to provide - like, maybe, specific instructions for how to move messages to Local Folders, how to request additional storage allowance, etc. *** 3. When user is over quota, have LDA deliver to the folder referenced above (# 1) - (yes, accept the message for final delivery from the sending mta), and then update the Quota Status message and move it to the Inbox. Optionally, a bounce/notification could be generated to the sender, informing them that their message is being 'held in queue' or something to that effect, due to the recipient being over-quota. *** 4. Once the user deletes enough mail to come back under quota, dovecot would then move messages from the 'over-quota' folder to his Inbox. Ok, again, am willing to hear *valid* reasons how/why this is a terrible idea... :) How is this different from just telling the customer there quota has been increased by the size of their .oqt box? Quota is there for a reason at my work, to stop accepting mail if the user already has too much mail. As we deal with customers, and can't just fire them for being too stupid, it is much better to give them a clear policy with no fuzzy grey areas. I think this also better in the case of the few employees I have to support as well. A hard bounce is the right way to go in this case, because it will let the sender know right away that there is a problem sending to the user. A soft bounce may take days of retrying before the sender is aware of a problem, especially since very few servers can handle a quota bounce at the smtp level. The recipient is probably going to be oblivious that a problem exists because if they are over quota, it usually means they haven't been checking their mail and will not see a quota warning message. 89% of the cases I see of users over quota, is due to negligence. 10% is for mailboxes that are no longer in use. I wouldn't think it a good idea to allocate extra disk space to either of these cases. The other 1% calls us to ask for more space which we gladly sell to them. -- Kenny Dail [EMAIL PROTECTED]
Re: [Dovecot] Quota handling - v2 - updated FR
How is this different from just telling the customer there quota has been increased by the size of their .oqt box? Because it hasn't - they can't GET this mail until they deal with their over-quota condition. All this does is prevent mail from being REJECTED, and provide a more consistent and effective way to communicate the problem to the user. Quota is there for a reason at my work, to stop accepting mail if the user already has too much mail. Currently, that is correct - but I have a customer who wants to ACCEPT the mail for delivery (ie, never, ever REJECT a message due to over-quota), but just not give it to the USER until they fix their quota problem. As we deal with customers, and can't just fire them for being too stupid, it is much better to give them a clear policy with no fuzzy grey areas. I think this also better in the case of the few employees I have to support as well. Funny - I see what I am proposing as being much *more* clear, with LESS fuzzy gray areas. A hard bounce is the right way to go in this case, because it will let the sender know right away that there is a problem sending to the user. This is your *opinion*. Personally, I disagree - but, of course, I would never force my way on you. As I have maintained, this should definitely be configurable - including the option of sending a notification to the sender that their message was accepted for delivery, but won't be delivered to the users Inbox until they fix their quota problem. This means all the sender has to do is call the user and tell them 'I sent you the message - it is waiting for you - fix your quota, idiot'... A soft bounce may take days of retrying before the sender is aware of a problem, Who is talking about soft bouncing? Did you even read my proposal? The recipient is probably going to be oblivious that a problem exists because if they are over quota, it usually means they haven't been checking their mail and will not see a quota warning message. True - but then they would be oblivious in either case, so I fail to see your point. 89% of the cases I see of users over quota, is due to negligence. Yep... and my way, no mail is lost or bounced, it is just held pending resolution of the over-quota condition, after which it is *immediately* delivered to their Inbox within SECONDS. 10% is for mailboxes that are no longer in use. Why are you leaving an account open that is no longer in use? Admittedly, for an ISP, this may not be a good thing to do - but not every mail system belongs to an ISP. I can see a lot of benefit to Corporate mail systems. I wouldn't think it a good idea to allocate extra disk space to either of these cases. So set the hard limit on the over-quota box. But for 95+% of cases, it would never get used. The other 1% calls us to ask for more space which we gladly sell to them. Obviously, you are selling mail services - so yes, I agree, this may not be a good fit for an ISP or someone selling mail services - but maybe you could comment on this from the perspective that not everyone would use it like you do... Do you seriously not see a benefit to a corporate user? I guess I'm just way off base here... Maybe I'll see if I can find someone willing to modify the Quot Plugin that exists now... -- Best regards, Charles
Re: [Dovecot] Updated v1.1 and summer plans
On Wed, 23 May 2007 08:59:29 -0500 Brian G. Peterson [EMAIL PROTECTED] wrote: Timo Sirainen wrote: On Tue, 2007-05-22 at 00:52 +0800, M1 wrote: Dear Timo, How about managedsieve? I think it'll have to wait for v2.0. Especially because I want it to be distributed in dovecot-sieve package, not in the main dovecot package. This just isn't possible without the larger changes that v2.0 brings. Please do put a manageSIEVE interface formally on the roadmap. (I'd vote for v1.1, but I understand the technical issues that may push it to 2.0). SIEVE really isn't useful without a manageSIEVE interface or a shell. I would like to request that this also be capable of being a proxy, similar to the pop/imap proxy. -- Marshal Newrock Ideal Solution, LLC - http://www.idealso.com
Re: [Dovecot] Courier migrating issues: indexes, maildirsize, update query
Jan van den Berg wrote: mail_location = maildir:/var/spool/mail/%1u/%2u/%u:INDEX=MEMORY Of interest to you might be using a scratch disk space to store the indexes on a/the local mail server; I just did a bit of math for you (well ok, a 'bc' script did the math) and with 90.5gigs of email in Maildir folders via NFS, we have 372megs of indexes on the local disks for performance gains. mail_location = maildir:~/Maildir:INDEX=/var/spool/dovecot/indexes/%1u/%u I'm not sure the space your 100K+ mailboxes take, but maybe you can use the above numbers to do some math and see if you can do indexes like that. -te -- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
Re: [Dovecot] deliver rejection message
2007. May 23., Timo Sirainen: Currently the typical rejection message is: - Your message was automatically rejected by Dovecot Mail Delivery Agent. The following reason was given: Quota exceeded. - Then there is MDN + message headers in other MIME parts. But of course there sucky clients that can't display MDNs and users get confused. Any suggestions how to improve this message? I'm not sure if the Dovecot Mail Delivery Agent even needs to be in there. How about Probably you're better off excluding Dovecot program information from this kind of bounces. See Postfix's Changelog[1]: [...] Major changes - delivery status notifications - [...] [Incompat 20060806] Postfix no longer announces its name in delivery status notifications. Users believe that Wietse provides a free help desk service that solves all their email problems. [...] something like: - Your message to [EMAIL PROTECTED] was automatically rejected: Quota exceeded. See the attachment for the original message's headers. - And should I change this for v1.0.1 already? [1] - ftp://postfix.cloud9.net/official/postfix-2.4.1.RELEASE_NOTES -- Daniel
[Dovecot] Will pay $500 towards a Dovecot feature
10 days ago I proposed this addition (see below) to Dovecot and got a lot of positive response. I would like to make it happen. I'm willing to contribute $500 to the development of this feature. It doesn't have to be implemented perfectly but needs to be workable to the extent that I can telnet into the Dovecot server and run it manually from the command line. I want to at least be able to run a simple script that I will write to add or remove someone from a black list text file. Timo has limited time but has indicated that he will allow it as a kind of undocumented feature (or wiki documented only). This is a sort of proof of concept feature and if it ever becomes a standard the standard will probably be different. However, we should implement it in a way that would be as close to a standard as possible. So - I'm looking for a programmer to make it happen. I'm also looking for others who might also kick in a few bucks as well if necessary. Here's the rough spec. -- Here's some thoughts I'd like to throw out there. I know it's not standard IMAP protocol but someone has to try new ideas first and I want to see what people (Timo) think of this. IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? The connection is made. It's a secure connection that's been authenticated. Lets use it! Here's my initial thoughts on this. Suppose we extended IMAP to include an EXECUTE command as follows: EXECUTE command parameter, parameter On the server side is a config file that has the commands that execute will allow and what programs they run. When the execute command is seen by Dovecot then Dovecot runs the program in the list with the parameters passed. For example, suppose there is a command to add a user to a server side blacklist. 100 execute blacklist add [EMAIL PROTECTED] 100 ok Dovecot would open a two way connection to the server application allowing the client to talk to any application that is configured and can send and receive text. The connection persists until the server end terminates or the client closes the connection. With a tool like this one can write generic applications easily that would greatly expand what email clients can do interacting with the server. Not only can setting be changes but you could interact with server side calendars, pick up voice messages from phone systems, run any sort of groupware, all over a generic IMAP connection with this simple extension. Example: 100 EXECUTE calendar 100 ok 100 list schedule today 8:00 10:00 100 8:00 make coffee 100 9:00 meeting with boss 100 9:30 Call Joe Blow at 415-555-1212 100 ok 100 quit 100 ok One thing I'd like to use it for is an outgoing SMTP connection to send outgoing email over IMAP. A session might look like this: 999 EXECUTE smtp 999 220 darwin.ctyme.com ESMTP Exim 4.67 Sun, 13 May 2007 06:52:26 -0700 999 helo ctyme.com 999 250 darwin.ctyme.com Hello localhost [127.0.0.1] 999 mail from:[EMAIL PROTECTED] 999 250 OK 999 rcpt to:dovecot@dovecot.org 999 250 Accepted .. 999 quit 999 OK Config File: There would have to be a config file that would be a table of what command run what. An example might look like this: calendar: /usr/bin/dovecot/calendar blacklist: /etc/exim/scripts/blacklist Probably might eventually want to add UID/GID and root directory restrictions for security. Login information and connection IP should be passed in the environment.
Re: [Dovecot] Will pay $500 towards a Dovecot feature
why not use ssh for that purpose ? On 5/23/07, Marc Perkel [EMAIL PROTECTED] wrote: 10 days ago I proposed this addition (see below) to Dovecot and got a lot of positive response. I would like to make it happen. I'm willing to contribute $500 to the development of this feature. It doesn't have to be implemented perfectly but needs to be workable to the extent that I can telnet into the Dovecot server and run it manually from the command line. I want to at least be able to run a simple script that I will write to add or remove someone from a black list text file. Timo has limited time but has indicated that he will allow it as a kind of undocumented feature (or wiki documented only). This is a sort of proof of concept feature and if it ever becomes a standard the standard will probably be different. However, we should implement it in a way that would be as close to a standard as possible. So - I'm looking for a programmer to make it happen. I'm also looking for others who might also kick in a few bucks as well if necessary. Here's the rough spec. -- Here's some thoughts I'd like to throw out there. I know it's not standard IMAP protocol but someone has to try new ideas first and I want to see what people (Timo) think of this. IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? The connection is made. It's a secure connection that's been authenticated. Lets use it! Here's my initial thoughts on this. Suppose we extended IMAP to include an EXECUTE command as follows: EXECUTE command parameter, parameter On the server side is a config file that has the commands that execute will allow and what programs they run. When the execute command is seen by Dovecot then Dovecot runs the program in the list with the parameters passed. For example, suppose there is a command to add a user to a server side blacklist. 100 execute blacklist add [EMAIL PROTECTED] 100 ok Dovecot would open a two way connection to the server application allowing the client to talk to any application that is configured and can send and receive text. The connection persists until the server end terminates or the client closes the connection. With a tool like this one can write generic applications easily that would greatly expand what email clients can do interacting with the server. Not only can setting be changes but you could interact with server side calendars, pick up voice messages from phone systems, run any sort of groupware, all over a generic IMAP connection with this simple extension. Example: 100 EXECUTE calendar 100 ok 100 list schedule today 8:00 10:00 100 8:00 make coffee 100 9:00 meeting with boss 100 9:30 Call Joe Blow at 415-555-1212 100 ok 100 quit 100 ok One thing I'd like to use it for is an outgoing SMTP connection to send outgoing email over IMAP. A session might look like this: 999 EXECUTE smtp 999 220 darwin.ctyme.com ESMTP Exim 4.67 Sun, 13 May 2007 06:52:26 -0700 999 helo ctyme.com 999 250 darwin.ctyme.com Hello localhost [127.0.0.1] 999 mail from:[EMAIL PROTECTED] 999 250 OK 999 rcpt to:dovecot@dovecot.org 999 250 Accepted .. 999 quit 999 OK Config File: There would have to be a config file that would be a table of what command run what. An example might look like this: calendar: /usr/bin/dovecot/calendar blacklist: /etc/exim/scripts/blacklist Probably might eventually want to add UID/GID and root directory restrictions for security. Login information and connection IP should be passed in the environment. -- DINH Viêt Hoà
Re: [Dovecot] Will pay $500 towards a Dovecot feature
On Wed, 2007-05-23 at 21:11 +0200, DINH Viêt Hoà wrote: why not use ssh for that purpose ? You wouldn't necessarily want all your users to ssh into your mail server, or deal with the configuration of that. Doing it through dovecot means it's already locked down to some point. I wonder if I could even create a '[EMAIL PROTECTED]' shell account... On 5/23/07, Marc Perkel [EMAIL PROTECTED] wrote: 10 days ago I proposed this addition (see below) to Dovecot and got a lot of positive response. I would like to make it happen. I'm willing to contribute $500 to the development of this feature. It doesn't have to be implemented perfectly but needs to be workable to the extent that I can telnet into the Dovecot server and run it manually from the command line. I want to at least be able to run a simple script that I will write to add or remove someone from a black list text file. I think it's a great idea. Rick
Re: [Dovecot] Will pay $500 towards a Dovecot feature
On May 23, 2007 11:54:20 AM -0700 Marc Perkel [EMAIL PROTECTED] wrote: IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? The connection is made. It's a secure connection that's been authenticated. Lets use it! Sounds like a job for ACAP. -frank
Re: [Dovecot] Quota handling - v2 - updated FR
This revised proposal for a Feature Request is the result of my desire to implement quotas, but not have the attendant headaches that inevitably accompany its implementation. snip Ok, seems there is no interest in doing this - and I do understand the objections... but how about a more consistent method for handling over quota conditions? This could be as simple as: *** 1. Make dovecot aware of and use a special 'Quota Status' message that it uses to inform a user that they are over quota. This message should be able to be customized, with variables (like, for example, it should list the messages that are bounced - including, optionally, the Subject, the sender, date/time, etc - as well as provide general quota information (ie, how close to or over quota they are, and how much they'd need to delete or move to Local Folders to get back below a certain level (again, configurable)), and lastly, any custom information the System Admin wanted to provide - like, maybe, specific instructions for how to move messages to Local Folders, how to request additional storage allowance, etc. *** 2. When user goes over quota, update the Quota Status message and move it to the Inbox. *** 3. While the user is over quota, every time a message to them is bounced, update the Quota Status message with the new information (append the details of the message just bounced, so they will have a complete list of messages that were bounced while they were over quota). Hmmm... I think I like this idea much better anyway... -- Best regards, Charles
Re: [Dovecot] May 21 09:13:14 mail dovecot: imap-login: No authentication sockets found
Thank you Timo. You are great:) 2007/5/23, Timo Sirainen [EMAIL PROTECTED]: On Mon, 2007-05-21 at 22:31 +0300, Timo Sirainen wrote: On Mon, 2007-05-21 at 09:21 -0400, [EMAIL PROTECTED] wrote: I started getting this message this morning: May 21 09:13:14 mail dovecot: imap-login: No authentication sockets found .. What Dovecot version? The error message means that Dovecot's login_dir (/var/run/dovecot/login) was cleaned. A few other people have been having this problem, but I haven't yet found out any bugs in Dovecot that would cause it. Except before v1.0.rc29 if you tried to start Dovecot while it was already running it would do this. Actually I was wrong. I fixed it for dovecot -n and dovecot -a, but actually trying to start Dovecot while it's already running will wipe out the login directory. I'll go fix this for v1.0.1.
Re: [Dovecot] deliver rejection message
Hi Timo would you like to add some localization for quota exceeded. I cannot find a way to localize the message Quota Exceeded Most of my clients dont know english. Maybe you may put these feature. Surely dovecot becomes more universal. Ps: I cannot modify the source codes. I am using compiled dovecot for some reason. 2007/5/23, Daniel [EMAIL PROTECTED]: 2007. May 23., Timo Sirainen: Currently the typical rejection message is: - Your message was automatically rejected by Dovecot Mail Delivery Agent. The following reason was given: Quota exceeded. - Then there is MDN + message headers in other MIME parts. But of course there sucky clients that can't display MDNs and users get confused. Any suggestions how to improve this message? I'm not sure if the Dovecot Mail Delivery Agent even needs to be in there. How about Probably you're better off excluding Dovecot program information from this kind of bounces. See Postfix's Changelog[1]: [...] Major changes - delivery status notifications - [...] [Incompat 20060806] Postfix no longer announces its name in delivery status notifications. Users believe that Wietse provides a free help desk service that solves all their email problems. [...] something like: - Your message to [EMAIL PROTECTED] was automatically rejected: Quota exceeded. See the attachment for the original message's headers. - And should I change this for v1.0.1 already? [1] - ftp://postfix.cloud9.net/official/postfix-2.4.1.RELEASE_NOTES -- Daniel
Re: [Dovecot] Will pay $500 towards a Dovecot feature
Yeah it is a great idea. For example with a good plugin which is used in a Webmail environment. Individual clients may submit spam mails to the email server with these imap extension and it will create self control against with the users of email server. 2007/5/23, Frank Cusack [EMAIL PROTECTED]: On May 23, 2007 11:54:20 AM -0700 Marc Perkel [EMAIL PROTECTED] wrote: IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? The connection is made. It's a secure connection that's been authenticated. Lets use it! Sounds like a job for ACAP. -frank
[Dovecot] How about a pipe plugin?
Hi,
I have written a plugin so that each time a message is added to a
specific box, a program is run and the message is piped into it. Note
that the message is also really added to the box.
I've been using it for nearly 3 month, for spam/ham learning, and have
not had any problem with it. I guess it could also be used to
implement an out box (I remember seeing someone asking for such a
feature on this list). Currently, I use it with a config like this:
(...)
namespace private {
separator = .
location = maildir:/var/mail/%u
inbox = yes
hidden = no
}
namespace public {
separator = .
prefix = learn.
location = maildir:/var/learn/%u
inbox = no
hidden = no
}
(...)
plugin {
(...)
pipe = /var/learn/%u/.spam:spamc -d some.host -L spam
pipe2 = /var/learn/%u/.ham:spamc -d some.host -L ham
(...)
}
Would people be interested by such a feature? If enough people show
some interest, I can try to convince my boss to let me release this
plugin GPL-licensed.
Cheers,
Nicolas Boullis
Re: [Dovecot] Will pay $500 towards a Dovecot feature
Marc Perkel, 23.05.2007 (d.m.y): IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? AFAIK, the M in IMAP stands for Mail, not for Calendar or Schedules. The connection is made. It's a secure connection that's been authenticated. You can also use LDAP and/or Kerberos to authenticate your users for other services - e.g. HTTP/WebDAV access to their Calendars, for managing their Sieve filters and so on. Thus, your proposal sounds to me a bit like reinventing the wheel. And I think that what we want is dovecot, not Exchange. Nevertheless, feel free to give me $500. ;-) Gruss/Regards, Christian Schmidt -- Always do right. This will gratify some people and astonish the rest. -- Mark Twain
Re: [Dovecot] Will pay $500 towards a Dovecot feature
funkypunky drunky wrote: Yeah it is a great idea. For example with a good plugin which is used in a Webmail environment. Individual clients may submit spam mails to the email server with these imap extension and it will create self control against with the users of email server. Yep - that is one of thousands of things it could be used for.
Re: [Dovecot] Will pay $500 towards a Dovecot feature
Frank Cusack wrote: On May 23, 2007 11:54:20 AM -0700 Marc Perkel [EMAIL PROTECTED] wrote: IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? The connection is made. It's a secure connection that's been authenticated. Lets use it! Sounds like a job for ACAP. It's rumoured to be the most complex Internet Engineering Task Force designed protocol ever... -- http://en.wikipedia.org/wiki/Application_Configuration_Access_Protocol
Re: [Dovecot] Will pay $500 towards a Dovecot feature
On 5/23/07, Rick Romero [EMAIL PROTECTED] wrote: On Wed, 2007-05-23 at 21:11 +0200, DINH Viêt Hoà wrote: why not use ssh for that purpose ? You wouldn't necessarily want all your users to ssh into your mail server, or deal with the configuration of that. And what about a chrooted environment ? By the was, I don't understand why a thunderbird plugin would not be able to do ssh :) -- DINH Viêt Hoà
Re: [Dovecot] Will pay $500 towards a Dovecot feature
On 5/23/07, David Jonas [EMAIL PROTECTED] wrote: Frank Cusack wrote: On May 23, 2007 11:54:20 AM -0700 Marc Perkel [EMAIL PROTECTED] wrote: IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? The connection is made. It's a secure connection that's been authenticated. Lets use it! Sounds like a job for ACAP. It's rumoured to be the most complex Internet Engineering Task Force designed protocol ever... -- http://en.wikipedia.org/wiki/Application_Configuration_Access_Protocol I thought it was the same for IMAP :) -- DINH Viêt Hoà
Re: [Dovecot] Quota handling - v2 - updated FR
This could be as simple as: *** 1. Make dovecot aware of and use a special 'Quota Status' message that it uses to inform a user that they are over quota. This message should be able to be customized, with variables (like, for example, it should list the messages that are bounced - including, optionally, the Subject, the sender, date/time, etc - as well as provide general quota information (ie, how close to or over quota they are, and how much they'd need to delete or move to Local Folders to get back below a certain level (again, configurable)), and lastly, any custom information the System Admin wanted to provide - like, maybe, specific instructions for how to move messages to Local Folders, how to request additional storage allowance, etc. *** 2. When user goes over quota, update the Quota Status message and move it to the Inbox. Or how about using a virtual folder instead (assuming they will be supported in Dovecot in the near future). It would work like this: 1) A read-only global folder called overquota (normally not accessible) contains one generic message saying that you are over quota and will not receive any new messages (with instructions on how to delete email to go under quota). 2) Using virtual folders, when a user goes over quota, the user's inbox is shown together (merged) with the read-only overquota folder. 3) When a user is back under quota, the inbox will go back to normal. Using this method, no additional disk space is required for writing over quota messages, so it would work with a hard quota or filesystem quota. On the filesystem is only one message (owned by an admin) that would be shown to everyone over quota - no need to have multiple copies of this message. Additionally, this method could be further developed and configured with a setting to warn users that they are almost at their limit (using a different virtual folder containing a you're at 95% or 99% of your quota message). Having a constant, new, important (flagged), un-deletable message in ones inbox would be a constant reminder that action needs to be taken. Scott Alter
Re: [Dovecot] Will pay $500 towards a Dovecot feature
On May 23, 2007 12:33:04 PM -0700 David Jonas [EMAIL PROTECTED] wrote: Frank Cusack wrote: On May 23, 2007 11:54:20 AM -0700 Marc Perkel [EMAIL PROTECTED] wrote: IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? The connection is made. It's a secure connection that's been authenticated. Lets use it! Sounds like a job for ACAP. It's rumoured to be the most complex Internet Engineering Task Force designed protocol ever... -- http://en.wikipedia.org/wiki/Application_Configuration_Access_Protocol hyperbole
[Dovecot] unexpected error message (maildir_sync_index)
Hello, I recently saw these errors in my log, and one of my users complained that Dovecot disconnected him unexpectedly. Any idea what might have happened? dovecot: Error: IMAP([EMAIL PROTECTED]): file maildir-sync.c: line 1075 (maildir_sync_index): assertion failed: (uid prev_uid) dovecot: Error: IMAP([EMAIL PROTECTED]): Raw backtrace: /usr/local/libexec/dovecot/imap [0x80b6501] - /usr/local/libexec/dovecot/imap [0x80b641c] - /usr/local/libexec/dovecot/imap(maildir_sync_index+0x902) [0x8069042] - /usr/local/libexec/dovecot/imap [0x8069243] - /usr/local/libexec/dovecot/imap(maildir_storage_sync_init+0x48) [0x8069428] - /usr/local/libexec/dovecot/imap(imap_sync_init+0x40) [0x8062590] - /usr/local/libexec/dovecot/imap(cmd_sync+0x71) [0x80626d1] - /usr/local/libexec/dovecot/imap(cmd_noop+0x26) [0x8059cc6] - /usr/local/libexec/dovecot/imap [0x805b878] - /usr/local/libexec/dovecot/imap [0x805b907] - /usr/local/libexec/dovecot/imap(_client_input+0x6c) [0x805bfbc] - /usr/local/libexec/dovecot/imap(io_loop_handler_run+0x120) [0x80bc7e0] - /usr/local/libexec/dovecot/imap(io_loop_run+0x28) [0x80bb808] - /usr/local/libexec/dovecot/imap(main+0x4b0) [0x8063fd0] - /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xc8) [0xb7e7eea8] - /usr/local/libexec/dovecot/imap [0x8056a11] dovecot: Error: child 8418 (imap) killed with signal 6 ~Kyle -- All we have to decide is what to do with the time that is given us. -- Gandalf the Grey pgpaQEEymB9pl.pgp Description: PGP signature
[Dovecot] Dovecot LDA and address extensions
I'm converting over a virtual user installation that used Postfix and
maildrop with a MySQL back-end for mailbox lookups to use Dovecot LDA.
The maildrop setup used a database table like:
+-++-++
| address | owner | domain | mailbox|
+-++-++
| [EMAIL PROTECTED] | tmetro | example.com | .admin.postmaster/ |
| [EMAIL PROTECTED]| tmetro | example.com | .admin.root.lex/ |
| [EMAIL PROTECTED] | tmetro | example.com | .INBOX/|
| [EMAIL PROTECTED] | tmetro | example.com | .spam.tmetro/ |
[...]
where maildrop was handed ${recipient} from postfix, and it queries the
above table matching ${recipient} to the address column, getting back
the expression CONCAT_WS('/','/var/mail',domain,owner) as the home
directory, and CONCAT_WS('/','/var/mail',domain,owner,mailbox) as the
mailbox. The UID/GID are fixed, as this is a virtual user setup.
So looking up the mailbox for the user [EMAIL PROTECTED] returns:
/var/mail/example.com/tmetro/.admin.postmaster/
Currently I'm using a static user database with Dovecot. This SQL
appears to replicate the maildrop setup:
user_query = SELECT CONCAT_WS('/','/var/mail',domain,owner) as home,
CONCAT_WS('/','maildir:/var/mail',domain,owner,mailbox) as mail,
5000 as uid, 5000 as gid FROM vmbx2 WHERE userid = '%u'
And this works for mail deliveries.
The problem with this is that not only is a database lookup overkill for
the IMAP server, as the root mail location for IMAP users follows a
simple pattern adequately represented by the static userdb, it also
breaks IMAP, because the returned 'mail' overrides mail_location,
(currently set to maildir:/var/mail/%d/%n/), so for user
[EMAIL PROTECTED] it returns:
maildir:/var/mail/example.com/tmetro/.INBOX/
instead of:
maildir:/var/mail/example.com/tmetro/
(which is the same as the home directory).
Can the userdb sql directive be added to the protocol lda section?
Or perhaps instead create a new auth lda section, and move the userdb
sql and socket listen directives to that section?
The second issue is how to best deal with address extensions, something
that wasn't fully implemented in the maildrop setup. Ideally I'd like a
setup where a lookup is first performed for [EMAIL PROTECTED], and if it
fails to return a mailbox, then lookup [EMAIL PROTECTED] Assuming Dovecot can
handle a multi-row query result (grabbing the first record and ignoring
the rest), this can probably be hacked using an appropriate WHERE
expression.
But the difficulty is getting the address components. Postfix will
provide them, but Dovecot's deliver doesn't seem to have a way of
receiving them and passing them on to the user query. The example LDA
setup shown here:
http://wiki.dovecot.org/LDA/Postfix
suggests passing the extension as an argument to the mailbox (-m)
switch. But this assumes that one wants a one-to-one direct mapping
between extensions and mailbox names.
I suppose I could switch from:
-d [EMAIL PROTECTED]
to:
-d ${recipient}
and add even more complexity to the SQL to parse out the extension. But
I'd rather avoid embedding the extension separator character in the SQL,
and would rather eliminate it from the database as well.
Maybe Sieve is the answer. I presume the argument to -m could be
inspected in a Sieve script, which could then map to the desired target
mailbox. The non-IMAP users (like [EMAIL PROTECTED]) could be
reimplemented as aliases that redirect to a [EMAIL PROTECTED] address
for the user responsible for that domain. But using Sieve scripts for
extension to mailbox mappings seems far less elegant than using a database.
Maybe I need to wedge a wrapper program between Postfix and deliver that
will accept the address components from postfix, perform the lookup, and
convert the results into a -d argument pointing to the owner (see
table above) and a -m argument pointing to the mailbox.
On a side note...
When I used this command in postfix's master.cf:
/usr/lib/dovecot/deliver -d [EMAIL PROTECTED] -n -m ${extension}
as recommended in the wiki, the following error gets logged:
... status=bounced (command line usage error. Command output: Fatal:
Unknown argument: -d Usage: deliver [-c config file]
[-d destination user] [-m mailbox][-f envelope
sender] )
which doesn't make a lot of sense. I suspect what it is trying to say is
that it didn't like something about the argument to the -d switch. Maybe
that should be ${domain} instead of ${nexthop}.
(What's up with all the whitespace between [-m mailbox] and [-f
envelope sender]? Also, might be a good idea to have deliver always
write errors - even startup errors - to the specified logging facility,
given that not all programs that launch it will report what it writes to
STDERR. I notice most postfix commands - even the
