- dovecot - dovecot.org

Re: [Dovecot] HTTP passdb (was: feature request: IMAP passdb prefetch)
by Timo Sirainen 02 Aug '13

02 Aug '13

(Cc'd to dovecot list anyway since other people might be interested) On 2.8.2013, at 18.34, Richard Platel <rplatel(a)tucows.com> wrote: >> Uh. Why not simply something completely different like HTTP-based passdb? > > I can't find info for HTTP on the wiki, can we set that up as a success/fail passdb? We do our own password auth (so we can support custom hash types, etc). I've only a private version of a HTTP-based passdb implemented for a customer. I'm not sure if I should bother adding something to be distributed with Dovecot, since I guess most people would want to modify it in some way anyway. Here's a somewhat modified version of it that hopefully works (at least it compiles): http://dovecot.org/patches/2.2/passdb-openam.c

1 0

[Dovecot] feature request: IMAP passdb prefetch
by Richard Platel 02 Aug '13

02 Aug '13

> On 2.8.2013, at 18.20, Richard Platel <rplatel(a)tucows.com> wrote: > >> It'd be useful for us if the IMAP passdb could be used as a prefetch userdb. >> >> The remote IMAP server could respond with something like >> >> * OK key=value >> * OK key=value >> SEQ OK [CAPABILITY ...] Logged in. >> >> Or >> >> * OK <some JSON key value pairs> >> SEQ OK [CAPABILITY ...] Logged in. >> >> Would anyone else find this useful? > > Uh. Why not simply something completely different like HTTP-based passdb? > I can't find info for HTTP on the wiki, can we set that up as a success/fail passdb? We do our own password auth (so we can support custom hash types, etc).

1 0

[Dovecot] feature request: IMAP passdb prefetch
by Richard Platel 02 Aug '13

02 Aug '13

It'd be useful for us if the IMAP passdb could be used as a prefetch userdb. The remote IMAP server could respond with something like * OK key=value * OK key=value SEQ OK [CAPABILITY ...] Logged in. Or * OK <some JSON key value pairs> SEQ OK [CAPABILITY ...] Logged in. Would anyone else find this useful?

2 1

Re: [Dovecot] Mail being delivered but MUA showing empty inbox
by Nigel Smith 02 Aug '13

02 Aug '13

> You should take this discussion off list. Tell me Dem.... which part of my original question was not fit for the list ? It was a perfectly valid technical question relating to Dovecot, and according to the description of the mailing list "This is the main list for requesting help with Dovecot or talking about it in general" So I was "requesting help" with Dovecot, and everyone else is perfectly within their rights to "talk about it".

1 0

[Dovecot] 2.2.4 - Some questions about and needing help with quota-status
by Axel Luttgens 02 Aug '13

02 Aug '13

Help! I'm stuck. :-( The config of my experimental setup appears at the end of this message; I'm providing hereafter some more info that may not be immediately obvious. This is dovecot 2.2.4 with changesets 9091d0f2d971 and 2be295a0b64f. All involved databases are sqlite ones. passdb and userdb are devised so as to change usernames. For example, I could have a user with addresses "doe(a)oldexample.com", "johnd(a)oldexample.com" and "john.doe(a)example.com" needing to be able to log in as "jdoe" or "u123456"; all db lookups for that user then end with name "john.doe". This is a single mail user setup (user/group "dovemailer", uid/gid 999). Service lmtp has been configured to run as that user; that required a slight adjustment at the auth-userdb socket level. As a general rule, the quota dict appears to be correctly updated upon message arrivals and removals (thru lmtp, pop, imap), and to be correctly queried/interpreted by the various parts of the server. For example, thru the userdb query, user john.doe has been given an even lower quota limit than the already low default defined for testings: $ sudo doveadm quota get -u john.doe Quota name Type Value Limit % Quota utilisateur STORAGE 20 5 400 Quota utilisateur MESSAGE 14 - 0 and is clearly recognized as being over-quota by lmtp: $ telnet /_ROOT/var/run/dovecot/lmtp Trying /_ROOT/var/run/dovecot/lmtp... Connected to (null). Escape character is '^]'. 220 almba.local Dovecot ready. mail from:<mary.jane(a)example.com> 250 2.1.0 OK rcpt to:<john.doe(a)example.com> 250 2.1.5 OK data 354 OK Subject: test . 552 5.2.2 <john.doe(a)example.com> Quota exceeded (mailbox for user is full) Note that both services config and dict are launched if they aren't running. Since it has been previously seen that running quota-status as root comes with its own problems, and since it is a single user setup anyway, I'm trying to run it as dovemailer as well. So, let's try to see what quota-status thinks about john.doe: $ sudo -u _postfix telnet /_ROOT/var/spool/postfix/private/quota-policyd Trying /_ROOT/var/spool/postfix/private/quota-policyd... Connected to (null). Escape character is '^]'. Connection closed by foreign host. Clearly, not much... Looking in the log: dovecot[10554]: quota-status: Fatal: Error reading configuration: net_connect_unix(/_ROOT/var/run/dovecot/config) failed: Permission denied This thus raises a first question: Q1. What makes lmtp and quota-status different? How does lmtp manage to fetch all needed info, while quota-status seems to require an access to the config socket? Let's then slightly adjust dovecot.conf, in the hope to make quota-status happy: service config { unix_listener config { group = dovemailer mode = 0660 } } Q2. Should the above really be needed, wouldn't there be a better way? I ask, because it seems to me that I'm starting to seriously lose the benefits of privilege separation... Anyway, let's ask quota-status again: $ sudo -u _postfix telnet /_ROOT/var/spool/postfix/private/quota-policyd Password: Trying /_ROOT/var/spool/postfix/private/quota-policyd... Connected to (null). Escape character is '^]'. recipient=john.doe(a)example.com size=10000 action=OK ^] telnet> quit Connection closed. In the log: dovecot[11050]: auth: Debug: userdb out: USER 1 john.doe(a)example.com quota_rule=*:storage=5k dovecot[11050]: quota-status: Debug: auth input: john.doe(a)example.com quota_rule=*:storage=5k dovecot[11050]: quota-status: Debug: Added userdb setting: plugin/quota_rule=*:storage=5k dovecot[11050]: quota-status(john.doe(a)example.com): Debug: Effective uid=999, gid=999, home=/_Mailstores/john.doe dovecot[11050]: quota-status(john.doe(a)example.com): Debug: Quota root: name=Quota utilisateur backend=dict args=john.doe:proxy::sql_quota dovecot[11050]: quota-status(john.doe(a)example.com): Debug: Quota rule: root=Quota utilisateur mailbox=* bytes=5120 messages=0 dovecot[11050]: quota-status(john.doe(a)example.com): Debug: Quota grace: root=Quota utilisateur bytes=512 (10%) dovecot[11050]: quota-status(john.doe(a)example.com): Debug: dict quota: user=john.doe, uri=proxy::sql_quota, noenforcing=0 dovecot[11050]: quota-status(john.doe(a)example.com): Debug: fs: root=/_Mailstores/john.doe/mboxes, index=, indexpvt=, control=, inbox=/_Mailstores/john.doe/mboxes/inbox, alt= It is to be noted that the config server is now launched as expected, but that the dict server still isn't. Trying a dirsize backend instead of the dict backend doesn't help. The problem seems to be circumscribed to the interaction with the quota backend since, for example, querying quota-status for an unknown recipient yields an expected "action=REJECT Unknown user". Hence my last question, after having tried a lot of things for several days now, with no more success: Q3. What am I doing wrong? Many thanks in advance, Axel # 2.2.4: /_ROOT/etc/dovecot/dovecot.conf # OS: Darwin 12.4.0 x86_64 auth_debug = yes dict { sql_quota = sqlite:/_ROOT/etc/dovecot/dict-quota.conf } disable_plaintext_auth = no listen = * mail_debug = yes mail_gid = dovemailer mail_home = /_Mailstores/%n mail_location = mbox:~/mboxes:INBOX=~/mboxes/inbox mail_plugins = quota mail_uid = dovemailer managesieve_sieve_capability = vacation mbox_write_locks = fcntl passdb { args = /_ROOT/etc/dovecot/db.conf driver = sql } plugin { quota = dict:Quota utilisateur:%n:proxy::sql_quota quota_rule = *:storage=50M sieve = ~/sieve/active_script.sieve sieve_dir = ~/sieve/scripts sieve_extensions = vacation sieve_max_actions = 3 sieve_max_redirects = 2 sieve_max_script_size = 10K sieve_user_log = ~/sieve/log } service auth { unix_listener auth-userdb { group = dovemailer mode = 0660 user = $default_internal_user } } service dict { unix_listener dict { group = dovemailer mode = 0660 } } service lmtp { group = dovemailer user = dovemailer } service quota-status { client_limit = 1 executable = quota-status -p postfix group = dovemailer unix_listener /_ROOT/var/spool/postfix/private/quota-policyd { user = _postfix } user = dovemailer } ssl = no userdb { driver = prefetch } userdb { args = /_ROOT/etc/dovecot/db.conf driver = sql } protocol lmtp { mail_plugins = quota sieve postmaster_address = postmaster(a)example.com sendmail_path = /_ROOT/postfix/sbin/sendmail } protocol pop3 { pop3_uidl_format = %08Xv%08Xu }

