Re: [Dovecot] doveadm fetch
On Tue, 20 Apr 2010 18:49:10 +0300
Timo Sirainen wrote:
>
> The above syntax would probably have to use IMAP parser.
>
> > doveadm fetch subject "(foo)"
>
> This works nowadays though. It's possible to use:
>
> doveadm fetch INBOX \( subject "(foo)" seen \) or unseen
>
> This works because there are now "IMAP parser" and "command line
> parser". The command line parser knows that after subject there must
> come a string, so it's not confused by the () characters. Then it also
> knows that when "(" or ")" comes in a separate parameter, it means a
> list. Actually it would have been possible to support \(subject without
> space after \(, but this won't work with the ending \):
>
> \(subject "(foo)"\)
>
> vs.
>
> \(subject "(foo))"
>
> would look identical to doveadm. So I thought it's better to always
> require the space.
>
> > but that makes it more difficult to add variables, because if you do:
> >
> > doveadm fetch 'subject "$foo"'
>
> $variables also work nicely now without having to escape them.
>
> Now, the next problem is how to select what to fetch and what the output
> format should look like. I'm thinking about:
>
> doveadm fetch INBOX "flags uid hdr.received hdr.from body" all
>
> would look like:
>
> ===sep
> flags: \seen \draft $Label1
> uid: 1234
> hdr:
> Received: stuff
> Received: more stuff
> From: t...@iki.fi
>
> body:
> message body
> ..
> ===sep
> flags: ..next message..
> ===sep
>
> The ===sep is a randomly generated separator string that begins always
> with "===", optionally it could be given as parameter. I was wondering
> about how to return hdr.* fields, if they should be returned separately
> or all in one "hdr". Otherwise separate fields would be nice, but if the
> header exists multiple times, it's not so clear anymore how it should be
> written. So if there's a single hdr then it's at least easy to
> understand that it ends with an empty line.
>
> Besides the example parameters above there could be "hdr" = full header
> and "text" = alias for "hdr body".
>
> It would be nice also to support something like:
>
> doveadm search INBOX from t...@iki.fi
>
> doveadm next|less
> doveadm next|less
> ..etc..
>
> So the "next" would return the next matching message based on the
> previous search. I'm not really sure where the state could be kept
> though. Would be nice if it was terminal-specific, and would be nice if
> it didn't write any temporary files.
Maybe you should take exim's queue style for such operations. Here few examples:
#exim -bp //return queue in format:
4d 99K 1O36Eu-0001Py-Ts
is_...@domain.ltd
#doveadm search INBOX from t...@iki.fi
<...id-1>
<...id-2>
<...id-n>
Will return just unique ids for current mailbox. Maybe also few headers/flags
etc.
#doveadm fetch <...id-2> all
Print full message for id, gotten from doveadm searc.
#doveadm fetch <...id-2> hrd.from hdr.subject
Print corresponding header values.
Exim also have -Mvl option - which print log lines for current id. It will be
nice if:
#doveadm log
Found all service records for message and print them to terminal.
With above scheme you don't need to construct separator - will be
enough and doveadm next wont be necessary.
[Dovecot] imap-zlib patch to fix runaway imap process
Here is a patch to fix the problem where an imap process runs away when
imap-zlib is in use. The backtrace showed:
io_loop_handler_run ->
stream_send_io ->
client_output ->
o_stream_flush ->
o_stream_zlib_flush ->
o_stream_zlib_send_flush
When o_stream_zlib_flush returns 0, stream_send_io reinstates the IO_WRITE
event, causing the infinite loop.
diff -ur dovecot-2.0.beta4/src/plugins/zlib/ostream-bzlib.c
dovecot-2.0.beta4+fix/src/plugins/zlib/ostream-bzlib.c
--- dovecot-2.0.beta4/src/plugins/zlib/ostream-bzlib.c 2010-02-12
20:22:07.0 -0600
+++ dovecot-2.0.beta4+fix/src/plugins/zlib/ostream-bzlib.c 2010-04-20
19:15:29.0 -0500
@@ -122,15 +122,15 @@
static int o_stream_bzlib_flush(struct ostream_private *stream)
{
struct bzlib_ostream *zstream = (struct bzlib_ostream *)stream;
+ int ret;
if (o_stream_bzlib_send_flush(zstream) < 0)
return -1;
- if (o_stream_flush(zstream->output) < 0) {
+ ret = o_stream_flush(zstream->output);
+ if (ret < 0)
zstream_copy_error(zstream);
- return -1;
- }
- return 0;
+ return ret;
}
static ssize_t
diff -ur dovecot-2.0.beta4/src/plugins/zlib/ostream-zlib.c
dovecot-2.0.beta4+fix/src/plugins/zlib/ostream-zlib.c
--- dovecot-2.0.beta4/src/plugins/zlib/ostream-zlib.c 2010-02-18
22:01:56.0 -0600
+++ dovecot-2.0.beta4+fix/src/plugins/zlib/ostream-zlib.c 2010-04-20
19:15:29.0 -0500
@@ -184,15 +184,15 @@
static int o_stream_zlib_flush(struct ostream_private *stream)
{
struct zlib_ostream *zstream = (struct zlib_ostream *)stream;
+ int ret;
if (o_stream_zlib_send_flush(zstream) < 0)
return -1;
- if (o_stream_flush(zstream->output) < 0) {
+ ret = o_stream_flush(zstream->output);
+ if (ret < 0)
zstream_copy_error(zstream);
- return -1;
- }
- return 0;
+ return ret;
}
static ssize_t
Re: [Dovecot] zlib Plugin Dovecot 2.0 - ostream
If I had the file descriptor, I will reuse my functions to do this, made in a separate library, that i use in the MTA. So no need to rewrite again the part of split the message. 2010/4/20 Timo Sirainen > You should write the message header to the ostream that you get, and > message body to some other file that you create. Use the o_stream_send() > function to write the message header to the ostream (which does > basically the same as write(fd)). I don't see how getting the stream's > fd would help with anything. > > On Tue, 2010-04-20 at 11:54 -0300, Alex Baule wrote: > > Because my plugin will separate the body of the message header. > > > > With the FD I have control over the message to separate it. > > > > Do you have any suggestions for this separation? > > > > I do not quite understand how the struct ostream works. > > > > Tks Timo. > > > > > > > > 2010/4/20 Timo Sirainen > > > > > On Tue, 2010-04-20 at 11:40 -0300, Alex Baule wrote: > > > > > > > There is a way to get the file descriptor from output used in ostream > > > zlib > > > > plugin ? > > > > > > No. Why do you need it? You should be writing to ostream, not to its > fd. > > > > > > > >
[Dovecot] doveadm fetch
On Wed, 2010-04-14 at 12:04 +0300, Timo Sirainen wrote:
> I don't think the process creation is much of an issue. But something like
> this could work:
>
> doveadm expunge -A < Trash savedbefore 1w
> Trash/* savedbefore 1w
> Spam savedbefore 2mon
> EOT
The above syntax would probably have to use IMAP parser.
> doveadm fetch subject "(foo)"
This works nowadays though. It's possible to use:
doveadm fetch INBOX \( subject "(foo)" seen \) or unseen
This works because there are now "IMAP parser" and "command line
parser". The command line parser knows that after subject there must
come a string, so it's not confused by the () characters. Then it also
knows that when "(" or ")" comes in a separate parameter, it means a
list. Actually it would have been possible to support \(subject without
space after \(, but this won't work with the ending \):
\(subject "(foo)"\)
vs.
\(subject "(foo))"
would look identical to doveadm. So I thought it's better to always
require the space.
> but that makes it more difficult to add variables, because if you do:
>
> doveadm fetch 'subject "$foo"'
$variables also work nicely now without having to escape them.
Now, the next problem is how to select what to fetch and what the output
format should look like. I'm thinking about:
doveadm fetch INBOX "flags uid hdr.received hdr.from body" all
would look like:
===sep
flags: \seen \draft $Label1
uid: 1234
hdr:
Received: stuff
Received: more stuff
From: t...@iki.fi
body:
message body
..
===sep
flags: ..next message..
===sep
The ===sep is a randomly generated separator string that begins always
with "===", optionally it could be given as parameter. I was wondering
about how to return hdr.* fields, if they should be returned separately
or all in one "hdr". Otherwise separate fields would be nice, but if the
header exists multiple times, it's not so clear anymore how it should be
written. So if there's a single hdr then it's at least easy to
understand that it ends with an empty line.
Besides the example parameters above there could be "hdr" = full header
and "text" = alias for "hdr body".
It would be nice also to support something like:
doveadm search INBOX from t...@iki.fi
doveadm next|less
doveadm next|less
..etc..
So the "next" would return the next matching message based on the
previous search. I'm not really sure where the state could be kept
though. Would be nice if it was terminal-specific, and would be nice if
it didn't write any temporary files.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] zlib Plugin Dovecot 2.0 - ostream
You should write the message header to the ostream that you get, and message body to some other file that you create. Use the o_stream_send() function to write the message header to the ostream (which does basically the same as write(fd)). I don't see how getting the stream's fd would help with anything. On Tue, 2010-04-20 at 11:54 -0300, Alex Baule wrote: > Because my plugin will separate the body of the message header. > > With the FD I have control over the message to separate it. > > Do you have any suggestions for this separation? > > I do not quite understand how the struct ostream works. > > Tks Timo. > > > > 2010/4/20 Timo Sirainen > > > On Tue, 2010-04-20 at 11:40 -0300, Alex Baule wrote: > > > > > There is a way to get the file descriptor from output used in ostream > > zlib > > > plugin ? > > > > No. Why do you need it? You should be writing to ostream, not to its fd. > > > > signature.asc Description: This is a digitally signed message part
Re: [Dovecot] zlib Plugin Dovecot 2.0 - ostream
Because my plugin will separate the body of the message header. With the FD I have control over the message to separate it. Do you have any suggestions for this separation? I do not quite understand how the struct ostream works. Tks Timo. 2010/4/20 Timo Sirainen > On Tue, 2010-04-20 at 11:40 -0300, Alex Baule wrote: > > > There is a way to get the file descriptor from output used in ostream > zlib > > plugin ? > > No. Why do you need it? You should be writing to ostream, not to its fd. > >
Re: [Dovecot] dovecot2 beta and gcc3(?) - compile problem
On Tue, 2010-04-20 at 15:18 +0200, Andre Hübner wrote: > ../../src/login-common/.libs/libdovecot-login.so: undefined reference to > `ERR_peek_last_error' Your OpenSSL library is too old. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] zlib Plugin Dovecot 2.0 - ostream
On Tue, 2010-04-20 at 11:40 -0300, Alex Baule wrote: > There is a way to get the file descriptor from output used in ostream zlib > plugin ? No. Why do you need it? You should be writing to ostream, not to its fd. signature.asc Description: This is a digitally signed message part
[Dovecot] zlib Plugin Dovecot 2.0 - ostream
Hello Everyone... In zlib save mail have it: struct ostream *output; There is a way to get the file descriptor from output used in ostream zlib plugin ? to get in istream is i_stream_get_fd, but don't have o_stream_get_fd..
[Dovecot] dovecot2 beta and gcc3(?) - compile problem
Hello, try to compile current dovecot2 beta on older machine with gcc 3.3 Compiling results in error: libtool: link: gcc -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -o .libs/imap-login client.o client-authenticate.o imap-login-settings.o imap-proxy.o ../../src/login-common/.libs/libdovecot-login.so ../../src/lib-dovecot/.libs/libdovecot.so -lrt -Wl,-rpath -Wl,/usr/lib/dovecot ../../src/login-common/.libs/libdovecot-login.so: undefined reference to `ERR_peek_last_error' collect2: ld returned 1 exit status make[3]: *** [imap-login] Error 1 make[3]: Leaving directory `/usr/src/dovecot-1.1.rc12/dovecot-2.0.beta4/src/imap-login' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/dovecot-1.1.rc12/dovecot-2.0.beta4/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/dovecot-1.1.rc12/dovecot-2.0.beta4' make: *** [all] Error 2 Is there something missed on my side or problem with older gcc? dovecot 1.2.11 compiles just fine with same configure-line also there are some warnings like this: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../src/lib -I../../../../src/lib-settings -I../../../../src/lib-mail -I../../../../src/lib-imap -I../../../../src/lib-index -I../../../../src/lib-storage -I../../../../src/lib-storage/index -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -MT dbox-sync-rebuild.lo -MD -MP -MF .deps/dbox-sync-rebuild.Tpo -c dbox-sync-rebuild.c -fPIC -DPIC -o .libs/dbox-sync-rebuild.o In file included from dbox-sync-rebuild.c:5: ../../../../src/lib-index/mail-index-modseq.h:34: warning: parameter has incomplete type ../../../../src/lib-index/mail-index-modseq.h:52: warning: parameter has incomplete type or libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../src/lib -I../../../../src/lib-settings -I../../../../src/lib-mail -I../../../../src/lib-imap -I../../../../src/lib-index -I../../../../src/lib-storage -I../../../../src/lib-storage/index -I../../../../src/lib-storage/index/dbox-common -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -MT mdbox-file.lo -MD -MP -MF .deps/mdbox-file.Tpo -c mdbox-file.c -fPIC -DPIC -o .libs/mdbox-file.o In file included from mdbox-storage.h:5, from mdbox-file.c:16: ../../../../src/lib-storage/mailbox-list-private.h:158: warning: parameter has incomplete type Thanks, Andre
Re: [Dovecot] Checkpassword/prefetch/master_user and prob lems
Nobody ?
This can be a dovecot bug ?
--
Emerson Pinter
Picture Internet
55 11 5089-8130
http://www.picture.com.br/
On Mon, 19 Apr 2010 14:27:22 -0300, Emerson Pinter
wrote:
> Hi.
>
> I'm trying to use checkpassword for simple auth and masteruser auth.
> I have two programs, one called checkpassword-master (for masteruser
> lookup) and another called checkpassword for normal passdb and userdb
> lookup).
> All works fine for non-masteruser authentication (in this case dovecot
> makes a single call to checkpassword binary). But if a master-user
> authenticates, dovecot execute checkpassword-master binary, and then
> executes checkpassword binary. Checkpassword binary receive the
MASTER_USER
> env and do all the checks correctly, when checkpassword finish, dovecot
> logs this message "auth(default): checkpassword: sighandler called for
> unknown child" and authentication fails...
>
> I'm trying checkpassword-reply and fd4 too, on 1.2.11 and 2.0b4, no
> success.
>
> Below is my config:
>
> auth default {
> mechanisms = plain
> passdb checkpassword {
> args = /srv/dovecot/checkpassword
> }
> passdb checkpassword {
> args = /srv/dovecot/checkpassword-master
> master=yes
> pass=yes
> }
> userdb prefetch {
> }
> }
>
> Anybody can help me ?
>
> Tks.
Esta mensagem pode conter informações confidenciais, privilegiadas ou privadas.
Caso não seja o destinatário, favor apagá-la e notificar o remetente.
Saiba que o uso impróprio das informações existentes é estritamente
proibido, sendo tratado conforme as normas da empresa e a legislação em vigor.
Re: [Dovecot] setgid failed - Not owner
in master.cf you said postfix to run deliver as user dovecot. deliver then ask sql and get the info to stote the mail as uid 12345 deliver has to run setuid root to do that. see http://wiki.dovecot.org/LDA#Multiple_UIDs or you can change master.cf to dovecot unix - n n - - pipe flags=DRhu user=12345:12345 argv=/var/postfix/dovecot/libexec/dovecot/deliver -d $(recipient) if all have the same uid. Andreas Am 20.04.2010 08:28 schrieb Zilon X: > Changed home dir of users, in my configuration they are > /var/postfix/spool and /var/postfix/dovecot/run, but with no effect. > I still got the "fatal setgid failed: Not owner" ( Fatal: > setgid(12345(postfix)) failed with euid=12346(dovecot), > gid=54322(dovecot), egid=54322(dovecot): Not owner ) > > > > 2010/4/20 Andreas Schulze : > > I would never use /dev/null as homedir. > > postfix home is /var/spool/postfix, dovecot likes /var/run/dovecot. -- Andreas Schulze Internetdienste | P532 DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info @datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender) Dipl.-Kfm. Michael Leistenschneider Jörg Rabe v. Pappenheim Dipl.-Vw. Eckhard Schwarzer Vorsitzender des Aufsichtsrates: Reinhard Verholen
Re: [Dovecot] setgid failed - Not owner
Changed home dir of users, in my configuration they are /var/postfix/spool and /var/postfix/dovecot/run, but with no effect. I still got the "fatal setgid failed: Not owner" ( Fatal: setgid(12345(postfix)) failed with euid=12346(dovecot), gid=54322(dovecot), egid=54322(dovecot): Not owner ) 2010/4/20 Andreas Schulze : > Am 19.04.2010 16:49 schrieb Zilon X: >> postfix:x:12345:12345::/dev/null:/bin/false >> dovecot:x:12346:54322::/dev/null:/bin/false > > I would never use /dev/null as homedir. > postfix home is /var/spool/postfix, dovecot likes /var/run/dovecot. > > -- > Andreas Schulze > Internetdienste | P532 > > DATEV eG > 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 > E-Mail info @datev.de | Internet www.datev.de > Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg > Nr.70 > Vorstand > Prof. Dieter Kempf (Vorsitzender) > Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender) > Dipl.-Kfm. Michael Leistenschneider > Jörg Rabe v. Pappenheim > Dipl.-Vw. Eckhard Schwarzer > Vorsitzender des Aufsichtsrates: Reinhard Verholen > >
Re: [Dovecot] zero sized messages in Maildir, corrupt filenames ?
On Tue, 2010-04-20 at 10:39 +0200, Rodolphe Buret wrote:
> Example of 2 probably related messages in the cur folder:
> 1785 Apr 20 09:18 msg.zMeU:2,d
This is an MH file.
http://wiki.dovecot.org/MailboxFormat/Maildir#Procmail_Problems
> 0 Apr 20 09:18 _J9C%jVVzLB.{myhostname}:2,
I don't know what this is. Not something created by Dovecot.
signature.asc
Description: This is a digitally signed message part
[Dovecot] zero sized messages in Maildir, corrupt filenames ?
Hi,
I'm starting to see more and more duplicates in my cur directory. they
seem to be a copy of an incoming mail (messages share the same date) but
they appears in the client as a message without subject and without
sender or body. Their filename starts with an underscore and the 4th
letter is a %. The rest of the filename is random (but it also includes
my hostname). Which program could create such a filename ? If it's in
the cur directory, it can only be dovecot, right ?
Example of 2 probably related messages in the cur folder:
1785 Apr 20 09:18 msg.zMeU:2,d
0 Apr 20 09:18 _J9C%jVVzLB.{myhostname}:2,
In addition, it seems that since we have started to use thunderbird 3,
indexes are often corrupt, mailboxes needs reconstruction and so on.
Could it be an incompatibility with my version of dovecot ? I've
disabled my thunderbird filters that were moving the incoming mail
automatically, no difference. I use no antivirus (linux imap client
mainly). I can (probably) upgrade to dovecot-1.2.11-3_108 but I'd like
to be sure that I won't create more problems before doing it.
The homedirs are NFS mounted.
dovecot 1.1.7-0_84
squirrelmail 1.4.19
postfix 2.6.5-1
Here is my dovecot -n
# 1.1.7: /etc/dovecot.conf
# OS: Linux 2.6.18-128.1.1.el5xen x86_64 Red Hat Enterprise Linux Server
release 5.3 (Tikanga)
log_path: /var/log/dovecot.log
protocols: imap imaps
listen: *
login_dir: /var/run/dovecot/login
login_executable: /usr/libexec/dovecot/imap-login
mail_location: maildir:~/Maildir
mmap_disable: yes
mail_nfs_storage: yes
mail_nfs_index: yes
lock_method: dotlock
auth default:
passdb:
driver: pam
userdb:
driver: passwd
plugin:
quota:
Thanks for your time,
--
Rodolphe Buret Ecole Polytechnique Fédérale de Lausanne
System AdministratorEPFL STI-IEL-ESL
Tel: +41-21-693-0922ELG 136 (bâtiment ELG)
Fax: +41-21-693-0909Station 11
Email: rodolphe.bu...@epfl.ch CH-1015 Lausanne Switzerland
Re: [Dovecot] Dovecot-sieve vacation proposal, use address in addresses as recipient
Steffen Kaiser wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 19 Apr 2010, Stephan Bosch wrote: Now I'm wondering.. should this be configurable/optional? Ideally I would suggest a vendor feature, which one has to require before use. But this would make problems using the feature from Webmail frontends, that does not allow to add custom Sieve code. If users don't want this to happen, they should specify :from explicitly. I'm more interested in whether administrators would would want to disable this behavior throughout the system. Regards, Stephan.
Re: [Dovecot] Dovecot-sieve vacation proposal, use address in addresses as recipient
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 19 Apr 2010, Stephan Bosch wrote: Now I'm wondering.. should this be configurable/optional? Ideally I would suggest a vendor feature, which one has to require before use. But this would make problems using the feature from Webmail frontends, that does not allow to add custom Sieve code. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS81lZr+Vh58GPL/cAQLb2Af/cwI67piwRVyGkz4UpUZIKaBYG3uk0Atk wEovBX9qpWKFxFqs1Xw1OMnBuQgiX5iJIa3cOYw+ldx7XNv3YSRVczd12dZWWS3L DiUaFrGeKsLsvl9V3OKXp2U3BhZVe7X5I/6+dqXItV5+ZtgToyLyEYC5sM7p7k+5 aPbKudg5Ojh52VKR8LgYBbhMM+35A1GCYQQVFe34eitKgdyhXKZbLjr/B9SAmxQ8 8lcN9boHIg8wYRYwn4etCJymw3vAKwVn44kv65bhjwuGezQHh01pAXSCgzwlSifL K91ol3WixY3XdZYyHwVWFCGi2aGNy8ZKENQMyJe+qJsGP5ydB+z6DA== =3Kq8 -END PGP SIGNATURE-
