Re: [Dovecot] problem with virtual plugin/index files?
On Thu, 23 Aug 2012, Timo Sirainen wrote: On 18.8.2012, at 0.12, Lutz Preßler wrote: inthread refs younger 604800 This works as expected for the first time. But later on, also older messages/ threads are included until I delete the virtual/.week/dovecot.index*. [...] Situation with latest 2.1 is unchanged. But maybe it's easier to fix/ enhance now? Any estimate how much effort it would be? Just about the same amount of work I think. I haven't really looked at virtual plugin for a while, so I can't easily say how much work it would be. But my guess is that it wouldn't be easy. Thanks. To force MEMORY indexes only (with location option in namespace or forcibly - with warnings - by having empty index files for one mailbox chattr +i'ed (extended attributes immutable flag on Linux filesystems)) disables full text search indexing also. What about regular deletion of main index files. Is this a problem with FTS? doveadm fts rescan necessary, too? Btw, with 2.1 search results with or without fts indexes (solr,squat) differ in substring behaviour (http://wiki2.dovecot.org/Plugins/FTS/Squat). Namespaces with INDEX=MEMORY allow for a slow search view. But then no attachment content is searched... Lutz
Re: [Dovecot] Deleting metadata smashes file dovecot.dict
Hi Timo, [Timo Sirainen; Di 21 Aug 2012 12:22:04 CEST] Unfortunatly this can't be a fix because in file_set_size() dovecot defines an array 'char block[IO_BLOCK_SIZE]'. On the other hand the default block size is predestined for file ops. Does the attached patch fix it? (not a very good fix) No, it doesn't. Still got no response on large metadata and writing destroys the dictionary. Sorry for bumping - is there a chance to get it work with dovecot 2.1.7? TIA Andre
Re: [Dovecot] IMAP IDLE - iPhone?
On Thu, Aug 23, 2012 at 10:49 PM, Timo Sirainen t...@iki.fi wrote: Is there a reason why 172.16.0.0/12 was left out of the change ^^ ? Is it actually used? :) I've used 192.168 in my home network and all corporate networks I've seen have been 10/8. But yeah, I guess since there aren't more than those 3 I'll just add it (I thought there were more of them, but looks like they're reserved for other purposes). Yeah as others have mentioned - also not sure whether it is worth the effort to support IPv6's 'private' network (fc00::/7)? I havent seen anyone making use of this for their v6 enabled sites but others may have input here. thanks -- .warren
Re: [Dovecot] enabling per user quota plugin and problems with pop3
El 23/08/12 22:05, Timo Sirainen escribió:
On 20.8.2012, at 14.47, Angel L. Mateo wrote:
The origin of the problem why lmtp didn't use user's mail_plugin is
that I had it configured it in the pass_attrs option (and read with prefetch)
and not in user_attrs, so lmtp didn't get it.
But now the problem is that I can't configure mail_plugins redefinition
per user with 'quota,imap_quota' because when it is get it for lmtp, it
produces the error
Aug 20 13:38:30 myotis30 dovecot: lmtp(1086): Error:
dlopen(/usr/lib/dovecot/modules/lib11_imap_quota_plugin.so) failed:
/usr/lib/dovecot/modules/lib11_imap_quota_plugin.so: undefined symbol:
client_send_tagline
and if I configure mail_plugins redefinition with just 'quota' then it
is no applied for IMAP connections.
You can't do it with one passwd-file, you'd have to use multiple per-protocol
passwd files.. For example:
userdb passwd-file {
args = /etc/dovecot/passwd.%s
}
I have tried this option. It works, although I have to duplicate this
file.
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información _o)
y las Comunicaciones Aplicadas (ATICA) / \\
http://www.um.es/atica_(___V
Tfo: 868887590
Fax: 86337
[Dovecot] Size of Mailbox affecting the sending of mail?
Hi, I didn't know where to post this one so I'll start off with you guys and then try Postfix if I'm barking up the wrong tree! Having set up my mail server (Dovecot/Postfix), users are experiencing long delays (a couple of minutes) when sending mail from mail client such as Thunderbird - this increases with attachments. Having had a brief discussion with someone, they mentioned that the reason that this may be to do with the size of the mailbox. I couldn't see the rationale behind this unless Dovecot is syncing the mailbox after every sent mail (due to possibly saving the sent item?) The mail is being delivered successfully but the amount of time it is taking to complete the action is far too long! Sorry this is a bit vague but any advice on trying to diagnose the problem would be appreciated. Thanks in advance! Tim
Re: [Dovecot] IMAP IDLE - iPhone?
On Fri, 24 Aug 2012 10:10:42 +0200 Warren Baker articulated: Yeah as others have mentioned - also not sure whether it is worth the effort to support IPv6's 'private' network (fc00::/7)? I havent seen anyone making use of this for their v6 enabled sites but others may have input here. I would personally recommend supporting it. If history teaches us anything, it is that sooner or later, and usually sooner, someone will require that block. Being prepared for it in advance would seem like the prudent thing to do. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __
Re: [Dovecot] Size of Mailbox affecting the sending of mail?
Am 24.08.2012 12:53, schrieb Tim Smith: Hi, I didn't know where to post this one so I'll start off with you guys and then try Postfix if I'm barking up the wrong tree! Having set up my mail server (Dovecot/Postfix), users are experiencing long delays (a couple of minutes) when sending mail from mail client such as Thunderbird - this increases with attachments. Having had a brief discussion with someone, they mentioned that the reason that this may be to do with the size of the mailbox. I couldn't see the rationale behind this unless Dovecot is syncing the mailbox after every sent mail (due to possibly saving the sent item?) The mail is being delivered successfully but the amount of time it is taking to complete the action is far too long! Sorry this is a bit vague but any advice on trying to diagnose the problem would be appreciated. Thanks in advance! Tim sending mail ist usual smtp ( postfix ), not dovecot if no firewalls/proxies , slow lines , dns problems are involved, there may exist some policy or milter service which slows down smtp out from i.e tb, ask same question with logs and config in the postfix mail list size of mailbox should be not involved in this -- Best Regards MfG Robert Schetterer
Re: [Dovecot] Size of Mailbox affecting the sending of mail?
Thanks Robert. That's what I thought. I couldn't make the connection. Will try the Postfix list! On 24/08/12 12:06, Robert Schetterer wrote: Am 24.08.2012 12:53, schrieb Tim Smith: Hi, I didn't know where to post this one so I'll start off with you guys and then try Postfix if I'm barking up the wrong tree! Having set up my mail server (Dovecot/Postfix), users are experiencing long delays (a couple of minutes) when sending mail from mail client such as Thunderbird - this increases with attachments. Having had a brief discussion with someone, they mentioned that the reason that this may be to do with the size of the mailbox. I couldn't see the rationale behind this unless Dovecot is syncing the mailbox after every sent mail (due to possibly saving the sent item?) The mail is being delivered successfully but the amount of time it is taking to complete the action is far too long! Sorry this is a bit vague but any advice on trying to diagnose the problem would be appreciated. Thanks in advance! Tim sending mail ist usual smtp ( postfix ), not dovecot if no firewalls/proxies , slow lines , dns problems are involved, there may exist some policy or milter service which slows down smtp out from i.e tb, ask same question with logs and config in the postfix mail list size of mailbox should be not involved in this
Re: [Dovecot] IMAP IDLE - iPhone?
On 2012-08-24, at 7.01, Jerry je...@seibercom.net wrote: I would personally recommend supporting it. If history teaches us anything, it is that sooner or later, and usually sooner, someone will require that block. Being prepared for it in advance would seem like the prudent thing to do. I wonder whether it would be better to make the exclusion list configurable. As I understand it, the intention is to avoid treating connections through a load balancer or proxy as though they're the same client device. The assumption that private address = proxy is a fair default, but some sites will be using public addresses for their proxies. And that's only going to increase with IPv6. -- Matthew Powell matt...@atom.net
Re: [Dovecot] Size of Mailbox affecting the sending of mail?
Hi all, Having set up my mail server (Dovecot/Postfix), users are experiencing long delays (a couple of minutes) when sending mail from mail client such as Thunderbird - this increases with attachments. Having had a While in the first place sending e-mail has to do with SMTP and not IMAP, most mail client programs are configured to save a copy of an e-mail using FCC (file carbon copy) by putting this copy via IMAP into some Sent folder. And here you are: this may explain the long delays, esp. if on some asymmetric connection like DSL with low upstream bandwith. Just my 2c Cheers and have a nice weekend -- Dirk Jahnke-Zumbusch Deutsches Elektronen-Synchrotron DESY
Re: [Dovecot] IMAP IDLE - iPhone?
Am 24.08.2012 13:18, schrieb Matthew Powell: On 2012-08-24, at 7.01, Jerry je...@seibercom.net wrote: I would personally recommend supporting it. If history teaches us anything, it is that sooner or later, and usually sooner, someone will require that block. Being prepared for it in advance would seem like the prudent thing to do. I wonder whether it would be better to make the exclusion list configurable. As I understand it, the intention is to avoid treating connections through a load balancer or proxy as though they're the same client device i doubt the ip is generally the wrong value to define something is the same client device, there are millions of networks behind NAT out there with a lot of clients usually connecting to the same mailserver via the same public IP and many of them have a workstation beside a mobile device using the same IMAP account the same device = open connection, nothing else The assumption that private address = proxy is a fair default in my opinion this is generally the wrong direction i do NOT like it when server software behaves different from my private LAN where services are tested than later after making the service public from the WAN signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Size of Mailbox affecting the sending of mail?
Am 24.08.2012 13:35, schrieb Jahnke-Zumbusch, Dirk: Hi all, Having set up my mail server (Dovecot/Postfix), users are experiencing long delays (a couple of minutes) when sending mail from mail client such as Thunderbird - this increases with attachments. Having had a While in the first place sending e-mail has to do with SMTP and not IMAP, most mail client programs are configured to save a copy of an e-mail using FCC (file carbon copy) by putting this copy via IMAP into some Sent folder. And here you are: this may explain the long delays, esp. if on some asymmetric connection like DSL with low upstream bandwith. Just my 2c Cheers and have a nice weekend -- Dirk Jahnke-Zumbusch Deutsches Elektronen-Synchrotron DESY very true, but tb should show the copy action, unless its not configured not to do so -- Best Regards MfG Robert Schetterer
[Dovecot] quota: ignore deleted messages (?)
Hi! I am currently in the process of preparing a migration of our old Courier-based IMAP/POP server setup to a Dovecot-based one. During this process I came across the following problem with the difference Courier and Dovecot handle deleted messages and mail quota. Quote from http://www.courier-mta.org/imap/README.maildirquota.html: , | The default application configuration that uses this maildirquota | library does not count deleted messages, and any contents of the Trash | folder, against the quota. Messages that are marked as deleted (but not | yet actually removed), or messages that are moved to the Trash folder | (which is subject to automatic purging) do not count towards the set | quota. ` Ignoring the content (or increasing the quota) of the Trash folder is easy and no problem, but ignoring deleted messages seems impossible without changes to the code. While deleted messages are still stored on the server and still take up space until they are expunged, counting them against the quota is somewhat counter-intuitive because most clients don't show those mails and the normal user is unaware the mails he deleted are still there and take up space. Worse yet, if the client uses move-to-Trash, a user deleting mails will double the used space (until Expunge is used) and this may push him over his quota and thus cause any new mail delivery to fail. Unfortunately as our users are used to the courier way of handling the quota this will cause trouble after the migration. And this setup is run at a University, so I don't have any control over the clients a user uses and the behavior of said clients so I am not able to disable the move-to-Trash feature or force an immediate Expunge after a delete. So I propose an additional flag for the quota_rule config option to be able to enable a more lax interpretation of the quota enforcement: quota_rule = *:storage=1G:ignoredeleted quota_rule2 = Trash:storage=+100M Of course I would then have a nightly cronjob which force-expunges all deleted messages so that users can't store mails infinitely in their mailboxes. Thanks for your time and Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: [Dovecot] Size of Mailbox affecting the sending of mail?
On 8/24/2012 5:53 AM, Tim Smith wrote: Hay Tim, Having set up my mail server (Dovecot/Postfix), users are experiencing long delays (a couple of minutes) when sending mail from mail client such as Thunderbird - this increases with attachments. Having had a brief discussion with someone, they mentioned that the reason that this may be to do with the size of the mailbox. I couldn't see the rationale behind this unless Dovecot is syncing the mailbox after every sent mail (due to possibly saving the sent item?) The mail is being delivered successfully but the amount of time it is taking to complete the action is far too long! You probably have multiple factors involved in this mail sending delay issue. One may be that you're not bypassing your Postfix restrictions on your submission service. To fix this, disable your restrictions in the master.cf service definition of your submission service. For example: 587 inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o content_filter= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,\ permit_sasl_authenticated,reject -o receive_override_options=no_unknown_recipient_checks,\ no_address_mappings,no_header_body_checks This should squash any/all delays in Postfix submission. Another is the fact you're storing the users' Sent folders on the IMAP server. Typically there's nothing wrong with this. I do this and I see zero delay in Tbird. If a good portion of the delay you're seeing is Tbird copying messages to the Sent folder then I'd say you may have a duplex mismatch or some other network layer issue. What is the network topology between these client MUAs and the server? Full duplex fast ethernet? GbE? Or is the server at a remote location, say a colo/VPS server, and your clients are submitting over a shared ADSL/cable circuit to the server? If this is the case you'll always have substantial delays as the real outbound transmission rate of the best ADSL/cable circuits is only 500-1000 Kbps. Sending an attachment over such a pipe is always going to be slow, doubly so if you're copying to an IMAP Sent folder over the same connection, plus sharing it for web browsing, etc, amongst many users. If this is a SOHO environment with shared ADSL/cable the server needs to be on site, with clients connected via ethernet. This will allow instantaneous submission and Sent copying, while pushing the delay to the Postfix outbound queue, where it's invisible to your users. -- Stan
Re: [Dovecot] quota: ignore deleted messages (?)
On 24.8.2012, at 15.02, Sven Hartge wrote: Ignoring the content (or increasing the quota) of the Trash folder is easy and no problem, but ignoring deleted messages seems impossible without changes to the code. .. So I propose an additional flag for the quota_rule config option to be able to enable a more lax interpretation of the quota enforcement: quota_rule = *:storage=1G:ignoredeleted quota_rule2 = Trash:storage=+100M This can't be implemented race-condition-free without huge changes to code.
Re: [Dovecot] quota: ignore deleted messages (?)
Timo Sirainen t...@iki.fi wrote: On 24.8.2012, at 15.02, Sven Hartge wrote: Ignoring the content (or increasing the quota) of the Trash folder is easy and no problem, but ignoring deleted messages seems impossible without changes to the code. .. So I propose an additional flag for the quota_rule config option to be able to enable a more lax interpretation of the quota enforcement: quota_rule = *:storage=1G:ignoredeleted quota_rule2 = Trash:storage=+100M This can't be implemented race-condition-free without huge changes to code. Damn, too bad. I know for sure either my users or my 1st level support team are going to kill me if I don't find a solution. Is is possible to forcibly expunge a message at once, directly after a client has marked it as deleted? Kind of the opposite of the lazy_expunge plugin? Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: [Dovecot] quota: ignore deleted messages (?)
Am 24.08.2012 15:13, schrieb Sven Hartge: Timo Sirainen t...@iki.fi wrote: On 24.8.2012, at 15.02, Sven Hartge wrote: Ignoring the content (or increasing the quota) of the Trash folder is easy and no problem, but ignoring deleted messages seems impossible without changes to the code. .. So I propose an additional flag for the quota_rule config option to be able to enable a more lax interpretation of the quota enforcement: quota_rule = *:storage=1G:ignoredeleted quota_rule2 = Trash:storage=+100M This can't be implemented race-condition-free without huge changes to code. Damn, too bad. I know for sure either my users or my 1st level support team are going to kill me if I don't find a solution. Is is possible to forcibly expunge a message at once, directly after a client has marked it as deleted? Kind of the opposite of the lazy_expunge plugin? Grüße, Sven. hm perhaps as workaround http://wiki2.dovecot.org/Plugins/deleted-to-trash and do often http://wiki2.dovecot.org/Plugins/Expire via cron i.e doveadm expunge -A mailbox Trash savedbefore 1h -- Best Regards MfG Robert Schetterer
[Dovecot] Vpopmail Dynamic Authentication Module
Hello, We currently use qmail with vpopmail for e-mail and are looking to switch from courier-imap to dovecot for IMAP on our RedHat EL 5 systems. Our goal is to use the dovecot RPM supplied by RH (v1.0.7) if at all possible. We can do this if we are able to dynamically load the vpopmail auth module. The wiki (http://wiki.dovecot.org/CompilingSource) notes that this should be possible: Dovecot can also dynamically load authentication modules from the $prefix/lib/dovecot/auth/ directory. Binary packages builders should use them for authentication modules which require external libraries (e. g. LDAP and vpopmail). There is no standard way to build them as modules currently, but something like this should work: gcc -shared -fPIC -DHAVE_CONFIG_H -DUSERDB_VPOPMAIL -DPASSDB_VPOPMAIL \-I../.. -I../lib userdb-vpopmail.c passdb-vpopmail.c -o vpopmail.so \-lvpopmail I had to modify the command to build the module, but was able to successfully build it: gcc -shared -fPIC -DHAVE_CONFIG_H -DUSERDB_VPOPMAIL -DPASSDB_VPOPMAIL -I../.. -I../lib -I/home/vpopmail/include -I/home/vpopmail/lib userdb-vpopmail.c passdb-vpopmail.c -o vpopmail.so -L/home/vpopmail/lib/libvpopmail.a I am unable to get the module to load properly. Dovecot built with --with-vpopmail works perfectly. When I start dovecot and it tries to load the module it reports: Aug 23 16:48:18 ctd-nix1 dovecot: Dovecot v1.0.7 starting up Aug 23 16:48:18 ctd-nix1 dovecot: auth(default): dlopen(/usr/lib64/dovecot/auth/vpopmail.so) failed: /usr/lib64/dovecot/auth/vpopmail.so: undefined symbol: vclose Aug 23 16:48:18 ctd-nix1 dovecot: auth(default): dlsym(passdb_vpopmail) failed: dovecot-auth: undefined symbol: passdb_vpopmail Aug 23 16:48:18 ctd-nix1 dovecot: auth(default): Unknown passdb driver 'vpopmail' (typo, or Dovecot was built without support for it? Check with dovecot --build-options) Aug 23 16:48:18 ctd-nix1 dovecot: Auth process died too early - shutting down Sometimes instead the last line is replaced with: Aug 23 15:02:45 ctd-nix1 dovecot: child 5412 (auth) returned error 89 Thanks! Eric
Re: [Dovecot] Size of Mailbox affecting the sending of mail?
My next guess was the upstream data rate. My router states that the upstream is 10x slower than downstream so I guess this is the culprit. Time to move to a VPS methinks... On 24/08/12 13:50, Stan Hoeppner wrote: On 8/24/2012 5:53 AM, Tim Smith wrote: Hay Tim, Having set up my mail server (Dovecot/Postfix), users are experiencing long delays (a couple of minutes) when sending mail from mail client such as Thunderbird - this increases with attachments. Having had a brief discussion with someone, they mentioned that the reason that this may be to do with the size of the mailbox. I couldn't see the rationale behind this unless Dovecot is syncing the mailbox after every sent mail (due to possibly saving the sent item?) The mail is being delivered successfully but the amount of time it is taking to complete the action is far too long! You probably have multiple factors involved in this mail sending delay issue. One may be that you're not bypassing your Postfix restrictions on your submission service. To fix this, disable your restrictions in the master.cf service definition of your submission service. For example: 587 inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o content_filter= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,\ permit_sasl_authenticated,reject -o receive_override_options=no_unknown_recipient_checks,\ no_address_mappings,no_header_body_checks This should squash any/all delays in Postfix submission. Another is the fact you're storing the users' Sent folders on the IMAP server. Typically there's nothing wrong with this. I do this and I see zero delay in Tbird. If a good portion of the delay you're seeing is Tbird copying messages to the Sent folder then I'd say you may have a duplex mismatch or some other network layer issue. What is the network topology between these client MUAs and the server? Full duplex fast ethernet? GbE? Or is the server at a remote location, say a colo/VPS server, and your clients are submitting over a shared ADSL/cable circuit to the server? If this is the case you'll always have substantial delays as the real outbound transmission rate of the best ADSL/cable circuits is only 500-1000 Kbps. Sending an attachment over such a pipe is always going to be slow, doubly so if you're copying to an IMAP Sent folder over the same connection, plus sharing it for web browsing, etc, amongst many users. If this is a SOHO environment with shared ADSL/cable the server needs to be on site, with clients connected via ethernet. This will allow instantaneous submission and Sent copying, while pushing the delay to the Postfix outbound queue, where it's invisible to your users.
Re: [Dovecot] quota: ignore deleted messages (?)
Robert Schetterer rob...@schetterer.org wrote: Am 24.08.2012 15:13, schrieb Sven Hartge: Timo Sirainen t...@iki.fi wrote: On 24.8.2012, at 15.02, Sven Hartge wrote: Ignoring the content (or increasing the quota) of the Trash folder is easy and no problem, but ignoring deleted messages seems impossible without changes to the code. So I propose an additional flag for the quota_rule config option to be able to enable a more lax interpretation of the quota enforcement: quota_rule = *:storage=1G:ignoredeleted quota_rule2 = Trash:storage=+100M This can't be implemented race-condition-free without huge changes to code. Damn, too bad. I know for sure either my users or my 1st level support team are going to kill me if I don't find a solution. Is is possible to forcibly expunge a message at once, directly after a client has marked it as deleted? Kind of the opposite of the lazy_expunge plugin? hm perhaps as workaround http://wiki2.dovecot.org/Plugins/deleted-to-trash and do often http://wiki2.dovecot.org/Plugins/Expire via cron i.e doveadm expunge -A mailbox Trash savedbefore 1h I stumbled upon deleted_to_trash 5 minutes ago. This could work, if the code still works with dovecot 2.1. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: [Dovecot] quota: ignore deleted messages (?)
Sven Hartge s...@svenhartge.de wrote: Robert Schetterer rob...@schetterer.org wrote: Am 24.08.2012 15:13, schrieb Sven Hartge: Is is possible to forcibly expunge a message at once, directly after a client has marked it as deleted? Kind of the opposite of the lazy_expunge plugin? hm perhaps as workaround http://wiki2.dovecot.org/Plugins/deleted-to-trash and do often http://wiki2.dovecot.org/Plugins/Expire via cron i.e doveadm expunge -A mailbox Trash savedbefore 1h I stumbled upon deleted_to_trash 5 minutes ago. This could work, if the code still works with dovecot 2.1. Nope, does not compile (dovecot-dev headers are installed): cc\ -fPIC -shared -Wall \ -I/usr/include/dovecot \ -I/usr/include/dovecot/src \ -I/usr/include/dovecot/src/lib \ -I/usr/include/dovecot/src/lib-storage \ -I/usr/include/dovecot/src/lib-mail \ -I/usr/include/dovecot/src/lib-imap \ -I/usr/include/dovecot/src/lib-index \ -DHAVE_CONFIG_H \ deleted-to-trash-plugin.c -o lib_deleted_to_trash_plugin.so deleted-to-trash-plugin.c: In function ‘mailbox_open_or_create’: deleted-to-trash-plugin.c:79: error: ‘MAILBOX_FLAG_KEEP_RECENT’ undeclared (first use in this function) deleted-to-trash-plugin.c:79: error: (Each undeclared identifier is reported only once deleted-to-trash-plugin.c:79: error: for each function it appears in.) deleted-to-trash-plugin.c: In function ‘copy_deleted_mail_to_trash’: deleted-to-trash-plugin.c:136: warning: passing argument 1 of ‘mailbox_keywords_unref’ from incompatible pointer type /usr/include/dovecot/mail-storage.h:612: note: expected ‘struct mail_keywords **’ but argument is of type ‘struct mailbox *’ deleted-to-trash-plugin.c:136: error: too many arguments to function ‘mailbox_keywords_unref’ make: *** [lib_deleted_to_trash_plugin.so] Error 1 Grüße, Sven. -- Sigmentation fault. Core dumped.
[Dovecot] Trying to fix delete_to_trash plugin (was: quota: ignore deleted messages (?))
Sven Hartge s...@svenhartge.de wrote:
Nope, does not compile (dovecot-dev headers are installed):
OK, trying to fix this, without having any deeper knowlege of C
(anymore):
deleted-to-trash-plugin.c: In function ‘mailbox_open_or_create’:
deleted-to-trash-plugin.c:79: error: ‘MAILBOX_FLAG_KEEP_RECENT’ undeclared
(first use in this function)
MAILBOX_FLAG_KEEP_RECENT is not present in 2.1, seems to me it was made
the default and MAILBOX_FLAG_DROP_RECENT was introduced as its
counterpart.
I removed the flag from the call to mailbox_alloc() in
72 static struct mailbox *
73 mailbox_open_or_create(struct mailbox_list *list, const char *name,
74const char **error_r)
75 {
76 struct mailbox *box;
77 enum mail_error error;
78
79 box = mailbox_alloc(list, name, MAILBOX_FLAG_NO_INDEX_FILES);
80 if (mailbox_open(box) == 0) {
81 *error_r = NULL;
82 return box;
83 }
84
and retried to compile:
cc\
-fPIC -shared -Wall \
-I/usr/include/dovecot \
-I/usr/include/dovecot/src \
-I/usr/include/dovecot/src/lib \
-I/usr/include/dovecot/src/lib-storage \
-I/usr/include/dovecot/src/lib-mail \
-I/usr/include/dovecot/src/lib-imap \
-I/usr/include/dovecot/src/lib-index \
-DHAVE_CONFIG_H \
deleted-to-trash-plugin.c -o lib_deleted_to_trash_plugin.so
deleted-to-trash-plugin.c: In function ‘copy_deleted_mail_to_trash’:
deleted-to-trash-plugin.c:135: warning: passing argument 1 of
‘mailbox_keywords_unref’ from incompatible pointer type
/usr/include/dovecot/mail-storage.h:612: note: expected ‘struct mail_keywords
**’ but argument is of type ‘struct mailbox *’
deleted-to-trash-plugin.c:135: error: too many arguments to function
‘mailbox_keywords_unref’
make: *** [lib_deleted_to_trash_plugin.so] Error 1
_and_ now I am at the end of my wisdom. Pointer magic in C has always
been a dark dark mystery to me (I learned programming in Pascal, Ada95
and later Perl ...).
Help, anybody?
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
[Dovecot] Shared mdboxes
Hi Timo,
I'm trying to share two folders. The first one it's public and the other is per
user based, using acl's to control access etc . Dovecot create the folders, but
when I'll subscribe using ThunderBird client both of them seens like
watermarked and has a mailboxes folder inside. I can set up the acl's rules
using Thunderbird. Log files like mail.log don't show nothing in special and
mail.err has nothing.
Here is the config.
# 2.1.8 (b4cd382b6606): /etc/dovecot/dovecot.conf# OS: Linux 2.6.32-5-amd64
x86_64 Debian 6.0.5
/etc/dovecot/conf.d/10.mail.conf
namespace {type = publicseparator = .prefix = public.
location = mdbox:/var/mail_shares/public:INDEX=/var/mail_shares/public
subscriptions = no}namespace {type = sharedseparator = .
prefix = %h/sharedlocation = mdbox:%h/shared:INDEX=%h/shared
subscriptions = nolist = children}
Thanks, Wagner Azevedo
Re: [Dovecot] quota: ignore deleted messages (?)
On 24.8.2012, at 16.13, Sven Hartge wrote: quota_rule = *:storage=1G:ignoredeleted quota_rule2 = Trash:storage=+100M This can't be implemented race-condition-free without huge changes to code. Damn, too bad. I know for sure either my users or my 1st level support team are going to kill me if I don't find a solution. How about just disabling the quota enforcing and doing a nightly run of some type of enforcing (sending notification email and/or disabling new mail delivery until user has more quota again)?
Re: [Dovecot] quota: ignore deleted messages (?)
Timo Sirainen t...@iki.fi wrote: On 24.8.2012, at 16.13, Sven Hartge wrote: quota_rule = *:storage=1G:ignoredeleted quota_rule2 = Trash:storage=+100M This can't be implemented race-condition-free without huge changes to code. Damn, too bad. I know for sure either my users or my 1st level support team are going to kill me if I don't find a solution. How about just disabling the quota enforcing and doing a nightly run of some type of enforcing (sending notification email and/or disabling new mail delivery until user has more quota again)? As a last resort, yes. If possible, I'd like to keep the feedback about mailbox size as direct as possible. Disabling an account only once per night might be acceptable, but the reenabling of the account, once a user has freed some space, has to be instant or I would get constant complains from the users (the ones with the biggest mailboxes being the professors, which can be quite the pain to work with, if they believe they don't get what they think they are entitled to get). I know, this all sounds a bit whiny, but I've been working for over 8 years in this position and the harsh reality made me somewhat cautious. So far, the description of the delete_to_trash plugin sounds promising, because I can already ignore the Trash (or add to the total quota for this folder and do a nightly expunge run for it), if only it would compile for dovecot 2.1. Grüße, Sven. -- Sigmentation fault. Core dumped.