2 9

[Dovecot] mails delivered to the wrong user when using lmtp_proxy and reject_unverified_recipient
by Peer Heinlein 02 Aug '13

02 Aug '13

Hi, looks like we detected a serious bug in dovecot's lmtp proxying where e-mails are delivered to the wrong user. The setup is: *) Dovecot is configured with "lmtp_proxy=yes" # Support proxying to other LMTP/SMTP servers by performing passdb lookups. lmtp_proxy = yes *) Postfix uses "dynamic recipient verification", so Postfix starts sending a (verify) mail by LMTP to dovecot, but quits the lmtp-session right after the RCPT TO:. No DATA-stage is reached in the protocol and no real e-mail is sent. But Postfix had a LMTP-connection for "user1". *) Just some seconds later a "real" e-mail to "user2" has to be delivered to dovecot by LMTP. But Dovecot will deliver this mail to the wrong "user1" instead of "user2". Looks like dovecot re-uses the (still opened?) lmtp-proxy-connection from "user1" to deliver an e-mail to "user2". Have a log at the protocol: 1) There's a verify call to user1 from Postfix: Jul 19 13:49:49 mailms postfix/lmtp[9842]: DE653280C51: to=<user1(a)example.com>, relay=localhost[127.0.0.1]:24, conn_use=2, delay=120, delays=117/0.45/0/2.5, dsn=2.1.5, status=deliverable (250 2.1.5 OK) 2) Just five seconds later the e-mail to user2 (see Postfix' point of view in the last line) is delivered to user2 (see result from Dovecot in the last line): Jul 19 13:50:04 mailms dovecot: lmtp(10965, kraemer): save: box=INBOX, uid=49880, msgid=<59798276-E5D1-4053-A570-9901B731DF5D(a)example.come>, size=11020 Jul 19 13:50:04 mailms dovecot: lmtp(10965, kraemer): 1zTeKrMn6VHVKgAAhyqEuA: msgid=<59798276-E5D1-4053-A570-9901B731DF5D(a)example.com>: saved mail to INBOX Jul 19 13:50:04 mailms postfix/lmtp[10953]: C25FC280BE5: to=<user2(a)example.com>, relay=localhost[127.0.0.1]:24, conn_use=19, delay=116, delays=115/0.53/0/0.33, dsn=2.0.0, status=sent (250 2.0.0 <user2> 1zTeKrMn6VHVKgAAhyqEuA Saved) Same with user3 and user4: Jul 19 14:47:53 mailms postfix/lmtp[10845]: C389A2809D7: to=<user3(a)example.com>, relay=localhost[127.0.0.1]:24, delay=4.7, delays=3.7/0.87/0/0.19, dsn=2.1.5, status=deliverable (250 2.1.5 OK) Jul 19 14:47:55 mailms dovecot: lmtp(26546, fs211113): save: box=INBOX, uid=8504, msgid=<928729810.113.1374238063381(a)example.com>, size=233151 Jul 19 14:47:55 mailms dovecot: lmtp(26546, fs211113): MbMvI2816VGyZwAAhyqEuA: msgid=<928729810.113.1374238063381(a)example.com>: saved mail to INBOX Jul 19 14:47:55 mailms postfix/lmtp[22524]: 6F0D2280A6E: to=<user4(a)example.com>, relay=localhost[127.0.0.1]:24, conn_use=2, delay=10, delays=8.4/1/0/0.8, dsn=2.0.0, status=sent (250 2.0.0 <user3> MbMvI2816VGyZwAAhyqEuA Saved) The user itself is quite normal in the user database (but has a mailhost=127.0.0.1 set): root@mailms:/etc/dovecot/conf.d# doveadm user user2(a)example.com userdb: user2(a)example.com uid : 5000 gid : 5000 home : /srv/mail/user2 root@mailms:/etc/dovecot/conf.d# doveadm auth user2(a)example.com Password: passdb: user2(a)example.com auth failed extra fields: user=user2 Peer -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-42 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin

4 3

[Dovecot] Auth-woker log lines
by Grzegorz Staniak 02 Aug '13

02 Aug '13

Hi, Are log lines like the following: Jul 28 15:30:50 mx1.somewhere dovecot: auth-worker(18980): sql(user(a)domain,217.67.x.x): unknown user Jul 28 15:32:56 mx1.somewhere dovecot: auth-worker(18980): sql(user(a)domain,212.182.x.x): Password mismatch written every time any authetntication phase fails, in SASL as well as in POP3/IMAP mailbox access? I have a legacy app that would gain a lot if I could distinguish between failed SASL authentication and failed POP3/IMAP authentication. I know I can use the "auth failed" lines for the latter case, and postfix log lines in the former, but they don't contain user info. Is there a way for log monitoring software to get failed login lines with both user info, and the reason (SASL, POP3, IMAP)? Regards, -- Grzegorz Staniak <gstaniak [at] gmail _dot_ com>

2 1

[Dovecot] 2.2.4 - quota-status changing the user it is running as
by Axel Luttgens 02 Aug '13

02 Aug '13

Hello, I'm currently experimenting with this quota-status service configuration: service quota-status { client_limit = 1 executable = quota-status -p postfix # Let's make the default explicit. user = root unix_listener /var/spool/postfix/private/quota-policyd { user = postfix } } The idea is to run the service as root during the preliminary tests (at worst, since the service is going to be used as a policy daemon by Postfix only, it shouldn't be very problematic to have it running as root anyway). A user, with address john.doe(a)example.com and identified as john.doe, is known to be over-quota. A "doveadm quota get" returns: $ sudo doveadm quota get -u john.doe Password: Quota name Type Value Limit % Quota utilisateur STORAGE 5 5 100 Quota utilisateur MESSAGE 9 - 0 and messages for that user are correctly rejected by lmtp: dovecot[4989]: lmtp(5069, john.doe(a)example.com) QWSWLgrP4lF7FAAA5Q0ykw: msgid=<20130714161643.9085DF176F2(a)ALMba.local>: save failed to INBOX: Quota exceeded (mailbox for user is full) Let's now simulate a connection from Postfix: $ sudo -u postfix telnet /_ROOT/var/spool/postfix/private/quota-policyd Trying /_ROOT/var/spool/postfix/private/quota-policyd... Connected to (null). Escape character is '^]'. A look at the output of top (excerpt) confirms that quota-status is running as root: PID COMMAND UID 5100 quota-status 0 Going on with our telnet session: recipient=john.doe(a)example.com size=10000 action=OK Hmmm... OK, this may be a config problem of mine which may require further investigation. Anyway, looking at top's output: PID COMMAND UID 5100 quota-status 999 it appears that quota-status is now running as the mail_uid/mail_gid user; the switch happens immediately after having entered the empty line in the telnet session. Let's then try to go further within the telnet session: recipient=john.doe(a)example.com size=10000 action=DEFER_IF_PERMIT Internal error occurred. Refer to server log for more information. ^] telnet> quit Connection closed. and a look at the log indeed reveals that quota-status doesn't have sufficient privileges anymore: dovecot[4989]: quota-status(john.doe(a)example.com): Error: user john.doe(a)example.com: Error reading configuration: net_connect_unix(/_ROOT/var/run/dovecot/config) failed: Permission denied Is this the expected behavior, to have quota-status switch to another user? TIA, Axel

