Re: Sieve LDA Errors (Improper Saving?)
On 02/07/2017 06:51 PM, Stephan Bosch wrote: > Newer versions of Pigeonhole may use a different version of the compiled > binary format. So, for some upgrades it may be necessary to recompile. > Anyway, for now you should be helped by just manually recompiling. Manually recompiling fixed it. We had upgraded a while back, so the version difference could very well be the issue. Thanks! -- Richard
Sieve LDA Errors (Improper Saving?)
I'm getting lots of errors like this (possibly on every message delivery): imap2 dovecot: lmtp(rlaa...@wiktel.com): Error: OU02K+gQmFhUAwAAVtfydQ : sieve: binary save: failed to create temporary file: open(/var/lib/dovecot/sieve/junk-mail.svbin.ima p2.852.) failed: Permission denied (euid=500(vmail) egid=500(vmail) missing +w perm: /var/lib/dovecot/ sieve, dir owned by 0:0 mode=0755) imap2 dovecot: lmtp(rlaa...@wiktel.com): Error: OU02K+gQmFhUAwAAVtfydQ: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/var/lib/dovecot/sieve/junk-mail.sieve' need to be pre-compiled using the sievec tool It's intentional in my setup that the vmail user can't write to the global sieve script directory. But it shouldn't need to, as those are already pre-compiled: rlaager@imap2:/var/lib/dovecot/sieve$ ls -la total 12 drwxr-xr-x 2 root root 4096 Nov 29 22:27 . drwxr-xr-x 3 root root 4096 Feb 6 20:39 .. lrwxrwxrwx 1 root root 53 Sep 12 01:35 junk-mail.sieve -> /usr/share/wiktel-server-mail-backend/junk-mail.sieve -rw-r--r-- 1 root root 254 Nov 29 22:27 junk-mail.svbin rlaager@imap2:/var/lib/dovecot/sieve$ ls -la /usr/share/wiktel-server-mail-backend/junk-mail.sieve -rw-r--r-- 1 root root 124 Oct 31 09:34 /usr/share/wiktel-server-mail-backend/junk-mail.sieve Note that the .svbin is from November, while the text version is from October. Even if something is looking at the date of the symlink, that's from September. So the first question is... why is Dovecot trying to write the binary file? I dug into the Pigeonhole code... I think, but am certainly not sure, that lda_sieve_open() in pigeonhole/src/plugins/lda-sieve/lda-sieve-plugin.c is the relevant function calling lda_sieve_binary_save(). At the end of the function, it has: if (!recompile) lda_sieve_binary_save(srctx, sbin, script); This seems odd to me. Why is it trying to save in the "!recompile" case? It seems like it should be saving in the "recompile" case. If I'm reading this code right, recompile is set when it loads a corrupt sieve binary script and needs to recompile from text. I could be completely off, though. Any thoughts? -- Richard
Re: Dsync Header Hashing
On 04/12/2016 04:05 PM, Timo Sirainen wrote: I added it today: https://github.com/dovecot/core/commit/03af8e5325a7b4fec36414ac35949457bc426c0b Cool. And thanks for the awesome software! -- Richard
Re: Dsync Header Hashing
We've completed our migration to Dovecot (yay!), so this isn't critical
for me any more. But this change might still be a useful addition to
Dovecot. It doesn't create any non-standard behavior (like my patch for
non-atom flags).
On 03/07/2016 11:16 PM, Richard Laager wrote:
On 03/04/2016 08:52 AM, Timo Sirainen wrote:
On 04 Mar 2016, at 07:47, Richard Laager wrote:
Is there any way to disable the header hashing in dsync?
...
Does the attached patch happen to work? Compiles, but untested for now.
It works with one more change on top of your patch:
diff --git a/src/doveadm/dsync/dsync-mailbox-export.c
b/src/doveadm/dsync/dsync-mailbox-export.c
index 361cc55..0267f86 100644
--- a/src/doveadm/dsync/dsync-mailbox-export.c
+++ b/src/doveadm/dsync/dsync-mailbox-export.c
@@ -518,7 +518,7 @@ dsync_mailbox_export_init(struct mailbox *box,
p_array_init(&exporter->expunged_seqs, pool, 16);
p_array_init(&exporter->expunged_guids, pool, 16);
- if (!exporter->mails_have_guids)
+ if (!exporter->mails_have_guids && !exporter->no_hdr_hashes)
exporter->wanted_headers = dsync_mail_get_hash_headers(box);
/* first scan transaction log and save any expunges and flag changes */
--
Richard
diff --git a/src/doveadm/dsync/dsync-brain-mailbox.c b/src/doveadm/dsync/dsync-brain-mailbox.c
index 5dadf97..f71c7aa 100644
--- a/src/doveadm/dsync/dsync-brain-mailbox.c
+++ b/src/doveadm/dsync/dsync-brain-mailbox.c
@@ -322,6 +322,12 @@ int dsync_brain_sync_mailbox_open(struct dsync_brain *brain,
exporter_flags |= DSYNC_MAILBOX_EXPORTER_FLAG_TIMESTAMPS;
if (brain->hdr_hash_v2)
exporter_flags |= DSYNC_MAILBOX_EXPORTER_FLAG_HDR_HASH_V2;
+ if (remote_dsync_box->messages_count == 0) {
+ /* remote mailbox is empty - we don't really need to export
+ header hashes since they're not going to match anything
+ anyway. */
+ exporter_flags |= DSYNC_MAILBOX_EXPORTER_FLAG_NO_HDR_HASHES;
+ }
brain->box_exporter = brain->backup_recv ? NULL :
dsync_mailbox_export_init(brain->box, brain->log_scan,
diff --git a/src/doveadm/dsync/dsync-mailbox-export.c b/src/doveadm/dsync/dsync-mailbox-export.c
index c013eb0..361cc55 100644
--- a/src/doveadm/dsync/dsync-mailbox-export.c
+++ b/src/doveadm/dsync/dsync-mailbox-export.c
@@ -63,6 +63,7 @@ struct dsync_mailbox_exporter {
unsigned int minimal_dmail_fill:1;
unsigned int return_all_mails:1;
unsigned int export_received_timestamps:1;
+ unsigned int no_hdr_hashes:1;
};
static int dsync_mail_error(struct dsync_mailbox_exporter *exporter,
@@ -163,6 +164,10 @@ exporter_get_guids(struct dsync_mailbox_exporter *exporter,
if (!exporter->mails_have_guids) {
/* get header hash also */
+ if (exporter->no_hdr_hashes) {
+ *hdr_hash_r = "";
+ return 1;
+ }
if (dsync_mail_get_hdr_hash(mail, exporter->hdr_hash_version, hdr_hash_r) < 0)
return dsync_mail_error(exporter, mail, "hdr-stream");
return 1;
@@ -505,6 +510,8 @@ dsync_mailbox_export_init(struct mailbox *box,
(flags & DSYNC_MAILBOX_EXPORTER_FLAG_TIMESTAMPS) != 0;
exporter->hdr_hash_version =
(flags & DSYNC_MAILBOX_EXPORTER_FLAG_HDR_HASH_V2) ? 2 : 1;
+ exporter->no_hdr_hashes =
+ (flags & DSYNC_MAILBOX_EXPORTER_FLAG_NO_HDR_HASHES) != 0;
p_array_init(&exporter->requested_uids, pool, 16);
p_array_init(&exporter->search_uids, pool, 16);
hash_table_create(&exporter->export_guids, pool, 0, str_hash, strcmp);
diff --git a/src/doveadm/dsync/dsync-mailbox-export.h b/src/doveadm/dsync/dsync-mailbox-export.h
index c8f9548..02c6aa9 100644
--- a/src/doveadm/dsync/dsync-mailbox-export.h
+++ b/src/doveadm/dsync/dsync-mailbox-export.h
@@ -6,7 +6,8 @@ enum dsync_mailbox_exporter_flags {
DSYNC_MAILBOX_EXPORTER_FLAG_MAILS_HAVE_GUIDS = 0x02,
DSYNC_MAILBOX_EXPORTER_FLAG_MINIMAL_DMAIL_FILL = 0x04,
DSYNC_MAILBOX_EXPORTER_FLAG_TIMESTAMPS = 0x08,
- DSYNC_MAILBOX_EXPORTER_FLAG_HDR_HASH_V2 = 0x10
+ DSYNC_MAILBOX_EXPORTER_FLAG_HDR_HASH_V2 = 0x10,
+ DSYNC_MAILBOX_EXPORTER_FLAG_NO_HDR_HASHES = 0x20
};
struct dsync_mailbox_exporter *
[PATCH] imapc: Accept strings in FLAGS responses
While non-standard, the IMAP server we are replacing returns non-system
flags as strings instead of atoms.
Prior to this change, imapc would abort processing on the first message
with a string flag.
---
src/lib-storage/index/imapc/imapc-mailbox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/lib-storage/index/imapc/imapc-mailbox.c
b/src/lib-storage/index/imapc/imapc-mailbox.c
index c3e12d1..91333dc 100644
--- a/src/lib-storage/index/imapc/imapc-mailbox.c
+++ b/src/lib-storage/index/imapc/imapc-mailbox.c
@@ -310,7 +310,8 @@ static void imapc_untagged_fetch(const struct
imapc_untagged_reply *reply,
t_array_init(&keywords, 8);
seen_flags = TRUE;
for (j = 0; flags_list[j].type != IMAP_ARG_EOL; j++) {
- if (!imap_arg_get_atom(&flags_list[j], &atom))
+ if (!imap_arg_get_atom(&flags_list[j], &atom) &&
+ !imap_arg_get_string(&flags_list[j], &atom))
return;
if (atom[0] == '\\')
flags |= imap_parse_system_flag(atom);
--
2.1.4
Re: Dsync Header Hashing
On 03/04/2016 08:52 AM, Timo Sirainen wrote: > On 04 Mar 2016, at 07:47, Richard Laager wrote: >> Is there any way to disable the header hashing in dsync? ... > Does the attached patch happen to work? Compiles, but untested for now. It works with one more change on top of your patch: diff --git a/src/doveadm/dsync/dsync-mailbox-export.c b/src/doveadm/dsync/dsync-mailbox-export.c index 361cc55..0267f86 100644 --- a/src/doveadm/dsync/dsync-mailbox-export.c +++ b/src/doveadm/dsync/dsync-mailbox-export.c @@ -518,7 +518,7 @@ dsync_mailbox_export_init(struct mailbox *box, p_array_init(&exporter->expunged_seqs, pool, 16); p_array_init(&exporter->expunged_guids, pool, 16); - if (!exporter->mails_have_guids) + if (!exporter->mails_have_guids && !exporter->no_hdr_hashes) exporter->wanted_headers = dsync_mail_get_hash_headers(box); /* first scan transaction log and save any expunges and flag changes */ -- Richard
Dsync Header Hashing
Is there any way to disable the header hashing in dsync? I'm doing a one-time migration to Dovecot using imapc. The FETCHes for Date & Message-ID take a non-trivial amount of time and it's not clear to me if they have a function for a one-time migration. -- Richard
[Dovecot] Non-atomic Flags in APPEND
I'm using Evolution and Dovecot (on the localhost) and receiving these
errors trying to move a message into the IMAP folder:
C00095 APPEND INBOX (\Answered \Seen NotJunk "Junk" "NotJunk"
"receipt-handled") {1022}
C00095 BAD Error in IMAP command APPEND: Flags list contains non-atoms.
Is this a Dovecot or Evolution bug?
Thanks,
Richard
$ dovecot -n
# 1.1.11: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.28-11-generic i686 Ubuntu 9.04
log_timestamp: %Y-%m-%d %H:%M:%S
login_dir: /var/run/dovecot/login
login_executable: /usr/lib/dovecot/imap-login
mail_privileged_group: mail
mail_location: mbox:~/Private/mail
auth default:
passdb:
driver: pam
userdb:
driver: passwd
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] Permanent roadmap page on web
On Tue, 2008-01-01 at 19:52 +0200, Timo Sirainen wrote: > I'd want two things from BTS related to this: > > 1) It needs to be bidirectional: anyone on this mailing list must be > able to reply to the mail from BTS and the reply must be added to BTS. > What BTSes support this? The only thing I can speak to personally is Debian's bug tracker, which supports this. This might be helpful, though it's a bit of a mess: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems Richard signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Permanent roadmap page on web
On Sun, 2007-12-30 at 07:41 +0200, Timo Sirainen wrote: > Most replies to that mail ignored the 3) part, which is > the main reason there's no issue tracker yet. Regarding your three issues: 1. Yes, they all suck in different ways. You have to pick one with the least suck for you. ;) 2. If you need hosting with PHP and MySQL, contact me off-list and I might (but no promises just yet) be able to help. 3. What if you setup bug mails to come to this list? Richard signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Wiki license
On Sun, 2007-12-16 at 21:52 +0100, Marcus Rueckert wrote: > On 2007-12-16 22:43:18 +0200, Timo Sirainen wrote: > > a) GNU Free Documentation License > > > > b) Creative Commons (Attribution-Share Alike?) > > > > It could also be dual-licensed to both to maximize the distribution > > possibilities. > > CC Share Alike 3 > > GFDL has some sucking part about the license when using parts of the > documentation. I'm not sure if this would matter or not, but... Debian has previously said that the CC licenses are not DFSG-free. From what I can see, no opinion has been released on the version 3 licenses. See: http://wiki.creativecommons.org/Version_3#Debian A dual-license of GFDL (without invariant sections) and CC SA 3 should be okay with Debian, though. (I'm not a DD and am not speaking for the project.) Dovecot is MIT & LGPL, so why not choose one of those? The only down-side of an MIT license is that someone could take the work and put it into a non-free product. With documentation, the biggest potential problem would be someone making a Dovecot book. If you're not worried about that, really a Public Domain declaration should work. Here's what Wikipedia uses: This [content] has been released into the public domain by its author, [NAME]. This applies worldwide. In some countries this may not be legally possible; if so: [NAME] grants anyone the right to use this work for any purpose, without any conditions, unless such conditions are required by law. Richard signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Spliting Folders for Efficiency
On Sat, 2007-10-13 at 09:25 +0100, Daniel W wrote: > Is it also true that to read a single message > in a 800MB mbox, you need to load 800MB of data into memory which is > then searched for that message? Of course not! That's what an index is for. Richard signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot shared mailbox folder problem
On Thu, 2007-07-05 at 17:43 +0300, Timo Sirainen wrote: > On Wed, 2007-07-04 at 16:50 +0200, Steffen Kaiser wrote: > > drwxrws--- 5 31045 30005 4096 2007-07-04 15:53 ./ > > drwxrwsr-x 2 31045 30005 4096 2007-06-21 12:19 cur/ > > The setuid-group bit hides group-x bit. The only thing I can think of is > cur/ isn't group-executable. With GNU ls at least, that would appear as rwS instead of rws. Richard signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot waking every 50ms when doing nothing
On Sun, 2007-06-03 at 13:48 -0400, Dave McGuire wrote: >That's not to say that simply adding one dependency on glib would > cause a huge problem...but it indicates the adoption of a mindset, > and it's a slippery slope. The same applies to duplicating code in the interest of avoiding dependencies. Richard signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot waking every 50ms when doing nothing
On Sun, 2007-06-03 at 18:48 +0300, Timo Sirainen wrote: > I've used GLib before. The biggest problem I see with it is that it > doesn't support memory pools. That's why I duplicated most of its useful > functionality originally instead of just using it directly. So I think > it's much better to fix Dovecot's main loop code to work better instead > of adding a dependency to GLib and using only a tiny part of it. Are they against adding memory pools? Richard signature.asc Description: This is a digitally signed message part
Re: [Dovecot] CVS to Mercurial switch
On Sat, 2007-05-19 at 22:31 +0300, Timo Sirainen wrote: > On Sat, 2007-05-19 at 14:05 -0500, Richard Laager wrote: > > On Sat, 2007-05-19 at 20:32 +0300, Timo Sirainen wrote: > > > SVN is centralized, Mercurial is distributed. Distributed version > > > control systems allow a lot of nice things. > > > > Also curious here... Why Mercurial vs. TLA (I think that's what they're > > calling arch now?), > > Last I checked Arch / TLA seemed too complex. I've never played with that one. > > Darcs, > > It has its own weird diff format (don't know if you could disable it) > and it can use a lot of memory. Our beef with Darcs was that some operations take FOREVER to complete. We couldn't wait for the heat death of the universe to get our old history imported. > > Monotone, > > I had forgotten it even existed. We're using this for Pidgin, which is why I asked. > It seems a bit kludgy with all of its different commands and scripts. I tend to agree with this. > Also I don't really like its code. It's using standard C functions for > string manipulations and in general it's using a lot with fixed size > buffers. I should start diving into the Dovecot code and learn something. ;) > Anyway, I wanted to use a version control system that I knew was going > to be usable now and would be around for a while. Mercurial seems to be > used quite a lot (Mozilla, MoinMoin, Xine, ALSA, Xen), so I think it's a > pretty safe choice. > > I was also considering Bazaar, but since it was slower than Mercurial > and didn't have any big names using it, I picked Mercurial. Ubuntu uses it, I believe. I'm sure Mercurial is a fine choice. I should look into it sometime. Richard signature.asc Description: This is a digitally signed message part
Re: [Dovecot] CVS to Mercurial switch
On Sat, 2007-05-19 at 20:32 +0300, Timo Sirainen wrote: > SVN is centralized, Mercurial is distributed. Distributed version > control systems allow a lot of nice things. Also curious here... Why Mercurial vs. TLA (I think that's what they're calling arch now?), Darcs, Monotone, or Git? Richard signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v1.1 plans
On Wed, 2007-04-18 at 07:17 -0400, Charles Marcus wrote: > Well, there is room for argument here... I would call a 'minor' version > going from 1.0 to 1.0.1. For these increments, I totally agree. That's a change in the micro version. http://en.wikipedia.org/wiki/Software_versioning#Numeric Richard signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v1.1 plans
On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote: > I'm planning on keeping v1.1 almost completely compatible with v1.0. > There could be some minor configuration file changes, but for most > people v1.0's dovecot.conf should work with v1.1. Please, this needs to be "Everyone's v1.0 dovecot.conf will work in v1.1." If you're going to change the configuration file format even in some subtle way, please bump the major version. Likewise with plugin support... if you're going to break API or ABI, please bump the major version. It's easy enough to avoid breaking compatibility gratuitously. People do not expect configuration files to need changing between minor releases and they'll be quite upset if things break. Richard signature.asc Description: This is a digitally signed message part
