Re: [Dovecot] UTF-8 mailbox names in filesystem
Quoting Timo Sirainen t...@iki.fi: Currently mailbox names are stored in IMAP's modified-UTF-7 format in filesystem. I was wondering about changing this in v2.0. The default would still be to use mUTF-7 in filesystem, but just adding :UTF8 or something to mail_location could enable UTF-8. Any thoughts? Could this be dangerous somehow? UTF-8 enables a lot of weird characters, perhaps no one really wants to see them on filesystem since there's no way to type the characters? But for small systems this probably isn't a problem. I would personally find it useful. I use accented and Chinese characters, and I've worked in environments where they were common as well. Having a common name between MUA and FS would certainly be nice. As for the risks, maybe some Unicode ranges could be restricted to avoid control characters and such? Or limit the use to given subsets? It might be useful as well to be able to enable it on a per-user basis. Would that add too much complexity? I think of it as a nice feature, but not a critical one. Laurent
Re: [Dovecot] UTF-8 mailbox names in filesystem
On Mon, Nov 09, 2009 at 09:11:23PM -0500, Timo Sirainen wrote: Currently mailbox names are stored in IMAP's modified-UTF-7 format in filesystem. I was wondering about changing this in v2.0. The default would still be to use mUTF-7 in filesystem, but just adding :UTF8 or something to mail_location could enable UTF-8. Any thoughts? Could this be dangerous somehow? UTF-8 enables a lot of weird characters, perhaps no one really wants to see them on filesystem since there's no way to type the characters? But for small systems this probably isn't a problem. What's the advantage? Geert -- Geert Hendrickx -=- g...@telenet.be -=- PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
Re: [Dovecot] homedir auto-creat
Hi Frank, Is it possible to activate home directories auto creation when using real UNIX users ( NIS ) on the dovecot server ? If you're using pam for authentication, you could perhaps use pam_mkhomedir? This works for any PAM app. Gr. Matthijs signature.asc Description: Digital signature
Re: [Dovecot] v1.2.7 released
Hello Timo,
unfortunally dovecot-1.2.6-managesieve-0.11.9.diff is not applicable to
Dovecot 1.2.7. After patching dovecot-1.2.6-managesieve-0.11.9.diff from:
@@ -619,7 +635,13 @@
*set-imap_capability != '\0' ?
set-imap_capability :
set-imap_generated_capability, NULL));
if (*set-imap_capability != '\0')
env_put(CAPABILITY_STRING_OVERRIDDEN=1);
+ } else if (group-mail_process_type == PROCESS_TYPE_MANAGESIEVE) {
+ env_put(t_strconcat(CAPABILITY_STRING=,
+ set-managesieve_generated_capability, NULL));
+ env_put(t_strconcat(MANAGESIEVE_IMPLEMENTATION_STRING=,
+
set-managesieve_implementation_string, NULL));
}
+
if (*set-login_trusted_networks != '\0') {
env_put(t_strconcat(TRUSTED_NETWORKS=,
set-login_trusted_networks, NULL));
to
@@ -619,9 +635,15 @@
*set-imap_capability != '\0' ?
set-imap_capability :
set-imap_generated_capability, NULL));
if (*set-imap_capability != '\0')
env_put(CAPABILITY_STRING_OVERRIDDEN=1);
+ } else if (group-mail_process_type == PROCESS_TYPE_MANAGESIEVE) {
+ env_put(t_strconcat(CAPABILITY_STRING=,
+ set-managesieve_generated_capability, NULL));
+ env_put(t_strconcat(MANAGESIEVE_IMPLEMENTATION_STRING=,
+
set-managesieve_implementation_string, NULL));
}
+
if (*set-login_trusted_networks != '\0') {
env_put(t_strconcat(TRUSTED_NETWORKS=,
set-login_trusted_networks, NULL));
this patch works with Dovecot 1.2.7.
Christian
[Dovecot] Override Quota with post-login scripting problem
Timo Sirainen schrieb: On Mon, 2009-11-09 at 11:18 +0100, Yorck Koehler wrote: But delivery is still a problem, because I'm unable to override the settings there with post-login scripting. Everytime I send messages to such a user, dovecot sends it back with Quota exceeded (mailbox for user is full)... My Question: Is it possible to override the lda quota like I can do it within imap ? How do you call deliver? Anyway, create deliver.sh that works something like: #!/bin/sh QUOTA_RULE=... exec deliver -k I changed in my Postfix configuration from /usr/local/libexec/dovecot/deliver to /usr/local/bin/deliver.sh and created the following file (deliver.sh): #!/bin/sh QUOTA_RULE='*:storage=500M' exec /usr/local/libexec/dovecot/deliver -k --- I'm still getting Quota exceeded messages, though 500M should be enough (Test-Mailbox is at 260M). I'm using Dovecot 1.2.7 since this morning (Nice work, btw.). I read in the source code (deliver.c) and found out that env_clean (-k) only changes the TZ/Home, if necessary. If Quota_Rule always comes from the dovecot.conf, this would explain, why defining Quota_Rule before calling deliver does not work. Sorry, im unable to understand the whole source code at once. Any Ideas ? sincerely yours - Yorck Koehler
[Dovecot] [Fwd: Re: Bug in BODYSTRUCTURE]
Fyi... Sam Varshavik (courier-imap developer) claims (on the courier-imap list, see attached) dovecot is incorrectly parsing messages with missing/invalid MIME-Version: header... I have no clue if he is correct... if so, maybe this has already been fixed? ---BeginMessage--- Chris St Denis writes: Sam Varshavchik wrote: Chris St Denis writes: Courier-imap is incorrectly parsing the message structure of some emails. Courier-IMAP parsed your sample message correctly, according to RFC 2822. This appears to be a bug in your Barracuda spam firewall product, which corrupted the original headers, when it processed it. What header(s) in particular are wrong and what should they be for it to be correct? I will pass the data as a bug report to Barracuda and get this resolved. An RFC 2822 message consists of one or more header lines, then an empty line, then followed by the body of the message. Then, in order for a message to be a valid MIME message, it must include the MIME-Version: header. See section 4 of RFC 2045. It's clear, and unambiguous. A MIME-Version: header must be present. Your sample message does not contain a MIME-Version: header, in the header portion of the message; as such it is not a MIME message. Without a valid MIME-Version: header present, none of the MIME headers, including Content-Type: carry any meaning. There is a line in your message that reads MIME-Version:, however it is not a part of this message's header portion. The message's headers precede the first empty line of the message, see above. In the example message MIME-Version: occurs after the first empty line. If you actually examine the message closely, Barracuda inserted its junk *in the middle* of an existing References: header! After all of that garbage, you can see what's obviously the last line of the original References: header, containing the last message ID, followed by a Mime-Version: 1.0. However, since the junk inserted by Barracuda included a bunch of empty lines, everything below that junk is considered a part of the message's contents, and not its headers. Ready!… Fire!… Aim??? However this situation does appear to be specific to courier-imap. Dovecot is able to parse it If so, it violates RFC 2045, section 4. Its wording is clear: Messages composed in accordance with this document MUST include such a header field, with the following verbatim text: MIME-Version: 1.0 The presence of this header field is an assertion that the message has been composed in compliance with this document. If so, it fails to check for the presence of the MIME-Version: header, so it processes the Content-Type: header even if MIME-Version: is missing. and Thunderbird (with courier-imap as the server) displays it correctly (therefore it must not use BODYSTRUCTURE). Correct. Thunderbird does not use BODYSTRUCTURE. And, it has the same sloppy logic as Dovecot. This is somewhat sad. Internet standards are supposed to have some meaning. I could see ignoring something that's may be burdensome or onerous, but this is basic, elementary stuff. pgpTVxfT3mY1F.pgp Description: PGP signature -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Courier-imap mailing list courier-i...@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap ---End Message---
Re: [Dovecot] [Fwd: Re: Bug in BODYSTRUCTURE]
Charles Marcus, 2009-11-10 12:52: Sam Varshavik (courier-imap developer) claims (on the courier-imap list, see attached) dovecot is incorrectly parsing messages with missing/invalid MIME-Version: header... Since when is being robust incorrect? However this situation does appear to be specific to courier-imap. Dovecot is able to parse it If so, it violates RFC 2045, section 4. Its wording is clear: Messages composed in accordance with this document MUST include such a header field, with the following verbatim text: MIME-Version: 1.0 The presence of this header field is an assertion that the message has been composed in compliance with this document. If so, it fails to check for the presence of the MIME-Version: header, so it processes the Content-Type: header even if MIME-Version: is missing. Well, that is a MUST for the sender part (that creates the message), but the RFC (or at least the part that Sam Varshavchik quoted) does not say you are not allowed to handle a MIME message if some part of it is broken. You can does, if you like to be a pedantic bureaucrat, but I doubt that this improves the user experience. This is somewhat sad. Internet standards are supposed to have some meaning. I could see ignoring something that's may be burdensome or onerous, but this is basic, elementary stuff. It's actually the other way round: It's harder to write software that follows the robustness principle, be liberal in what you accept from others. Sam's ranting would apply to violations of the other part, be conservative in what you do.
Re: [Dovecot] [Fwd: Re: Bug in BODYSTRUCTURE]
I fully agree with Jakob. Actually this is a somewhat recent change (v1.1.alpha2). Mime-Version: was previously required, but there were enough broken mails that I decided to make this optional in code (but not by admin): /* Buggy software creates Content-Type: headers without Mime- Version: header. By default we allow this and assume message is MIME if Content-Type: is found. This flag disables this. */ MESSAGE_PARSER_FLAG_MIME_VERSION_STRICT = 0x02 On Nov 10, 2009, at 8:02 AM, Jakob Hirsch wrote: Charles Marcus, 2009-11-10 12:52: Sam Varshavik (courier-imap developer) claims (on the courier-imap list, see attached) dovecot is incorrectly parsing messages with missing/invalid MIME-Version: header... Since when is being robust incorrect? However this situation does appear to be specific to courier-imap. Dovecot is able to parse it If so, it violates RFC 2045, section 4. Its wording is clear: Messages composed in accordance with this document MUST include such a header field, with the following verbatim text: MIME-Version: 1.0 The presence of this header field is an assertion that the message has been composed in compliance with this document. If so, it fails to check for the presence of the MIME-Version: header, so it processes the Content-Type: header even if MIME-Version: is missing. Well, that is a MUST for the sender part (that creates the message), but the RFC (or at least the part that Sam Varshavchik quoted) does not say you are not allowed to handle a MIME message if some part of it is broken. You can does, if you like to be a pedantic bureaucrat, but I doubt that this improves the user experience. This is somewhat sad. Internet standards are supposed to have some meaning. I could see ignoring something that's may be burdensome or onerous, but this is basic, elementary stuff. It's actually the other way round: It's harder to write software that follows the robustness principle, be liberal in what you accept from others. Sam's ranting would apply to violations of the other part, be conservative in what you do.
Re: [Dovecot] UTF-8 mailbox names in filesystem
On Nov 10, 2009, at 9:02 AM, Steffen Kaiser wrote: I've worked in environments where they were common as well. Having a common name between MUA and FS would certainly be nice. It would be nicer for some scripts and plugins as well. Will there be an API to match folder names, upper and lower case etc.pp.? Mailbox names have always been case-sensitive. So you could use some generic UTF-8 functions if you really needed to, but other than that I wasn't planning on doing anything.
[Dovecot] Multiple instances of dovecot in the same machine.
Hello all, I'm trying to run several instances of dovecot, with a different config each one, following the instructions from here: http://wiki.dovecot.org/RunningDovecot I try the command dovecot -c /etc/dovecot/installN/dovecot.conf and get: --- Error: ssl_cert_file: Can't use /etc/ssl/certs/dovecot.pem: No such file or directory Fatal: Invalid configuration in /etc/dovecot/installN --- but in my /etc/dovecot/installN/dovecot.conf file I have these lines: ssl_cert_file = /etc/dovecot/installN/ssl/certs/dovecot.pem ssl_key_file = /etc/dovecot/installN/ssl/private/dovecot.pem where both files exist and are valid. Any help is appreciated. Thanks, Rodolfo.
Re: [Dovecot] [Fwd: Re: Bug in BODYSTRUCTURE]
On 11/10/2009, Timo Sirainen (t...@iki.fi) wrote: I fully agree with Jakob. Actually this is a somewhat recent change (v1.1.alpha2). Mime-Version: was previously required, but there were enough broken mails that I decided to make this optional in code (but not by admin): Good enough for me... I just wanted confirmation... thx!
[Dovecot] [SOLVED] Re: Multiple instances of dovecot in the same machine.
Rodolfo Gonzalez Gonzalez escribió: --- Error: ssl_cert_file: Can't use /etc/ssl/certs/dovecot.pem: No such file or directory Fatal: Invalid configuration in /etc/dovecot/installN --- Please ignore this, it was a typo in the config. Solved. Thanks. attachment: rgonzalez.vcf
Re: [Dovecot] 1.1.20 patch - PAM file cleaup
On Tue, 2009-11-10 at 12:25 -0600, Todd Rinaldo wrote:
This patch prevents a temp file cleanup issue related to PAM. It
appears to be relevant only to 1.1 dovecot code. It seems pretty
sensible. From what I can tell, it's not included in the 1.1.20
release. I'm not clear if it was ever reported. Could it be merged in
for future releases?
http://cvs.fedora.redhat.com/viewvc/rpms/dovecot/F-8/dovecot-1.0.rc2-pam-setcred.patch?revision=1.1view=markup
No need to patch. Just use:
passdb pam {
args = setcred=no
}
signature.asc
Description: This is a digitally signed message part
[Dovecot] 1.1.20 patch - PAM file cleaup
Hi, This patch prevents a temp file cleanup issue related to PAM. It appears to be relevant only to 1.1 dovecot code. It seems pretty sensible. From what I can tell, it's not included in the 1.1.20 release. I'm not clear if it was ever reported. Could it be merged in for future releases? http://cvs.fedora.redhat.com/viewvc/rpms/dovecot/F-8/dovecot-1.0.rc2-pam-setcred.patch?revision=1.1view=markup Thanks, Todd Rinaldo
Re: [Dovecot] sieve files wont get parsed/compiled using cmusieve
Hi Steffen,
thanks for your reply.
deliver gets called and is saving the message to INBOX.
Sieve isn't mentioned at all in the log - only the MANAGESIEVE Service
does some logging when editing sieve rules via the MANAGESIEVE Service.
Any more ideas? ;-)
Thanks, Moritz
Nov 10 19:46:33 mail deliver(mor...@krinke.biz): maildir++:
root=/var/vmail/krinke.biz/moritz, index=, control=,
inbox=/var/vmail/krinke.biz/moritz
Nov 10 19:46:33 mail deliver(mor...@krinke.biz):
msgid=d03a5a670911101046y51cf5347m2c79a1642e726...@mail.gmail.com: saved
mail to INBOX
Nov 10 19:46:33 mail postfix/pipe[21996]: 4134B29F50:
to=mor...@krinke.biz, relay=dovecot, delay=0.07, delays=0.01/0.02/0/0.04,
dsn=2.0.0, status=sent (delivered via dovecot service)
On Mon, 9 Nov 2009 09:08:16 +0100 (CET), Steffen Kaiser
skdove...@smail.inf.fh-brs.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 7 Nov 2009, Moritz Krinke wrote:
Would be great if anyone had an idea what/where to check next...? ;-)
Are you sure your MTA calls Dovecot deliver at all?
See http://wiki.dovecot.org/Logging
Unset log_path in lda { } section to have all messages of deliver in
syslog and avoid permission problems. Then check the logs, e.g. if sieve
is mentioned there at all, the home dir sieve has determined, etc.pp.
Bye,
- --
Steffen Kaiser
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSvfN8HWSIuGy1ktrAQLdyAgAnwrkcaqz1392gLl8uUx4kxqOLLNVFIn+
FO16zDKI/687JCpoSM4lLb5oOCFWevE7iHYEtoc5IV3zRnR+8V9woK2XHSWmNSDH
2FEy1fkEaEot7sWYBvXtYVyru0zgQI7d3ELWVbyR80B1CJlSiqgl+Y0/0w4yXJ00
B67+NXA8i03lHQeJlcYxKyzVB3Tc24uWAHzMoBV7Ux5634gYb/8LN0ay/nAoyfCA
H0wN0NqRfdiniym3l802pAEx5b/MpjeuA8Vaw4Nl/4gMf3DMe6tb22Dr1LYYrQKa
zHRHWRrOeiAUAHVWVw2dZihweKA+k6eh624fGyZgHzexzv7/x3ET+Q==
=cw9K
-END PGP SIGNATURE-
[Dovecot] selective disable_plaintext_auth
Hi, I've been using dovecot for some time now, always with the setting: disable_plaintext_auth = yes so that no user can accidentally expose their username/password in the open. However, I'm now trying to configure a webmail client in a nearby server which doesn't support TLS or SSL IMAP connections :-( Is there any way to allow plaintext_auth only for a small set of IP addresses (for what I see in the comment, this is automatic for local addresses, alas, the webmail client is on another host). TIA -- Mariano Absatz - El Baby el.b...@gmail.com www.clueless.com.ar -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Theory is when you know something but it doesn't work. - Practice is when something works but you don't know why. - Usually we combine theory and practice: Nothing works and we don't know why. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- * TagZilla 0.066 * http://tagzilla.mozdev.org
Re: [Dovecot] dovecot-2.0.alpha2 doesn't compile on Mac OS X
Le 27 oct. 2009 à 20:21, Timo Sirainen a écrit : On Tue, 2009-10-27 at 13:13 -0500, Mike Abbott wrote: [...] [...] Although fdatasync() seems to have gone missing from .h files, but still exists in libc. I guess that's intentional? Hello Timo, Did Mike reply about that one? Still the case here with Mac OS 10.6.2: although undefined in any include file, the symbol still exists in libSystem.B.dylib and allows compilation (even if with a warning related to an implicit definition). On the other hand, the source code of xnu tends to be very circumspect wrt fdatasync(). TIA, Axel
Re: [Dovecot] UTF-8 mailbox names in filesystem
On Mon, 09 Nov 2009 21:11:23 -0500 Timo Sirainen t...@iki.fi wrote: Currently mailbox names are stored in IMAP's modified-UTF-7 format in filesystem. I was wondering about changing this in v2.0. The default would still be to use mUTF-7 in filesystem, but just adding :UTF8 or something to mail_location could enable UTF-8. Any thoughts? Could this be dangerous somehow? UTF-8 enables a lot of weird characters, perhaps no one really wants to see them on filesystem since there's no way to type the characters? But for small systems this probably isn't a problem. A while ago, I was playing around with the idea of encoded '/'s in Maildir names since many people have asked for a way to use them. UTF-7 does not require that each character be representable in only 1 way like UTF-8 does, so it's possible to encode US-ASCII characters and put them into the folder name; however, I found that most clients decode any mUTF-7 in folder names while parsing LIST/LSUB replies and then discard the name given by the server (expecting that they can just re-encode any non-ASCII characters and still arrive at the correct folder name.) While I would argue that these clients are buggy, the bug seems to be so common that encoding characters this way isn't practical. With that in mind, you do lose the ability to encode characters like this if the folder names on disk are UTF8, but that's not much of a loss anyway if UTF8 encoding is optional. So far as UTF-8 on the filesystem is concerned, I've been using UTF-8 in filenames on my personal systems for years now without any real issues. -- Ben Winslow r...@bluecherry.net
Re: [Dovecot] UTF-8 mailbox names in filesystem
On Tue, 2009-11-10 at 17:24 -0500, Ben Winslow wrote: A while ago, I was playing around with the idea of encoded '/'s in Maildir names since many people have asked for a way to use them. UTF-7 does not require that each character be representable in only 1 way like UTF-8 does, so it's possible to encode US-ASCII characters and put them into the folder name; This is explicitly disallowed by RFC 3501: Modified BASE64 MUST NOT be used to represent any printing US-ASCII character which can represent itself. Anyway, listescape plugin can already do that, as long as you're not using '/' as hierarchy separator. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dovecot-2.0.alpha2 doesn't compile on Mac OS X
On Tue, 2009-11-10 at 22:56 +0100, Axel Luttgens wrote: Although fdatasync() seems to have gone missing from .h files, but still exists in libc. I guess that's intentional? Hello Timo, Did Mike reply about that one? No. I'm also not sure what to do about it. I guess I could just try if compiler=gcc and compiling it fails with $CC -Wall -Werror and in that case fallback to fsync.. Kind of ugly. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] selective disable_plaintext_auth
On Tue, 2009-11-10 at 17:41 -0300, Mariano Absatz wrote: Is there any way to allow plaintext_auth only for a small set of IP addresses (for what I see in the comment, this is automatic for local addresses, alas, the webmail client is on another host). # Space separated list of trusted network ranges. Connections from these # IPs are allowed to override their IP addresses and ports (for logging and # for authentication checks). disable_plaintext_auth is also ignored for # these networks. Typically you'd specify your IMAP proxy servers here. #login_trusted_networks = signature.asc Description: This is a digitally signed message part
[Dovecot] Slow IMAP Auth
Hello, I am experiencing IMAP authentication delays when a client first authenticates, or after the last auth timeout. There are only a handful of clients - less than 5 - using the server. I am using a mysql database and I have verified the PAM auth is commented out. Other than that I can't figure out what might be causing the slow authentication. The first time a client authenticates with SSL/CRAMD5 it takes almost 20 seconds. Does anyone have any suggestions? My config and version is below: mail:~# dovecot --version 1.1.11 mail:/usr/share/gallery2# dovecot -n # 1.1.11: /etc/dovecot/dovecot.conf # OS: Linux 2.6.26-2-686 i686 Debian 5.0.3 ext3 log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login mail_max_userip_connections(default): 20 mail_max_userip_connections(imap): 20 mail_max_userip_connections(pop3): 10 first_valid_uid: 6060 mail_privileged_group: mail mail_location: maildir:/var/vmail/%d/%n mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugins(default): autocreate quota imap_quota mail_plugins(imap): autocreate quota imap_quota mail_plugins(pop3): quota mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 auth default: mechanisms: plain login cram-md5 passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf passdb: driver: sql
Re: [Dovecot] Slow IMAP Auth
I am looking into whether or not this is DNS related internally. Sent from an iPhone On Nov 10, 2009, at 10:18 PM, Jeff Duncan j...@fishoutercape.com wrote: Hello, I am experiencing IMAP authentication delays when a client first authenticates, or after the last auth timeout. There are only a handful of clients - less than 5 - using the server. I am using a mysql database and I have verified the PAM auth is commented out. Other than that I can't figure out what might be causing the slow authentication. The first time a client authenticates with SSL/ CRAMD5 it takes almost 20 seconds. Does anyone have any suggestions? My config and version is below: mail:~# dovecot --version 1.1.11 mail:/usr/share/gallery2# dovecot -n # 1.1.11: /etc/dovecot/dovecot.conf # OS: Linux 2.6.26-2-686 i686 Debian 5.0.3 ext3 log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login mail_max_userip_connections(default): 20 mail_max_userip_connections(imap): 20 mail_max_userip_connections(pop3): 10 first_valid_uid: 6060 mail_privileged_group: mail mail_location: maildir:/var/vmail/%d/%n mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugins(default): autocreate quota imap_quota mail_plugins(imap): autocreate quota imap_quota mail_plugins(pop3): quota mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 auth default: mechanisms: plain login cram-md5 passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf passdb: driver: sql
Re: [Dovecot] selective disable_plaintext_auth
On Tue, Nov 10, 2009 at 19:44, Timo Sirainen t...@iki.fi wrote: On Tue, 2009-11-10 at 17:41 -0300, Mariano Absatz wrote: Is there any way to allow plaintext_auth only for a small set of IP addresses (for what I see in the comment, this is automatic for local addresses, alas, the webmail client is on another host). # Space separated list of trusted network ranges. Connections from these # IPs are allowed to override their IP addresses and ports (for logging and # for authentication checks). disable_plaintext_auth is also ignored for # these networks. Typically you'd specify your IMAP proxy servers here. #login_trusted_networks = It seems my version is too old for this... I'm using the standard ubuntu server package (1.1.11-0ubuntu4.1 http://packages.ubuntu.com/jaunty-updates/dovecot-imapd), which seems to be 1.1.11 plus security patches... In what version did this feature appears? -- Mariano Absatz - El Baby www.clueless.com.ar
[Dovecot] Error: read(/var/run/dovecot/dict-server) failed: Remote disconnected
Hello all,
I have a problem with my mail configuration and I don`t know how to resolve
this error (listed bellow):
deliver(mym...@testtest.ro): Nov 11 09:07:54 Error: Internal quota calculation
error
dovecot: Nov 11 09:07:54 Error: dict: /etc/dovecot/dovecot-dict-quota.conf:
'username_field' missing
dovecot: Nov 11 09:07:54 Error: dict: Failed to initialize dictionary 'quota1'
deliver(mym...@testtest.ro): Nov 11 09:07:54 Error:
read(/var/run/dovecot/dict-server) failed: Remote disconnected
deliver(mym...@testtest.ro): Nov 11 09:07:54 Error: Internal quota calculation
error
dovecot: Nov 11 09:07:56 Error: dict: /etc/dovecot/dovecot-dict-quota.conf:
'username_field' missing
dovecot: Nov 11 09:07:56 Error: dict: Failed to initialize dictionary 'quota1'
My dovecot configuration is:
dovecot -n
# 1.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.27.7-9-pae i686 openSUSE 11.1 (i586) ext3
log_path: /var/log/dovecot.err
info_log_path: /var/log/dovecot.info
ssl_disable: yes
disable_plaintext_auth: no
login_dir: /var/run/dovecot/login
login_executable: /usr/lib/dovecot/imap-login
first_valid_uid: 5000
last_valid_uid: 5000
mail_location: maildir:/home/vmail/%d/%n
mail_debug: yes
mail_plugins: quota imap_quota
auth default:
mechanisms: plain login
user: vmail
verbose: yes
passdb:
driver: pam
passdb:
driver: sql
args: /etc/dovecot/dovecot-mysql.conf
userdb:
driver: sql
args: /etc/dovecot/dovecot-mysql.conf
userdb:
driver: prefetch
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 432
user: vmail
group: vmail
plugin:
quota: dict:::proxy::quota1
quota_rule: *:storage=50M:messages=1
acl: vfile:/etc/dovecot/acls
quota_warning: storage=95%% /usr/local/bin/quota-warning.sh 95
quota_warning2: storage=80%% /usr/local/bin/quota-warning.sh 80
dict:
quota1: mysql:/etc/dovecot/dovecot-dict-quota.conf
Another question that raise from these logs is what are the permissions for all
files from /var/run/dovecot?
In the master.cf file I have somthing like this:
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
Regarding this log : dovecot: Nov 11 09:07:54 Error: dict:
/etc/dovecot/dovecot-dict-quota.conf: 'username_field' missing, my
dovecot-dict-quota.conf is correctly and that field exists.
So...any idea?
Thanks!
[Dovecot] System Users with IMAP
Hi All, Sorry if this is a dumb questions, but what methods are available for retrieving mail for a system user i.e www-data. Basically my setup is just a normal Dovecot-IMAP which is working fine for shell users, but I want to be able to read mail for system users via IMAP. Is this doable? Cheers