3 8

[Dovecot] [PATCH] quota-status: allow different action for messages that are too large (over maximum quota)
by Ulrich Zehl 02 Aug '13

02 Aug '13

This proposed patch to quota-status allows the administrator to return different actions for messages that (a) cannot currently fit in the quota (because there's not enough free space) and (b) are over the maximum quota limit (and could not even be delivered if the mailbox was empty). Configuration works like this: plugin { quota_status_overquota = DEFER_IF_PERMIT 4.2.2 Mailbox full quota_status_toolarge = REJECT 5.2.3 Message length exceeds administrative limit } The patch is backwards compatible: If quota_status_toolarge is not set, quota_status_overquota is returned. No changes are necessary in setups where the new feature is not desired. The reason I developed this patch is: In my environment, I have mostly POP3 mailboxes, where condition (a) changes frequently (usually after each login), but condition (b) will almost never change (users do not get additional mailbox space often). Thus, I'd like to avoid bouncing mails that could be delivered half an hour later. This patch works for 2.2 and 2.1. (This assumes you have already applied the trivial patch I sent earlier; otherwise patch(1) will report some fuzz.) What do you think of this? Ulrich --- a/src/plugins/quota/quota-status.c 2013-08-01 18:05:24.000000000 +0200 +++ b/src/plugins/quota/quota-status.c 2013-08-01 18:03:30.000000000 +0200 @@ -46,13 +46,12 @@ } static int -quota_check(struct mail_user *user, uoff_t mail_size, const char **error_r) +quota_check(struct mail_user *user, uoff_t mail_size, const char **error_r, bool *too_large) { struct quota_user *quser = QUOTA_USER_CONTEXT(user); struct mail_namespace *ns; struct mailbox *box; struct quota_transaction_context *ctx; - bool too_large; int ret; if (quser == NULL) { @@ -64,7 +63,7 @@ box = mailbox_alloc(ns->list, "INBOX", 0); ctx = quota_transaction_begin(box); - ret = quota_test_alloc(ctx, I_MAX(1, mail_size), &too_large); + ret = quota_test_alloc(ctx, I_MAX(1, mail_size), too_large); quota_transaction_rollback(&ctx); mailbox_free(&box); @@ -82,6 +81,7 @@ struct mail_storage_service_user *service_user; struct mail_user *user; const char *value = NULL, *error; + bool too_large; int ret; if (client->recipient == NULL) { @@ -98,14 +98,21 @@ if (ret == 0) { value = nouser_reply; } else if (ret > 0) { - if ((ret = quota_check(user, client->size, &error)) > 0) { + if ((ret = quota_check(user, client->size, &error, &too_large)) > 0) { /* under quota */ value = mail_user_plugin_getenv(user, "quota_status_success"); if (value == NULL) value = "OK"; } else if (ret == 0) { - /* over quota */ - value = mail_user_plugin_getenv(user, "quota_status_overquota"); + if (too_large == TRUE) { + /* even over maximum quota */ + value = mail_user_plugin_getenv(user, "quota_status_toolarge"); + if (value == NULL) /* backwards compatibility */ + value = mail_user_plugin_getenv(user, "quota_status_overquota"); + } else { + /* over quota */ + value = mail_user_plugin_getenv(user, "quota_status_overquota"); + } if (value == NULL) value = t_strdup_printf("554 5.2.2 %s", error); }

2 1

Re: [Dovecot] LDA vs. LMTP
by Joseph Tam 02 Aug '13

02 Aug '13

(Weird: this message digest got dumped into Google's spam folder. Maybe it didn't like the string in a later post (obfuscated here) master(dot)cf, which in the context of this mailing list is a postfix configuration file, but which Gmail interpret as a website. However, that domain is a SURBL/DBL blacklisted URI). Ben Morrow writes: > > > And when it's running as root there is always the danger > > > of privilege escalation. LDA only runs when it's needed and since it > > > uses only user rights it shoudbe more harmless. > > > > ... > > (I'm assuming LMTP stays as root, and not spawning off user > > processes to do the real work.) > > It doesn't stay as root; Dovecot's LMTP switches down to the user's uid > to perform delivery, including sieve scripts. I stand corrected. This removes the other objection that the original poster for running a peristent LMTP process. Joseph Tam <jtam.home(a)gmail.com>

1 0