Re: [Dovecot] Address Extensions with System Users
Scott Silva wrote, On 4/17/09 1:27 PM: [...] AFAIR the RFC's state that all e-mail addresses are acted on in lowercase when being manipulated. The upper case parts are left intact only for human beings to read. That is very wrong. Email address local-parts MUST be treated as case-sensitive in SMTP because historically many hosts (including most systems resembling Unix) have treated usernames as case-sensitive and used local-parts that map to directories on case-sensitive filesystems. So RFC's 821, 822, 2821, and 5321 all explicitly state that local-parts are case-sensitive and RFC's 2822 and 5322 say it indirectly by way of the ABNF spec. The one exception is postmaster, which gets special treatment as the only address that has to exist in every domain. Note that the transport and header case-sensitivity does not automatically translate into how delivery agents and mailstore agents work. In this case, the case-folding is being done by Postfix's local component, which is its documented behavior.
Re: [Dovecot] Address Extensions with System Users
On Apr 18, 2009, at 2:05 AM, Bill Cole wrote: Scott Silva wrote, On 4/17/09 1:27 PM: [...] AFAIR the RFC's state that all e-mail addresses are acted on in lowercase when being manipulated. The upper case parts are left intact only for human beings to read. That is very wrong. Email address local-parts MUST be treated as case-sensitive in SMTP because historically many hosts (including most systems resembling Unix) have treated usernames as case- sensitive and used local-parts that map to directories on case- sensitive filesystems. So RFC's 821, 822, 2821, and 5321 all explicitly state that local-parts are case-sensitive and RFC's 2822 and 5322 say it indirectly by way of the ABNF spec. The one exception is postmaster, which gets special treatment as the only address that has to exist in every domain. I have no strong opinions about this, but http://mailman2.u.washington.edu/pipermail/imap-uw/2008-September/002190.html
Re: [Dovecot] Sieve redirect
James Butler schreef:
Is there an alternative to the redirect Sieve capability?
For example:
if header :contains Subject Listserv {
redirect list-us...@example.com;
redirect list-us...@example.com;
redirect list-us...@example.com;
stop;
}
How can I do the above without using redirect?
Unfortunately, redirect seems to be unsupported by Dovecot.
Thank you.
James
Here's why I posted this:
sievec global.before.sieve global.before.svbin
line 7: error: unsupported sieve capability 'redirect'.
error: validation failed.
Error: failed to compile sieve script 'global.before.sieve'
Ok, this error needs some clarification, since I, being the developer,
did not quite anticipate users 'require'ing Sieve core commands. :) The
redirect command is part of the main Sieve language and therefore it is
not known as a Sieve extension. This means that you can start using the
redirect command right away, but also that 'require'ing it causes an
error. So don't use 'require redirect;' in this case.
I am going to clarify these errors, so that user's know right away what
they are doing wrong.
Regards,
--
Stephan Bosch
step...@rename-it.nl
Re: [Dovecot] Shared folders and subscriptions
On Fri, Apr 17, 2009 at 07:07:49PM -0400, Timo Sirainen wrote: I tried this. The following is logged: Apr 18 00:12:01 asterix dovecot: IMAP(mar...@example.com): fchown(/var/spool/dovecot/users/example.com/markus/Maildir/control/ shared/subscriptions.lock, -1, 0) failed: Operation not permitted It tries to preserve the group. Try chmod g+s to the empty directory. That worked. Thanks again.
Re: [Dovecot] Feature Request: Control over IMP IDLE 'OK Still Here' message timings
Robert Goldsmith skrev: [...] Therefore, can you please make the timeout changeable from the config file, even if it defaults to the current 2min timing, so admins supporting mobile users can balance battery life with a need to prevent killed tcp connections. I'm amazed how you figured this out. I just thought my phone used more battery when connected to IMAP, I never thought it had anything to do with the OK Still Here messages (altough I knew they existed). Thanks for letting us all know, and thanks to Timo for accepting Robert's patch! Regards, Stian
Re: [Dovecot] Segfault in ACL Plugin + user shared folders
On Thu, Apr 16, 2009 at 08:10:00PM -0400, Timo Sirainen wrote: On Wed, 2009-04-08 at 01:03 +0200, Markus Werner wrote: With list = children the namespace ist still not listed, but that's no problem for me. With list = all now there is a folder named % listed, directly under #User/, additionaly to mar...@example.com. Talking IMAP manually, this looks like this: a003 LIST #User/% * LIST (\Noselect \HasChildren) / #User/% * LIST (\Noselect \HasChildren) / #User/t...@example.com * LIST (\Noselect \HasChildren) / #User/stefa...@example.com a003 OK List completed. a004 LIST #User/%/% * LIST (\HasNoChildren) / #User/t...@example.com/Shared * LIST (\HasNoChildren) / #User/stefa...@example.com/Software * LIST (\HasNoChildren) / #User/stefa...@example.com/Junk * LIST (\HasNoChildren) / #User/stefa...@example.com/Apple a004 OK List completed. or with *: a003 LIST #User/* * LIST (\Noselect \HasChildren) / #User/* * LIST (\Noselect \HasChildren) / #User/t...@example.com * LIST (\Noselect \HasChildren) / #User/stefa...@example.com * LIST (\HasNoChildren) / #User/t...@example.com/Shared * LIST (\HasNoChildren) / #User/stefa...@example.com/Software * LIST (\HasNoChildren) / #User/stefa...@example.com/Junk * LIST (\HasNoChildren) / #User/stefa...@example.com/Apple a003 OK List completed. a004 LIST #User/*/* * LIST (\HasNoChildren) / #User/t...@example.com/Shared * LIST (\HasNoChildren) / #User/stefa...@example.com/Software * LIST (\HasNoChildren) / #User/stefa...@example.com/Junk * LIST (\HasNoChildren) / #User/stefa...@example.com/Apple a004 OK List completed.
[Dovecot] Logging to see exactly all IMAP commands?
I was wondering if there is some additional logging that can be enabled to make it possible to have Dovecot print all actual IMAP commands it receives in a conversation? /Johan
Re: [Dovecot] Logging to see exactly all IMAP commands?
Johan Persson wrote: I was wondering if there is some additional logging that can be enabled to make it possible to have Dovecot print all actual IMAP commands it receives in a conversation? /Johan See here: http://wiki.dovecot.org/Debugging/Rawlog
[Dovecot] Mail replication
Hello, I am running an asynchronously replicated mail setup. 2 servers are each running an smtp server which uses dovecot as the LDA. I am using unison to replicate mail files between servers. Before, I was using Maildir format and after reading so much good papers about the very good performance of dbox format, I decided to switch to dbox. However, I now have a very annoying problem, as mails are created with names like u.1234 and numbers are following each others. So, if there is for example a mail stored as u.1001 on both servers, and now 2 mails arrive at about the same time, 1 on each server. Then, they will both be created as u.1002, that means unison will encounter a conflict as both files are different. So my question would be, is there a way to tell the servers to increment by 2 instead of 1 and have each an offset (like you can do with mysql with auto incrementing tables for example)? That way, with former example, one mail would be stored as u.1002 and the other as u.1003. Thanks smime.p7s Description: S/MIME Cryptographic Signature
Re: [Dovecot] Logging to see exactly all IMAP commands?
Thanks! This was exactly what I was looking for !! (I'm trying to debug a broken client without having the source to the client ... and have to show some proof to the vendor that they messed up.) /Johan On Saturday 18 April 2009 15:05:21 e-frog wrote: Johan Persson wrote: I was wondering if there is some additional logging that can be enabled to make it possible to have Dovecot print all actual IMAP commands it receives in a conversation? /Johan See here: http://wiki.dovecot.org/Debugging/Rawlog
Re: [Dovecot] Mail replication
On Apr 18, 2009, at 12:41 PM, Renaud Allard wrote: I am running an asynchronously replicated mail setup. 2 servers are each running an smtp server which uses dovecot as the LDA. I am using unison to replicate mail files between servers. Before, I was using Maildir format and after reading so much good papers about the very good performance of dbox format, I decided to switch to dbox. However, I now have a very annoying problem, as mails are created with names like u.1234 and numbers are following each others. So, if there is for example a mail stored as u.1001 on both servers, and now 2 mails arrive at about the same time, 1 on each server. Then, they will both be created as u.1002, that means unison will encounter a conflict as both files are different. Are you saying that both the servers are accepting and writing mails? That can't really work unless they can also do global file locking. So my question would be, is there a way to tell the servers to increment by 2 instead of 1 and have each an offset (like you can do with mysql with auto incrementing tables for example)? That way, with former example, one mail would be stored as u.1002 and the other as u.1003. Even if u.* files didn't conflict, index files would still break. And even if index files somehow could be made not to break, this would break IMAP protocol and IMAP clients might not download some of the mails anyway. I'm kind of surprised that it already wasn't breaking with Maildir.
Re: [Dovecot] Mail replication
Timo Sirainen wrote: On Apr 18, 2009, at 12:41 PM, Renaud Allard wrote: Are you saying that both the servers are accepting and writing mails? That can't really work unless they can also do global file locking. Indeed, but only one of them is accepting imap connections. The other one accepts imap only if the first one is down (virtual IPs) Even if u.* files didn't conflict, index files would still break. And even if index files somehow could be made not to break, this would break IMAP protocol and IMAP clients might not download some of the mails anyway. I'm kind of surprised that it already wasn't breaking with Maildir. Indexes were also replicated, but indeed they could break the same way. Is there already some sort of replication in dovecot? smime.p7s Description: S/MIME Cryptographic Signature
Re: [Dovecot] Mail replication
On Apr 18, 2009, at 12:58 PM, Renaud Allard wrote: Timo Sirainen wrote: On Apr 18, 2009, at 12:41 PM, Renaud Allard wrote: Are you saying that both the servers are accepting and writing mails? That can't really work unless they can also do global file locking. Indeed, but only one of them is accepting imap connections. The other one accepts imap only if the first one is down (virtual IPs) That kind of a setup would work reliably with maildir only if the other server's LDA didn't update any index/control files. But dbox's good performance comes from being able to trust that everything is always up-to-date in the index files, so that wouldn't really work. Is there already some sort of replication in dovecot? Not yet. Hopefully this year.
[Dovecot] Released Sieve v0.1.5 and ManageSieve v0.11.4 for Dovecot v1.2.rc3 and ManageSieve v0.10.6 for Dovecot v1.1.14
Hello Dovecot users, This is a simultaneous release of new versions of Sieve-related software for Dovecot v1.1 and v1.2. Only the Sieve implementation itself has seen significant development. The ManageSieve packages only have small fixes and the ManageSieve patches are updated as usual to match the new Dovecot releases. Changelog Sieve v0.1.5: * Ported the implementation of the Sieve include extension to the latest draft. This means that the import and export commands are replaced by a new command called global. The import and export commands are now DEPRICATED and are mere aliases for the global command. The new specification also adds the :once modifier to the include command. The also newly specified global.* variable namespace is not implemented yet as support for variable namespaces is currently missing. * Did a major rework of the multiscript support for better error handling and made sure that persistent global scripts (sieve_before/sieve_after) are always executed, even when the user does not have a script of his own and a global default is missing. + Provided basic support for the environment extension. Currenly, the name, version and host items are useful. Others are pending. + Improved error message that is presented when an unknown Sieve extension is provided as argument to the require command. It now notifies the user that Sieve core commands do not need to be specified in require. - Fixed bug in includes at levels deeper than one. - Fixed bug in address matching that was caused by the failure to handle group specifications. In Dovecot, these are marked by address items with NULL elements, which causes a segfault if not considered. The group 'undisclosed-recipients:;' in particular triggered this bug. Bug reported by Bernhard Schmidt. Changelog ManageSieve v0.11.4 (Dovecot v1.2.rc3): * Adjusted to changes in the Dovecot signal handler API. Changelog ManageSieve v0.10.6 (Dovecot v1.1.14): - Fixed small problems in the login proxy support. -- The releases are available as follows: Sieve for Dovecot 1.2: http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.5.tar.gz http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.5.tar.gz.sig ManageSieve for Dovecot v1.2 (package + patch): http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-managesieve-0.11.4.tar.gz http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-managesieve-0.11.4.tar.gz.sig http://www.rename-it.nl/dovecot/1.2/dovecot-1.2.rc3-managesieve-0.11.4.diff.gz http://www.rename-it.nl/dovecot/1.2/dovecot-1.2.rc3-managesieve-0.11.4.diff.gz.sig ManageSieve + patch for Dovecot v1.1 (package + patch): http://www.rename-it.nl/dovecot/1.1/dovecot-1.1-managesieve-0.10.6.tar.gz http://www.rename-it.nl/dovecot/1.1/dovecot-1.1-managesieve-0.10.6.tar.gz.sig http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.14-managesieve-0.10.6.diff.gz http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.14-managesieve-0.10.6.diff.gz.sig -- Have fun testing the new releases and don't hesitate to notify me when there are problems. Regards, -- Stephan Bosch step...@rename-it.nl
Re: [Dovecot] Dovecot broken with newer OpenSSL
Timo Sirainen wrote: On Apr 17, 2009, at 12:18 AM, Brad wrote: In the logs I see messages like the following... dovecot: Apr 16 23:12:18 Info: imap-login: Disconnected (no auth attempts): rip=2001:470:b01e:3:216:41ff:fe17:6933, lip=2001:470:1d:8c::2, TLS handshaking: Disconnected Anything else if you set verbose_ssl=yes? same problem here on OpenBSD 4.5-current (GENERIC) #28: Wed Apr 15 04:56:04 MDT 2009 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC with OpenSSL 0.9.8k 25 Mar 2009 and Dovecot 1.1.14 from ports log with verbose_ssl=yes: dovecot: imap-login: Disconnected (no auth attempts): rip=Y.Y.Y.Y, lip=X.X.X.X, TLS handshaking: SSL_accept() failed: error:0307F041:bignum routines:BNRAND:malloc failure hope that helps
Re: [Dovecot] Dovecot broken with newer OpenSSL
On Sat, 2009-04-18 at 22:26 +0200, Christian Rueger wrote: dovecot: imap-login: Disconnected (no auth attempts): rip=Y.Y.Y.Y, lip=X.X.X.X, TLS handshaking: SSL_accept() failed: error:0307F041:bignum routines:BNRAND:malloc failure Oh. malloc() failed? See if increasing login_process_size helps (or set it to 0 to disable the limit). signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Suggestion: deliver should honor mail_log_prefix
On Mon, 2009-04-13 at 14:29 -0500, Mike Abbott wrote:
I can set the log prefix for imap/pop3 processes using mail_log_prefix
but the log prefix for deliver is hard-coded. (I'm using 1.1.13.)
Deliver should either honor mail_log_prefix or have its own setting
(deliver_log_prefix?). What do you think?
Yeah, I guess mail_log_prefix should be used. It's also possible to make
deliver use a different one by placing it inside protocol lda {}. I'll
first add it to v1.3 and then see how easy it is to get it to v1.2 (but
I don't think I'll add it to v1.1, that would be a change in existing
behavior).
signature.asc
Description: This is a digitally signed message part
[Dovecot] dovecot deliver with sieve: Corrupted index cache file (in-memory index).cache: Broken fields for mail UID
Hi, Running dovecot deliver 1.1.11 with a sieve script (dovecot-sieve 1.1.6 + changeset b9567e94b897) the following messages started to show up in the mail logs for some (spam) messages: deliver(mathiaz): Apr 18 19:03:06 Error: Corrupted index cache file (in-memory index).cache: Broken fields for mail UID 1 deliver(mathiaz): Apr 18 19:03:06 Error: Couldn't fix broken header unfolding deliver(mathiaz): Apr 18 19:03:06 Info: msgid=01c9548a$f1666dfe$6c822...@pillarsx6: saved mail to INBOX How serious are these? Without changeset b9567e94b897 applied deliver would actually crash and the message would be lost. More information can be found in the Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/264306 -- Mathias Gug Ubuntu Developer http://www.ubuntu.com signature.asc Description: Digital signature
Re: [Dovecot] Dovecot broken with newer OpenSSL
On Saturday 18 April 2009 16:31:10 Timo Sirainen wrote: On Sat, 2009-04-18 at 22:26 +0200, Christian Rueger wrote: dovecot: imap-login: Disconnected (no auth attempts): rip=Y.Y.Y.Y, lip=X.X.X.X, TLS handshaking: SSL_accept() failed: error:0307F041:bignum routines:BNRAND:malloc failure Oh. malloc() failed? See if increasing login_process_size helps (or set it to 0 to disable the limit). I am not seeing the bit about SSL_accept() and setting login_process_size to 0 does not help. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
