Re: The future of SIS

[Gedalya via dovecot]

On 10/14/23 03:26, Laura Smith via dovecot wrote:
> FUD ? 
>
> I knew someone would accuse me of that which is why I linked to the video 
> from the horse's mouth, I transcribe what the speaker said:
>
> "there will be an open source version, but that open source version will be 
> maintained for single server use only. we are actually taking out anything 
> any actually kinda' involves multiple servers, dsync replication and err some 
> other stuff. so dovecot will be a fully-featured single node server"
>
Yes.

Aki, it would be much appreciated if you can deliver your point in the form of 
a clarification of what the product manager actually said in that video, in 
very clear language.

Thanks!


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Disable folder creation for details username

[Gedalya]

On 3/17/23 20:23, Robert Blayzor wrote:
> We understand there is:
> lda_mailbox_autocreate
>
> Which we have yes, as we do want to create mailboxes automatically when the 
> first message comes in, but not these folders. 

That's the setting you want. In IMAP / dovecot context, "mailbox" means 
"folder".

The basic directory structure for an account, with INBOX and the various 
mailboxes ("folders") as defined in your namespace / mailbox configuration 
where auto = [create|subscribe], will still be created automatically as soon as 
the first message arrives.

Re: Question about line length limit in lmtp.

[Gedalya]

On 12/8/22 17:41, Aki Tuomi wrote:
> This is something that is usually handled automatically and does not affect 
> the mails you see in your MUA. The folding is done within the protocol.

Again, I find this statement quite strange. I'm not relying on any MUA when I 
say long lines appear to be kept unfolded in storage.

The scenario is an MTA e.g. exim delivering mail with long lines to dovecot 
LMTP. If you're saying I'm definitely wrong then I'd have to test again.

As for submission, are you saying that if a client is submitting mail with long 
lines, submission will fold the lines before passing it on? And this would make 
sense because DKIM signing occurs later?

Re: Question about line length limit in lmtp.

[Gedalya]

On 12/8/22 17:29, Aki Tuomi wrote:
> Dovecot LMTP and Submission enforce the RFC line length, which is 1000, 
> including \r\n.

Can you elaborate on this?

I often get mail coming in from the wild with long lines and I find the most 
practical approach is to pass it on to dovecot LMTP as is, and it just works, 
and the message is stored with long lines, not folded.

I haven't tried dovecot's submission yet.

What exactly can you tell me about line length limits in LMTP and submission 
and can it be configured?

Re: sieve script is too large (max 1048576 bytes)

[Gedalya]

On 10/17/22 18:43, Marc wrote:
> In what section of the config is this limited?

plugin {
    sieve_max_script_size = 1M
}

Re: mdbox vs. maildir format

[Gedalya]

On 10/19/22 07:46, Steve Litt wrote:

>> for MAILBOX in $USERS; do
>>  doveadm expunge -u "$MAILBOX" mailbox Trash savedbefore 7d
>>  doveadm expunge -u "$MAILBOX" mailbox Spam savedbefore 30d
>>  doveadm purge -u "$MAILBOX"
>>
>>  LOCATION2="mdbox:/srv/snap_mail/$MAILBOX/mdbox"
>>  doveadm -v backup -u "$MAILBOX" -P "$LOCATION2"
>> done
>>
> Do you think the preceding shellscript will work if I store my Dovecot 
> messages in
> the Maildir form?

It would, including this part:  LOCATION2="mdbox:..."
You can use that as a way to convert between storage formats. Or not. Specify 
what is needed.

Re: mdbox vs. maildir format

[Gedalya]

On 10/18/22 18:46, Marc wrote:
>> you must not lose the dbox index files, as they can’t be
>>  regenerated without data loss.
> I have read this also, and was also worried about this, but when I look at 
> the flat m.988 file, I still have quite a lot of useful data there.

"Note that with dbox the Index files contain significant data which is held 
nowhere else. Index files for both sdbox and mdbox contain message flags and 
keywords. For mdbox, the index file also contains the map_uids which link (via 
the “map index”) to the actual message data. This data cannot be automatically 
recreated, so it is important that Index files are treated with the same care 
as message data files."

https://doc.dovecot.org/admin_manual/mailbox_formats/dbox/

Re: mdbox vs. maildir format

[Gedalya]

On 10/18/22 18:17, Michael wrote:
> what about backup? how can i achieve a backup/snapshot of both, the mdbox 
> (nfs share) and the index files (local raid) and assure they are consistent? 

If you do your backups using doveadm backup, then the result should be 
consistent, at least in the sense that it would be usable. Your destination can 
also be set up similarly with separate storage for indexes.

However I'm pretty sure the consistency would be per mailbox ("folder"), so 
e.g. if a user moved a message from one mailbox to another, you could 
potentially end up with the message appearing in both mailboxes in the backup.

Re: dovecot-lda -> lmtp server ?

[Gedalya]

On 10/17/21 02:01, Scott Q. wrote:
> I'm stuck with using Qmail which has no LMTP support, and thus I'm using 
> dovecot-lda which has certain drawbacks.
>
> Has anyone found a way to direct dovecot-lda to deliver the mail to the LMTP 
> server or any other way for Qmail to deliver the mail to the LMTP server 
> directly ?
>
Just a thought off the top of my head: you could perhaps pipe the mail to exim 
instead of dovecot-lda and that can easily be configured to deliver to LMTP

Re: Panic during IMAP APPEND

[Gedalya]

On 9/24/21 16:05, Gedalya wrote:
> I'll wait for the remaining users to return and report again.

All good.

Re: Panic during IMAP APPEND

[Gedalya]

On 9/21/21 04:45, Gedalya wrote:
> It might be a couple of days before I can confirm this is fixed.

Interim update: some but not all affected users have been active again with no 
errors.

I'll wait for the remaining users to return and report again.

So far I haven't been able to reproduce the issue on an unpatched server.

Re: Panic during IMAP APPEND

[Gedalya]

On 9/21/21 04:45, Gedalya wrote:
> Built, installed on two boxes.

No, Sorry, Stephan, I actually built it without the patch.

I had trouble with the patch, I had to refactor it by hand.

Did you forget a ) in line 745?

if (mevent->dest_mail_uid > 0)

Building now. At least the patch really did apply cleanly this time. Attached.



--- a/pigeonhole/src/plugins/imapsieve/imap-sieve-storage.c
+++ b/pigeonhole/src/plugins/imapsieve/imap-sieve-storage.c
@@ -581,6 +581,7 @@
 		return;
 
 	i_assert(ismt->src_mail_trans->box == src_box);
+	i_assert(mevent->src_mail_uid > 0);
 
 	if (*src_mail == NULL)
 		*src_mail = mail_alloc(ismt->src_mail_trans, 0, NULL);
@@ -741,11 +742,18 @@
 		bool fatal;
 
 		/* Determine UID for saved message */
-		if (mevent->dest_mail_uid > 0 ||
-			!seq_range_array_iter_nth(, mevent->save_seq, ))
+	if (mevent->dest_mail_uid > 0)
 			uid = mevent->dest_mail_uid;
+		else if (!seq_range_array_iter_nth(, mevent->save_seq,
+		)) {
+/* already gone for some reason */
+imap_sieve_mailbox_debug(
+	sbox, "Message for Sieve event gone");
+continue;
+		}
 
 		/* Select event message */
+		i_assert(uid > 0);
 		if (!mail_set_uid(mail, uid) || mail->expunged) {
 			/* already gone for some reason */
 			imap_sieve_mailbox_debug(sbox,

Re: Panic during IMAP APPEND

[Gedalya]

On 9/21/21 04:12, Stephan Bosch wrote:
> If you have the opportunity to apply and test patches, this should fix it:

Built, installed on two boxes.

Unfortunately, the users who were experiencing this issue seem to be inactive 
as of about 2 hours ago.

It might be a couple of days before I can confirm this is fixed.

Re: Panic during IMAP APPEND

[Gedalya]

On 9/21/21 00:04, Gedalya wrote:
> Mailbox format is Maildir

Migrating to mdbox didn't help. "doveadm force-resync -u u@d \*" also didn't 
help.

Getting exactly the same message and backtrace.

Panic during IMAP APPEND

[Gedalya]

I don't know how I can tell which mailbox is selected / being appended to.

Mailbox format is Maildir. Filesystem is XFS.

System was upgraded from 2.2.36.1 to 2.3.16, and it seems this started 
happening following that.

Sep 20 15:49:34 imap1 dovecot: imap(u@d)<17673>: Panic: file 
mail-index-map.c: line 558 (mail_index_map_lookup_seq_range): assertion failed: 
(first_uid > 0)
Sep 20 15:49:34 imap1 dovecot: imap(u@d)<17673>: Error: Raw 
backtrace: /usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x42) 
[0x7f363c72dc22] -> /usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) 
[0x7f363c72dd3e] -> /usr/lib/dovecot/libdovecot.so.0(+0xff47b) [0x7f363c73c47b] 
-> /usr/lib/dovecot/libdovecot.so.0(+0xff511) [0x7f363c73c511] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x5427c) [0x7f363c69127c] -> 
/usr/lib/dovecot/libdovecot-storage.so.0(+0x49e07) [0x7f363c84fe07] -> 
/usr/lib/dovecot/libdovecot-storage.so.0(+0xf0499) [0x7f363c8f6499] -> 
/usr/lib/dovecot/libdovecot-storage.so.0(mail_index_lookup_seq+0xf) 
[0x7f363c8ff20f] -> 
/usr/lib/dovecot/libdovecot-storage.so.0(index_mail_set_uid+0x2f) 
[0x7f363c8cf79f] -> /usr/lib/dovecot/libdovecot-storage.so.0(mail_set_uid+0x35) 
[0x7f363c8559a5] -> 
/usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so(+0x8d02) [0x7f363c255d02] 
-> /usr/lib/dovecot/modules/lib10_quota_plugin.so(+0x130f4) [0x7f363c45e0f4] ->
/usr/lib/dovecot/libdovecot-storage.so.0(mailbox_transaction_commit_get_changes+0x56)
 [0x7f363c8628a6] -> dovecot/imap [u@d xx.xx.xx.xx APPEND](+0x13e10) 
[0x55eae70f8e10] -> dovecot/imap [u@d xx.xx.xx.xx APPEND](command_exec+0xa4) 
[0x55eae7104844] -> dovecot/imap [u@d xx.xx.xx.xx APPEND](+0x1333b) 
[0x55eae70f833b] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) 
[0x7f363c752869] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x132) 
[0x7f363c7546d2] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) 
[0x7f363c754780] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) 
[0x7f363c754940] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) 
[0x7f363c6c4dd3] -> dovecot/imap [u@d xx.xx.xx.xx APPEND](main+0x500) 
[0x55eae70f7120] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) 
[0x7f363c49ad0a] -> dovecot/imap [u@d xx.xx.xx.xx APPEND](_start+0x2a) 
[0x55eae70f721a]
Sep 20 15:49:34 imap1 dovecot: imap(u@d)<17673>: Fatal: 
master: service(imap): child 17673 killed with signal 6 (core dumped)

# doveconf -n
# 2.3.16 (): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.16 (09c29328)
# OS: Linux 5.10.0-8-amd64 x86_64 Debian 11.0
# Hostname: imap1.x.com
auth_default_realm = x.com
auth_master_user_separator = *
auth_mechanisms = plain login cram-md5
auth_proxy_self = xx
auth_verbose = yes
auth_verbose_passwords = plain
dict {
  lastlogin = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
  quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
}
disable_plaintext_auth = no
doveadm_password = # hidden, use -P to show it
imap_hibernate_timeout = 10 secs
lmtp_rcpt_check_quota = yes
log_timestamp = "%Y-%m-%d %H:%M:%S "
login_greeting = Dovecot ready
login_log_format_elements = user=<%u> method=%m rip=%r lip=%l pip=%{real_rip} 
mpid=%e %c %k session=<%{session}>
login_trusted_networks = x
mail_attachment_detection_options = add-flags-on-save
mail_gid = vmail
mail_location = /nowhere
mail_plugins = quota listescape
mail_privileged_group = mail
mail_uid = vmail
managesieve_sieve_capability = fileinto envelope encoded-character subaddress 
comparator-i;ascii-numeric relational regex imap4flags copy include variables 
mailbox date index ihave duplicate mime foreverypart extracttext
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
    auto = subscribe
    special_use = \Drafts
  }
  mailbox Junk {
    auto = subscribe
    autoexpunge = 30 days
    special_use = \Junk
  }
  mailbox Sent {
    auto = subscribe
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    special_use = \Sent
  }
  mailbox Trash {
    auto = subscribe
    autoexpunge = 30 days
    special_use = \Trash
  }
  mailbox Trash/* {
    autoexpunge = 30 days
  }
  prefix =
  separator = /
  type = private
}
passdb {
  args = /etc/dovecot/master-users
  driver = passwd-file
  master = yes
  pass = yes
}
passdb {
  args = /etc/dovecot/dovecot-sql.conf.ext
  driver = sql
}
plugin {
  imapsieve_mailbox1_before = file:/usr/local/lib/imapsieve/report-spam.sieve
  imapsieve_mailbox1_causes = COPY APPEND
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox2_before = file:/usr/local/lib/imapsieve/report-ham.sieve
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_name = *
  imapsieve_mailbox3_before = file:/usr/local/lib/imapsieve/report-ham.sieve
  imapsieve_mailbox3_causes = APPEND
  imapsieve_mailbox3_name = INBOX
  last_login_dict = proxy::lastlogin
  last_login_key = # hidden, use -P to show it
  quota = dict:user::proxy::quota
  quota_rule = *:storage=2G
  quota_rule2 = 

Re: Dovecot sieve filters

[Gedalya]

On 9/20/21 03:15, j.emerlik wrote:
> "If address :is "from" "*" { .. } - I have same error.

Quote:

Error: sieve: report-ham: line 1: the envelope extension cannot be used in this 
context (needs access to message envelope)

It says "line 1", that's your "require" line. You need to remove "envelope" 
from the "require" line.

Re: Dovecot sieve filters

[Gedalya]

On 9/19/21 21:24, j.emerlik wrote:
>
> Error: sieve: report-ham: line 1: the envelope extension cannot be used in 
> this context (needs access to message envelope)
>
My guess would be that the envelope is not available because this is sieve 
running in IMAP, not during delivery.

If the From: header is also good, maybe try if address :is "from" "*" { .. }

Re: Storing Last Login Plugin value in SQL

[Gedalya]

On 9/14/21 05:44, dove...@ptld.com wrote:
>
> Thank you for the solution of using sql triggers. I was able to get it 
> working that way.
> I hope it doesn't add too much overhead as it feels like a band-aid and 
> duct-tape fix.

Yes, it's a workaround rather than being able to customize the SQL query. It's 
a bit of post-processing.

It will run on _any_ update on this table. If those are many, it may or may not 
be worthwhile to add a conditional, if perhaps evaluating the conditional would 
be cheaper than FROM_UNIXTIME().

In my case, I use a trigger to save a huge amount of overhead. Since I don't 
need to know that an account is "recently" used at a resolution higher than 15 
minutes, and the database is replicated, and nearly all database (+replication) 
IO is lastlogin, I'm able to cut it down tremendously when using row-based 
replication, and nothing is logged when the row wasn't actually modified. Of 
course this too could have been done in the original query itself.

On another note, IIRC the lastlogin timestamp is a 32-bit integer. We need 
64-bit timestamps, for winter is coming.

Re: Storing Last Login Plugin value in SQL

[Gedalya]

On 9/14/21 02:25, dove...@ptld.com wrote:
>
> The problem im having with the last-login plugin is the only option i can see 
> to use is a dict map{}. I can not create my own query for the plugin to 
> execute otherwise this would be way easier. Using the map{} method all you 
> can do it tell it the column name to update and the plugin/dovecot writes the 
> insert on dupe query automatically removing any kind of flexibility or 
> customization.
>
> Is there a way to use the plugin and write your own sql query to run instead 
> of using a dict map{}? 

Assuming you use MariaDB / MySQL, you create this trigger in the database. 
Assuming your int/bigint/varchar column is lastlogin and the table name is 
mailacct, the trigger will update the datetime `logindate` column whenever the 
table is updated, by whatever existing queries you have. This is your recourse 
when you can't get your queries to do the right thing in the first place.

Re: Storing Last Login Plugin value in SQL

[Gedalya]

On 9/14/21 02:12, dove...@ptld.com wrote:
>
> Anyone have any idea how to get the last-login plugin to update a date/time 
> column in sql?

I use this to throttle updates to once in 900 seconds:

create trigger tg1 before update on mailacct for each row if new.lastlogin < 
(old.lastlogin + 900) then set new.lastlogin = old.lastlogin; end if;

You can try:

create trigger tg1 before update on mailacct for each row set new.logindate = 
FROM_UNIXTIME(new.lastlogin);

Re: What kind of search response time are you setting with solr full text search?

[Gedalya]

On 8/25/21 9:19 AM, Steve Dondley wrote:
> I did some experimenting. I noticed that if the word I'm searching on is 
> fairly rare, results will pop up quickly, like in around 3 to 5 seconds. 
> Words that don't exist at all in any email returns nothing almost instantly.
>
> But words that appear in several hundred emails are the ones that are take a 
> much longer time. 

Can this be reduced to: getting more search results takes longer?

Re: FW: imapsieve rules not matching at all?

[Gedalya]

On 3/20/21 7:37 AM, dove...@steve.wattlink.net wrote:
>
> plugin {
>
>   imapsieve_mailbox1_before = 
> file:/usr/local/etc/dovecot/sieve/report-spam.sieve
>
>   imapsieve_mailbox1_causes = COPY APPEND
>
>   imapsieve_mailbox1_name = Spam
>
>   imapsieve_mailbox2_before = 
> file:/usr/local/etc/dovecot/sieve/report-ham.sieve
>
>   imapsieve_mailbox2_causes = COPY
>
>   imapsieve_mailbox2_from = Spam
>
>   imapsieve_mailbox2_name = *
>
> }
>
> - - - ->8 - - - -
>
>  
>
> I see that the static rule ought to have matched,
>
no!
>
>  
>
> - - - - 8<- - - -
>
> Mar 19 16:21:48 mhv3 dovecot[47532]: imap(steve)<47541>: 
> Debug: imapsieve: mailbox INBOX: APPEND event
>
> - - - ->8 - - - -

For INBOX (or * in your case) you only have COPY from Spam configured, not 
APPEND.

APPENDing to Spam should trigger the relevant script though.

If you want to enable ham training by uploading a message to INBOX you could 
add a third rule mentioning INBOX by name with APPEND as cause.

Re: FW: imapsieve rules not matching at all?

[Gedalya]

On 3/20/21 10:54 AM, Steve Watt wrote:
> I thought I had enabled that – check out the doveconf -n listing.  Did I miss 
> something?

IMAP METADATA for user-defined imapsieve scripts would be useful to you if you 
have clients that support that. If you know of any, please do share.

> Mar 19 16:21:48 mhv3 dovecot[47532]: imap(steve)<47541>: 
> Debug: imapsieve: mailbox INBOX: Mailbox attribute /shared/imapsieve/script 
> not found
>
> Mar 19 16:21:48 mhv3 dovecot[47532]: imap(steve)<47541>: 
> Debug: imapsieve: mailbox INBOX: Server attribute /shared/imapsieve/script 
> not found

This is saying that imapsieve scripts are not present in your defined 
mail_attribute_dict.

If you're not going to use that, you might as well disable it. However, I 
looked at the code and this is indeed not an error and it's not causing the 
imapsieve processing to stop as it would without METADATA enabled.

Re: FW: imapsieve rules not matching at all?

[Gedalya]

On 3/20/21 7:37 AM, dove...@steve.wattlink.net wrote:
>
> Greetings!
>
>  
>
> I feel like this has been beaten to death, but my searches on the web (and 
> about 10 hours spent over the last two days) haven’t revealed what’s going on.
>
>  
>
> Basically, it’s the usual “I’d like to auto-learn spam/ham based on moves 
> to/from a folder” problem.  But in my debugging, I don’t see any evidence 
> that the static rules are matching, so the scripts aren’t running, which 
> makes me think I’m missing something obvious.
>
>  
>

>  
>
> plugin {
>
>   imapsieve_url = sieve://127.0.0.1:4190
>
> }
>
> Mar 19 16:21:48 mhv3 dovecot[47532]: imap(steve)<47541>: 
> Debug: imapsieve: mailbox INBOX: Mailbox attribute /shared/imapsieve/script 
> not found
>
> Mar 19 16:21:48 mhv3 dovecot[47532]: imap(steve)<47541>: 
> Debug: imapsieve: mailbox INBOX: Server attribute /shared/imapsieve/script 
> not found

Try to fix or remove that.

https://www.mail-archive.com/dovecot@dovecot.org/msg82002.html

Re: Why Last-login?

[Gedalya]

On 3/4/21 3:21 AM, @lbutlr wrote:
> On 03 Mar 2021, at 05:38, Aki Tuomi  wrote:
>> These days you can also replace last-login with mail-lua script, which can 
>> do lot more than just try to set a dict. But last-login rather useful 
>> information when you are debugging, or removing dormant accounts. And other 
>> customer support incidents.
> Sure, being able to check a last login, approximately, is obviously useful. 
> Bu clogging it for every login

I do use last-login and I do agree that incrementing the timestamp when the 
existing value isn't too old is not very useful.

I have several deployments where everything is stored in and consumed from 
MySQL, so deploying redis just for this seems too much. The database is 
replicated. We end up seeing most of the replication traffic (network and disk 
IO) coming from last-login. Using specifically binlog_format = ROW, I can 
mitigate this with a trigger saying 'IF NEW.lastlogin < (OLD.lastlogin + 900) 
THEN SET NEW.lastlogin = OLD.lastlogin' and I end up having an unchanged row, 
so nothing goes to the binlog. Especially with pop3 users (some people do still 
do that) this can be a huge reduction in traffic.

It would perhaps be a nice feature if the last-login plugin could first fetch 
from the dict and do this comparison on its own.

Re: Getting panic in http-client-request.c: line 1240 during indexing on Ubuntu 20.04

[Gedalya]

On 2/9/21 4:49 AM, deano-dove...@areyes.com wrote:
> Unfortunately they don't make the source repos (deb-src 
> http://repo.dovecot.org/.) available,

They do however provide the .dsc file, so you can use dget (from the devscripts 
package)

e.g.

mkdir dovecot-source; cd dovecot-source
dget -u 
https://repo.dovecot.org/ce-2.3-latest/debian/buster/pool/main/2.3.13-2_ce/dovecot_2.3.13-2%2Bdebian10.dsc

That will do the same thing as apt-get source ...
(you need -u because the .dsc file does not contain a signature)

The directories are browsable at https://repo.dovecot.org/ce-2.3-latest/ so you 
can look for the right file per distro/version.

Re: Getting panic in http-client-request.c: line 1240 during indexing on Ubuntu 20.04

[Gedalya]

On 2/9/21 2:29 AM, John Fawcett wrote:
>>
>> Do we have when (or even if) that patch will make it into the main ?  I 
>> would really rather prefer pulling from repo ...
>>
> +1 from me.
>
> I'd like to see this patch (or something equivalent go in). Without this Tika 
> is unusable for me.
>
+1

I too had to re-apply Jeff Sipek's patch on top of 2.3.13, after 2.3.11. Now 
that 2.3.14 is on the way, it would be really nice if a fix could be included.

Re: dovecot quota-warning detection mail

[Gedalya]

Let me just add, of course you should play around with some test entries.
You don't want problems with dovecot finding the home directory, users suddenly 
seeing an empty mailbox, or LMTP delivering to the wrong place.
Just in case this isn't obvious :-)

On 10/29/20 2:08 PM, Gedalya wrote:
> Very good.
>
> See https://doc.dovecot.org/configuration_manual/authentication/passwd_file/
>
> You can add the "user" field as an "extra field"
>
> In users.auth, just add in the end "user=-...@ddd.example.com" to match 
> the respective entry in /etc/dovecot/users
>
> Good luck!
>
>
> On 10/29/20 2:02 PM, 森川 孝司 wrote:
>> OK. "passdb/userdb" Setting part
>>
>> $ dovecot -n (Excerpt from change)
>> 
>> -
>> passdb {
>>   args = scheme=CRYPT username_format=%u /etc/dovecot/users.auth
>>   driver = passwd-file
>> }
>>
>> userdb {
>>   args = username_format=%u /etc/dovecot/users.auth
>>   driver = passwd-file
>> }
>> protocol lmtp {
>>   info_log_path = /var/log/lmtplog
>>   mail_plugins = " quota quota sieve"
>>   userdb {
>> args = username_format=%u /etc/dovecot/users
>> driver = passwd-file
>> name =
>>   }
>> }
>> 
>> -
>>
>> cat /etc/dovecot/users.auth (Excerpt from change)
>> 
>> -
>> root:*/root::
>> :{CRAM-MD5}b09a26aedaddd0e66901eb4bc146b81930aac8be0dac96d1c83bb652fd4f7
>> 451/var/home/xxx/::
>> -ccc-ddd:{CRAM-MD5}b09a15aedaddd0e55901eb4bc146b81930aac8be0dac96d1c83bb
>> 652fd4f7451/home/vhosts/ddd/-ccc-ddd::
>> -fff-ggg:{CRAM-MD5}f4c336c68f063d1bbc2a1e32ae32bc9c978d0d2565eae42b4485d
>> 50370d157cd/home/vhosts/ggg/-fff-ggg::
>> -iii-jjj:{CRAM-MD5}78b337b326d57d564454d8019ed22b5d5cd181437aff77988e2c3
>> a12ec2d8490/home/vhosts/jjj/-iii-jjj::
>>   :
>>   :
>> 
>> -
>>
>> cat /etc/dovecot/users (Excerpt from change)
>> 
>> -
>> root:/root::
>> :/var/home/xxx/::
>> -...@ddd.example.com:::::/home/vhosts/ddd/-ccc-ddd::
>> -...@ggg.example.net:/home/vhosts/ggg/-fff-ggg::
>> -...@jjj.example.co.jp:/home/vhosts/jjj/-iii-jjj::
>>   :
>>   :
>> 
>> -
>>
>> -Original Message-
>> From: dovecot [mailto:dovecot-boun...@dovecot.org] On Behalf Of Gedalya
>> Sent: Thursday, October 29, 2020 2:27 PM
>> To: dovecot@dovecot.org
>> Subject: Re: dovecot quota-warning detection mail
>>
>> Perhaps if you share some information about your passdb / userdb
>> authentication setup, I or others might be able to help further.
>>
>>
>> On 10/29/20 12:51 PM, 森川 孝司 wrote:
>>> Gedalya-san
>>>
>>> Thank you for the information.
>>>
>>> It seems to be difficult...
>>>
>>> morikawa
>>> -Original Message-
>>> From: dovecot [mailto:dovecot-boun...@dovecot.org] On Behalf Of 
>>> Gedalya
>>> Sent: Thursday, October 29, 2020 1:17 PM
>>> To: dovecot@dovecot.org
>>> Subject: Re: dovecot quota-warning detection mail
>>>
>>> Aha. Then it's not a straightforward case of just adding the domain 
>>> name to the same username, you need to transform the username too.
>>> Dovecot's userdb / authdb allows you to return a "user" field, which 
>>> sets a new username for dovecot to use.
>>> Depending on what you use as your authentication backend, you may be 
>>> able to do the transformation at that layer.
>>>
>>> https://doc.dovecot.org/configuration_manual/authentication/user_extra
>>> _field
>>> /
>>>
>>> On 10/29/20 12:06 PM, 森川 孝司 wrote:
>>>> Gedalya-san
>>>>
>>>> You are currently logged in without a domain name.
>>>>
>>>> Currently, "abc-xyz-unyo-sekkei" users have been converted to 
>>>> "abc-xyz-u...@example.co.jp".
>>>> (There is no "sekkei" in the address.)
>>>>
>>>> Or just add "@example.co.jp"?
>>>> When it comes to "abc-xyz-unyo-sek...@example.co.jp"
>>>> I can't send a mail.
>>>>
>>>> Thank you.
>>>>
>>>> morikawa

Re: dovecot quota-warning detection mail

[Gedalya]

Very good.

See https://doc.dovecot.org/configuration_manual/authentication/passwd_file/

You can add the "user" field as an "extra field"

In users.auth, just add in the end "user=-...@ddd.example.com" to match the 
respective entry in /etc/dovecot/users

Good luck!


On 10/29/20 2:02 PM, 森川 孝司 wrote:
> OK. "passdb/userdb" Setting part
>
> $ dovecot -n (Excerpt from change)
> 
> -
> passdb {
>   args = scheme=CRYPT username_format=%u /etc/dovecot/users.auth
>   driver = passwd-file
> }
>
> userdb {
>   args = username_format=%u /etc/dovecot/users.auth
>   driver = passwd-file
> }
> protocol lmtp {
>   info_log_path = /var/log/lmtplog
>   mail_plugins = " quota quota sieve"
>   userdb {
> args = username_format=%u /etc/dovecot/users
> driver = passwd-file
> name =
>   }
> }
> 
> -
>
> cat /etc/dovecot/users.auth (Excerpt from change)
> 
> -
> root:*/root::
> :{CRAM-MD5}b09a26aedaddd0e66901eb4bc146b81930aac8be0dac96d1c83bb652fd4f7
> 451/var/home/xxx/::
> -ccc-ddd:{CRAM-MD5}b09a15aedaddd0e55901eb4bc146b81930aac8be0dac96d1c83bb
> 652fd4f7451/home/vhosts/ddd/-ccc-ddd::
> -fff-ggg:{CRAM-MD5}f4c336c68f063d1bbc2a1e32ae32bc9c978d0d2565eae42b4485d
> 50370d157cd/home/vhosts/ggg/-fff-ggg::
> -iii-jjj:{CRAM-MD5}78b337b326d57d564454d8019ed22b5d5cd181437aff77988e2c3
> a12ec2d8490/home/vhosts/jjj/-iii-jjj::
>   :
>   :
> 
> -
>
> cat /etc/dovecot/users (Excerpt from change)
> 
> -
> root:/root::
> :/var/home/xxx/::
> -...@ddd.example.com:/home/vhosts/ddd/-ccc-ddd::
> -...@ggg.example.net:/home/vhosts/ggg/-fff-ggg::
> -...@jjj.example.co.jp:/home/vhosts/jjj/-iii-jjj::
>   :
>   :
> 
> -
>
> -Original Message-
> From: dovecot [mailto:dovecot-boun...@dovecot.org] On Behalf Of Gedalya
> Sent: Thursday, October 29, 2020 2:27 PM
> To: dovecot@dovecot.org
> Subject: Re: dovecot quota-warning detection mail
>
> Perhaps if you share some information about your passdb / userdb
> authentication setup, I or others might be able to help further.
>
>
> On 10/29/20 12:51 PM, 森川 孝司 wrote:
>> Gedalya-san
>>
>> Thank you for the information.
>>
>> It seems to be difficult...
>>
>> morikawa
>> -Original Message-
>> From: dovecot [mailto:dovecot-boun...@dovecot.org] On Behalf Of 
>> Gedalya
>> Sent: Thursday, October 29, 2020 1:17 PM
>> To: dovecot@dovecot.org
>> Subject: Re: dovecot quota-warning detection mail
>>
>> Aha. Then it's not a straightforward case of just adding the domain 
>> name to the same username, you need to transform the username too.
>> Dovecot's userdb / authdb allows you to return a "user" field, which 
>> sets a new username for dovecot to use.
>> Depending on what you use as your authentication backend, you may be 
>> able to do the transformation at that layer.
>>
>> https://doc.dovecot.org/configuration_manual/authentication/user_extra
>> _field
>> /
>>
>> On 10/29/20 12:06 PM, 森川 孝司 wrote:
>>> Gedalya-san
>>>
>>> You are currently logged in without a domain name.
>>>
>>> Currently, "abc-xyz-unyo-sekkei" users have been converted to 
>>> "abc-xyz-u...@example.co.jp".
>>> (There is no "sekkei" in the address.)
>>>
>>> Or just add "@example.co.jp"?
>>> When it comes to "abc-xyz-unyo-sek...@example.co.jp"
>>> I can't send a mail.
>>>
>>> Thank you.
>>>
>>> morikawa
>

Re: dovecot quota-warning detection mail

[Gedalya]

Perhaps if you share some information about your passdb / userdb authentication 
setup, I or others might be able to help further.


On 10/29/20 12:51 PM, 森川 孝司 wrote:
> Gedalya-san
>
> Thank you for the information.
>
> It seems to be difficult...
>
> morikawa
> -Original Message-
> From: dovecot [mailto:dovecot-boun...@dovecot.org] On Behalf Of Gedalya
> Sent: Thursday, October 29, 2020 1:17 PM
> To: dovecot@dovecot.org
> Subject: Re: dovecot quota-warning detection mail
>
> Aha. Then it's not a straightforward case of just adding the domain name to
> the same username, you need to transform the username too.
> Dovecot's userdb / authdb allows you to return a "user" field, which sets a
> new username for dovecot to use.
> Depending on what you use as your authentication backend, you may be able to
> do the transformation at that layer.
>
> https://doc.dovecot.org/configuration_manual/authentication/user_extra_field
> /
>
> On 10/29/20 12:06 PM, 森川 孝司 wrote:
>> Gedalya-san
>>
>> You are currently logged in without a domain name.
>>
>> Currently, "abc-xyz-unyo-sekkei" users have been converted to 
>> "abc-xyz-u...@example.co.jp".
>> (There is no "sekkei" in the address.)
>>
>> Or just add "@example.co.jp"?
>> When it comes to "abc-xyz-unyo-sek...@example.co.jp"
>> I can't send a mail.
>>
>> Thank you.
>>
>> morikawa

Re: dovecot quota-warning detection mail

[Gedalya]

Aha. Then it's not a straightforward case of just adding the domain name to the 
same username, you need to transform the username too.
Dovecot's userdb / authdb allows you to return a "user" field, which sets a new 
username for dovecot to use.
Depending on what you use as your authentication backend, you may be able to do 
the transformation at that layer.

https://doc.dovecot.org/configuration_manual/authentication/user_extra_field/

On 10/29/20 12:06 PM, 森川 孝司 wrote:
> Gedalya-san
>
> You are currently logged in without a domain name.
>
> Currently, "abc-xyz-unyo-sekkei" users have been converted to
> "abc-xyz-u...@example.co.jp".
> (There is no "sekkei" in the address.)
>
> Or just add "@example.co.jp"?
> When it comes to "abc-xyz-unyo-sek...@example.co.jp"
> I can't send a mail.
>
> Thank you.
>
> morikawa

Re: dovecot quota-warning detection mail

[Gedalya]

It should only affect users who authenticate with a username only, without a 
domain.
The only effect is to add the domain name to the username.
You could perhaps test, by logging in as just "user" and then as 
"u...@example.co.jp" and make sure everything behaves the same.
If everything behaves the same, then setting auth_default_realm should not do 
any harm.
In other words, the question is: does any functionality actually depend on 
having a username without a domain.

On 10/29/20 8:18 AM, 森川 孝司 wrote:
> Gedalya-san
>
> I have a question.
> Currently, there are thousands of users. (In multi-domain)
> The setting of "auth_default_realm = example.co.jp" is
> Is it possible to set without affecting the current user?
>
> Thank you.

Re: dovecot quota-warning detection mail

[Gedalya]

On 10/28/20 12:19 PM, 森川 孝司 wrote:
> "
> "Recipient address rejected: User unknown in local recipient table"

If abc-xyz-unyo-sekkei is supposed to be abc-xyz-unyo-sek...@example.co.jp then 
you could try to set in dovecot configuration:

auth_default_realm = example.co.jp

Then %u will contain the domain part too.

Otherwise, you could try to configure postfix to qualify unqualified addresses 
with the appropriate domain.

Finally, you could just prohibit users from authenticating with an unqualified 
username (without a domain).

Re: imapsieve: setting imapsieve_url disables admin scripts

[Gedalya]

On 10/27/20 7:52 PM, Stephan Bosch wrote:
>
>
> On 27/10/2020 11:32, Gedalya wrote:
>> Hello,
>>
>> The documentation says imapsieve_url "has no effect on the 
>> administrator-controlled Sieve scripts". However, when setting this item, I 
>> get lines such as:
>>
>> Error: imapsieve: mailbox INBOX: Failed to read /shared/imapsieve/script 
>> mailbox attribute: Mailbox attributes not enabled
>>
>> and that's it. imapsieve_mailboxXXX_* settings are completely ignored. 
>> Unsetting imapsieve_url makes it all work again.
>
> https://doc.dovecot.org/configuration_manual/imap_metadata/
>
> METADATA support is needed for IMAPSieve with user Sieve scripts.

OK, I see, so if I want user scripts to actually work I'd have to enable that.

Why does a broken user script configuration have to break admin scripts?

imapsieve: setting imapsieve_url disables admin scripts

[Gedalya]

Hello,

The documentation says imapsieve_url "has no effect on the 
administrator-controlled Sieve scripts". However, when setting this item, I get 
lines such as:

Error: imapsieve: mailbox INBOX: Failed to read /shared/imapsieve/script 
mailbox attribute: Mailbox attributes not enabled

and that's it. imapsieve_mailboxXXX_* settings are completely ignored. 
Unsetting imapsieve_url makes it all work again.

# 2.3.11.3 (502c39af9): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.11 (6c69c917)
# OS: Linux 4.19.0-5-amd64 x86_64 Debian bullseye/sid xfs
# Hostname: --
auth_master_user_separator = *
auth_mechanisms = plain login
auth_verbose = yes
imapc_features = rfc822.size fetch-headers
imapc_host = imap.gmail.com
imapc_port = 993
imapc_ssl = imaps
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_gid = vmail
mail_home = /srv/mail/domains/%d/%n
mail_location = mdbox:/srv/mail/domains/%d/%n/mdbox
mail_plugins = quota fts fts_solr
mail_prefetch_count = 20
mail_privileged_group = mail
mail_uid = vmail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date index ihave duplicate 
mime foreverypart extracttext imapsieve vnd.dovecot.imapsieve
mdbox_preallocate_space = yes
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
    auto = subscribe
    special_use = \Drafts
  }
  mailbox Junk {
    auto = subscribe
    autoexpunge = 30 days
    special_use = \Junk
  }
  mailbox Sent {
    auto = subscribe
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    special_use = \Sent
  }
  mailbox Trash {
    auto = subscribe
    autoexpunge = 30 days
    special_use = \Trash
  }
  prefix =
  separator = /
}
passdb {
  args = /etc/dovecot/master-users
  driver = passwd-file
  master = yes
  pass = yes
}
passdb {
  args = /etc/dovecot/dovecot-sql.conf.ext
  driver = sql
}
plugin {
  fts = solr
  fts_autoindex = yes
  fts_solr = url=http://127.0.0.1:8983/solr/dovecot/
  fts_tika = http://127.0.0.1:9998/tika/
  imapsieve_mailbox1_before = file:/usr/local/lib/imapsieve/report-spam.sieve
  imapsieve_mailbox1_causes = COPY
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox2_before = file:/usr/local/lib/imapsieve/report-ham.sieve
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_name = *
  imapsieve_mailbox3_before = file:/usr/local/lib/imapsieve/report-spam.sieve
  imapsieve_mailbox3_causes = COPY
  imapsieve_mailbox3_name = Junk2
  imapsieve_mailbox4_before = file:~/sieve/IMAP-Sent.sieve
  imapsieve_mailbox4_causes = APPEND COPY
  imapsieve_mailbox4_name = Sent
  quota = count:User quota:noenforcing
  quota_rule = *:storage=5120M
  quota_vsizes = yes
  sieve = file:~/sieve;active=~/.dovecot.sieve
  sieve_before = /etc/dovecot/sieve-global/fileinto-spam.sieve
  sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment
  sieve_pipe_bin_dir = /usr/local/lib/imapsieve
  sieve_plugins = sieve_imapsieve sieve_extprograms
}
pop3_fast_size_lookups = yes
pop3_no_flag_updates = yes
protocols = " imap lmtp sieve pop3"
quota_full_tempfail = yes
service auth-worker {
  user = $default_internal_user
}
service auth {
  unix_listener auth-client {
    group = Debian-exim
    mode = 0660
    user = Debian-exim
  }
  unix_listener auth-userdb {
    group = vmail
    mode = 0660
    user = vmail
  }
  user = $default_internal_user
}
service imap-login {
  inet_listener imap {
    port = 143
  }
  service_count = 0
}
service imap {
  vsz_limit = 512 M
}
service lmtp {
  inet_listener lmtp {
    address = ---
    port = 2525
  }
  unix_listener lmtp {
    group = Debian-exim
    mode = 0660
    user = root
  }
}
service managesieve-login {
  inet_listener sieve {
    port = 4190
  }
  service_count = 0
}
service pop3-login {
  inet_listener pop3 {
    port = 110
  }
  service_count = 0
}
ssl = required
ssl_cert = 

Re: Indexer error after upgrade to 2.3.11.3

[Gedalya]

On 8/19/20 11:37 PM, Josef 'Jeff' Sipek wrote:
> If you can try it, let us know how it went.

Hi,

Thanks. I had this problem and the patch helped.

This suddenly started on two different deployments, a few days apart, one was 
October 8 and the other October 12, upon delivery of apparently troublesome 
messages.

My error message, for reference, was:

doveadm(): Panic: file http-client-request.c: line 1232 
(http_client_request_send_more): assertion failed: (req->payload_input != NULL)
doveadm(): Error: Raw backtrace: 
/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x42) [0x7f2e37823a12] -> 
/usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7f2e37823b2e] -> 
/usr/lib/dovecot/libdovecot.so.0(+0xf5dfb) [0x7f2e3782cdfb] -> 
/usr/lib/dovecot/libdovecot.so.0(+0xf5e31) [0x7f2e3782ce31] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x5211e) [0x7f2e3778911e] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x49a77) [0x7f2e37780a77] -> 
/usr/lib/dovecot/libdovecot.so.0(http_client_connection_output+0xee) 
[0x7f2e377d5c1e] -> /usr/lib/dovecot/libdovecot.so.0(+0x11bb51) 
[0x7f2e37852b51] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) 
[0x7f2e37842e39] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x132) 
[0x7f2e3782] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) 
[0x7f2e37842ee0] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) 
[0x7f2e378430a0] -> /usr/lib/dovecot/libdovecot.so.0(+0x9a53d) [0x7f2e377d153d] 
->
/usr/lib/dovecot/libdovecot.so.0(http_client_request_send_payload+0x2e) 
[0x7f2e377d16ce] -> /usr/lib/dovecot/modules/lib20_fts_plugin.so(+0xf2ed) 
[0x7f2e36fcc2ed] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(fts_parser_more+0x25) 
[0x7f2e36fcb345] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(fts_build_mail+0x511) 
[0x7f2e36fc9571] -> /usr/lib/dovecot/modules/lib20_fts_plugin.so(+0x11f0b) 
[0x7f2e36fcef0b] -> 
/usr/lib/dovecot/libdovecot-storage.so.0(mail_precache+0x2e) [0x7f2e379403be] 
-> doveadm(+0x374df) [0x5616b155f4df] -> doveadm(+0x3190d) [0x5616b155990d] -> 
doveadm(+0x324f2) [0x5616b155a4f2] -> 
doveadm(doveadm_cmd_ver2_to_mail_cmd_wrapper+0x22d) [0x5616b155b36d] -> 
doveadm(doveadm_cmd_run_ver2+0x4c8) [0x5616b156b9f8] -> 
doveadm(doveadm_cmd_try_run_ver2+0x3a) [0x5616b156ba4a] -> doveadm(main+0x1d0) 
[0x5616b154a440] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) 
[0x7f2e373f8cca] -> doveadm(_start+0x2a) [0x5616b154a91a]

Re: Spam learning for rspamd

[Gedalya]

On 10/13/20 8:49 AM, Dan Egli wrote:
>
> I'm quite new to Dovecot, so forgive me if this is a simple question. I've 
> got rspamd running, and it's rewriting the subject of many messages as spam 
> even when they are not. I've moved things out of the spam folder, which I was 
> under the impression would teach rspamd since I've connected a sieve script 
> that is supposed to call rspamd's learning tool, but nothing is happening. 
> I'm really at a loss as to where to even begin searching for an answer, so 
> any help is appreciated!
>
> -- 
> Dan Egli
> On my Test server

At first we'd want to see your current configuration, sieve scripts etc.

Re:

[Gedalya]

On 3/9/20 1:32 PM, ?? wrote:
> hello
> ?0?2 ?0?2 ?0?2I have some error by LMTP:
> Mar 09 13:26:42 imap-hibernate(q...@a.com)<90154>: Error: 
> Failed to unhibernate client: net_connect_unix(/var/run/dovecot/imap-master) 
> failed: Permission denied
> Mar 09 13:26:42 lmtp(q...@a.com)<90263>: Info: 
> msgid=<77z2kkfmm1-7846bu3...@test.com>: saved mail to INBOX
>
> ll /var/run/dovecot/imap-master
> srw--- 1 root root 0 3?? ?0?2 9 13:05 /var/run/dovecot/imap-master
>
>
service imap {
?0?2 # Note that this change will allow any process running as
?0?2 # $default_internal_user (dovecot) to access mails as any other user.
?0?2 # This may be insecure in some installations, which is why this isn't
?0?2 # done by default.
?0?2 unix_listener imap-master {
?0?2?0?2?0?2 user = $default_internal_user?0?2?0?2?0?2?0?2 #<<
?0?2 }

}

Re: Dovecot - Upgrade Solr 7.7.2 to 8.4.1

[Gedalya]

On 2/5/20 5:55 PM, Francis Augusto Medeiros-Logeay wrote:
> I want to install fts-solr, but must tutorials are mentioning solr 7.7.0. Any 
> heads-up on what one must pay attention to when installing 8.4.0? Do I need 
> to update the version on the schemas, for example? 

I followed the instructions and used the schema for 7.7.0, for a new install of 
8.4.0 and everything went fine.

Re: Dovecot - Upgrade Solr 7.7.2 to 8.4.1

[Gedalya]

On 1/23/20 7:03 AM, Domenico Pastore wrote:
> So, with Dovecot is it possible to use Apache Solr 8.4? 
> High RAM usage is the only problem?

I'm using 8.4.0 and it works flawlessly.

Re: Question about verbose_proctitle

[Gedalya]

On 07/13/2018 08:45 AM, J Doe wrote:
> I’m aware that this is because the code does not state to specify “TLS” for 
> the dovecot/imap [u...@example.com 1.2.3.4 IDLE] line of output, but I’m 
> curious as to why that decision was made ?

TLS is done by the imap-login process. This process does all the actual talking 
to the client. The imap process blindly trusts whoever invoked it (imap-login), 
it doesn't authenticate the user either. Timo didn't want any crypto or 
authentication code, or to link against any such libraries in the imap process 
itself.

Your imap-login process does show TLS and this can be logged in the log file as 
well, see login_log_format_elements and the variables %c and %k

Re: maildir vs dbox?

[Gedalya]

On 04/20/2018 04:08 AM, David Mehler wrote:
> I am wondering if changing to dbox would be beneficial?

It can be faster when a user deletes or moves a large number of messages.
One reason why I migrated a few sites is that when reporting issues with 
maildir on this list, there seems to be lack of interest in fixing them. In 
that regard, it can be seen as a safer choice.

Re: multi-site SSL certificates

[Gedalya]

On 04/02/2018 03:17 PM, Jeff Abrahamson wrote:
> On Mon, Apr 02, 2018 at 02:34:34PM +0200, Gedalya wrote:
>> On 04/02/2018 02:25 PM, Jeff Abrahamson wrote:
>>> I see that the file
>>>
>>> .well-known/acme-challenge/IT7-YURAep4bniD9zYpKpdRUBQcgCRJ6FflmZzWQGNg
>>>
>>> is being created (and one other file, too) but that nginx reports that
>>> the _directory_
>>>
>>> .well-known/acme-challenge/IT7-YURAep4bniD9zYpKpdRUBQcgCRJ6FflmZzWQGNg
>>>
>>> doesn't exist.
>> You have a problem with your nginx config. It doesn't seem related to 
>> postfix et al.
>>
>> Really off-topic for this list but you could perhaps post your nginx config 
>> and logs.
> If this is more properly a certbot question, I should ask there.  I'd
> understood from the certbot docs that postfix had developed a
> postfix-specific certbot plugin, in which case this might have been
> the right venue to ask.  That I hadn't found that plugin was, to be
> fair, a bit suspicious to me, but it wouldn't be the first time I miss
> something in front of my nose.


You're using the webroot plugin for the challenge. This is as simple as 
dropping a file and letting nginx serve it as static content (maybe with 
try_files). The various certbot plugins for postfix and other apps are for 
automating the certificate installation and tweaking TLS configuration to match 
certain recommendations. That's not related to your issue here. You're looking 
at a challenge failure. You're saying that the file is there but nginx is 
failing to serve it, that should be easy to fix and once it fix the challenge 
will pass and your certificate will be issued. You can then install it, 
manually or otherwise.

Re: multi-site SSL certificates

[Gedalya]

On 04/02/2018 02:25 PM, Jeff Abrahamson wrote:
> I see that the file
>
> .well-known/acme-challenge/IT7-YURAep4bniD9zYpKpdRUBQcgCRJ6FflmZzWQGNg
>
> is being created (and one other file, too) but that nginx reports that
> the _directory_
>
> .well-known/acme-challenge/IT7-YURAep4bniD9zYpKpdRUBQcgCRJ6FflmZzWQGNg
>
> doesn't exist.

You have a problem with your nginx config. It doesn't seem related to postfix 
et al.

Really off-topic for this list but you could perhaps post your nginx config and 
logs.

Re: BUG: Unknown command in userdb socket: CPID?2625

[Gedalya]

On 03/26/2018 02:03 PM, Vladimir Tiukhtin wrote:
> Do you have any document describing "special" names? Thanks

It's documented here.

https://wiki2.dovecot.org/Services#auth

I have to agree that it's kind of confusing. Would be clearer if it had a e.g. 
type=userdb setting.

Re: Documentation Bug

[Gedalya]

On 02/13/2018 03:00 PM, Andrew Beck wrote:
> In https://wiki2.dovecot.org/Tools/Doveadm/Sync#section_arguments the 
> destination list 5 possible options for the destination
>
> but in the page on migration https://wiki2.dovecot.org/Migration/Dsync it 
> seems to use a sixth undocumented "imapc:" option for destination
>
> e.g.
>
> doveadm -o mail_fsync=never backup -R -u user@domain imapc:
>
>
> "imapc:" is also referenced on https://wiki2.dovecot.org/Migration/Gmail
>
> Is https://wiki2.dovecot.org/Tools/Doveadm/Sync#section_arguments missing 
> this option?
>
> Andrew
>

imapc falls under the first option, "location".

See:

https://wiki.dovecot.org/MailLocation

https://wiki.dovecot.org/MailboxFormat

Re: doveadm log reopen not works with 2.2.33

[Gedalya]

On 12/14/2017 03:18 PM, Alessio Cecchi wrote:
> Is this a know bug? 


https://www.dovecot.org/pipermail/dovecot/2017-November/109971.html

Re: Postlogin script

[Gedalya]

On 11/10/2017 11:03 PM, Joseph Tam wrote:
>
> The toughest situation (using script techniques) is for
> CIDR ranges just shy of a full octet boundary e.g. /25. 

Actually there is a great tool for that, grepcidr

$ echo 10.11.12.127 | grepcidr 10.11.12.0/25 && echo OK
10.11.12.127
OK
$ echo 10.11.12.128 | grepcidr 10.11.12.0/25 && echo OK
$

But in your case you really probably should use postgres for the userdb and 
just return everything from there in user fields / extra fields, and if the 
logic doesn't fit in a simple query you can put it in a stored procedure. That 
will likely be more efficient.

Re: Postlogin script

[Gedalya]

A bit clunky but perhaps you could find another command.

https://packages.debian.org/stretch/netmask

$ IP=172.11.0.28
$ if [ "$(netmask -n $IP/24)" == " 172.11.0.0/24" ]; then echo OK; fi
OK
$ IP=172.12.0.11
$ if [ "$(netmask -n $IP/24)" == " 172.11.0.0/24" ]; then echo OK; fi
$

Range:

https://packages.debian.org/stretch/prips

$ IP=172.11.0.28
$ if prips 172.11.0.11 172.11.0.55 | grep $IP; then echo OK; fi
172.11.0.28
OK
$ IP=172.11.0.66
$ if prips 172.11.0.11 172.11.0.55 | grep $IP; then echo OK; fi


On 11/09/2017 11:12 AM, j.emerlik wrote:
> Hi,
> I would like to prepare postlogin a script that allow imap connection to
> roundcube for all but restrict imap access for selected users.
>
> My question is that:
>
> Is possible in condition IF use IP addresses as range or with mask (because
> I've more than one web servers) ?
>
> My script:
>
> #!/bin/sh
> if [ "$IP" = "172.11.0.28" ] ; then
>   printf "* [ALERT] Access allowed from that IP\r\n"
>   exec "$@"
> fi
>
> CHECK_USER=`PGPASSWORD="somepass" /usr/local/pg950/bin/psql -q -t -U
> someuser -d maildb -c "select imap_allowed from __users where name =
> '$USER' LIMIT 1"`
>
> if [ $CHECK_USER == "f" ] ; then
> exit 0
> fi
>
> if [ $CHECK_USER == "t" ] ; then
> exec "$@"
> fi
>
> Regards,
> Jack

Re: Post-login scripting

[Gedalya]

Aha. Looks pretty cool, and it's really nice that it supports HTTP.
On the other hand if I'm rate limiting the number of messages sent = number of 
times a client said RCPT TO, I guess it still has to be a postfix policy server?
Anyway, thanks for pointing this out, I'm sure I'll use it :-)


On 10/21/2017 02:16 PM, Aki Tuomi wrote:
> Dovecot auth supports auth_policy_server (v2.2.27+, 
> https://wiki.dovecot.org/Authentication/Policy), which you could use for 
> this. There is also https://github.com/PowerDNS/weakforced you can use as 
> policy server, which can also do ratelimiting and such. It also integrates 
> with postfix.
>
> Aki
>
>> On October 20, 2017 at 6:12 PM Gedalya <geda...@gedalya.net> wrote:
>>
>>
>> No, it's entirely my own.
>> If all you want to do is write client IP addresses to a database then your 
>> script will probably fit in 20 lines of code or so.
>>
>>
>> On 10/20/2017 05:04 PM, j.emerlik wrote:
>>> Which one policy server are you using ?
>>> Someone from that list : http://www.postfix.org/addon.html
>>>
>>> 2017-10-20 16:53 GMT+02:00 Gedalya <geda...@gedalya.net>:
>>>
>>>> On 10/20/2017 04:50 PM, j.emerlik wrote:
>>>>
>>>> I understand that Dovecot SASL does not support the Post-Login scripts.
>>>> Yea, perhaps not. The concept it follows for POP3/IMAP is a wrapper for
>>>> the executable launched to perform the actual service, and there is no such
>>>> service when dovecot is only a SASL auth server for an external program.
>>>>
>>>> On the other hand a postfix policy server can let you record a lot of
>>>> detail about SMTP activity: messages sent, sender/recipient addresses, and
>>>> client addresses of course.
>>>>
>>>> I might be able to help with putting such a script together, time
>>>> permitting :-)
>>>>

Re: Post-login scripting

[Gedalya]

No, it's entirely my own.
If all you want to do is write client IP addresses to a database then your 
script will probably fit in 20 lines of code or so.


On 10/20/2017 05:04 PM, j.emerlik wrote:
> Which one policy server are you using ?
> Someone from that list : http://www.postfix.org/addon.html
>
> 2017-10-20 16:53 GMT+02:00 Gedalya <geda...@gedalya.net>:
>
>> On 10/20/2017 04:50 PM, j.emerlik wrote:
>>
>> I understand that Dovecot SASL does not support the Post-Login scripts.
>> Yea, perhaps not. The concept it follows for POP3/IMAP is a wrapper for
>> the executable launched to perform the actual service, and there is no such
>> service when dovecot is only a SASL auth server for an external program.
>>
>> On the other hand a postfix policy server can let you record a lot of
>> detail about SMTP activity: messages sent, sender/recipient addresses, and
>> client addresses of course.
>>
>> I might be able to help with putting such a script together, time
>> permitting :-)
>>

Re: Post-login scripting

[Gedalya]

On 10/20/2017 04:50 PM, j.emerlik wrote:


I understand that Dovecot SASL does not support the Post-Login scripts.
Yea, perhaps not. The concept it follows for POP3/IMAP is a wrapper for 
the executable launched to perform the actual service, and there is no 
such service when dovecot is only a SASL auth server for an external 
program.


On the other hand a postfix policy server can let you record a lot of 
detail about SMTP activity: messages sent, sender/recipient addresses, 
and client addresses of course.


I might be able to help with putting such a script together, time 
permitting :-)

Re: Post-login scripting

[Gedalya]

I use an access policy server which mostly does rate-limiting and also 
writes to a database.

It's written in perl.
If all you want to do is to write some records for every connection then 
the script would be rather simple.
You just need to put "check_policy_service unix:" in the right 
place, presumably in smtpd_client_restrictions, I guess if you put it 
before permit_sasl_authenticated it would still have the auth details, 
due to delayed evaluation.

Re: Post-login scripting

[Gedalya]

On 10/20/2017 03:46 PM, j.emerlik wrote:
> Hi ,
> I would like to save every authentication IP addresses to database, for
> IMAP and POP3 everything working correct but I don't know how to configure
> Post-login script for SMTP AUTH.
>
> Can you help me ?
>
> Regards,
> Jack

It would probably be possible to do this at the MTA.
I do it in postfix + mysql.
What is your setup like?

Re: pop 110/995, imap 143/993 ?

[Gedalya]

Bottom line, a server operator's view can be a lot narrower than this, 
especially in the scenario where you serve the general public and do not 
control the clients.
There is definitely no reason why you wouldn't want to serve ports 993/995. The 
MITM thing can be used to argue against serving ports 110/143, and some servers 
indeed do not offer those.
But you'll always deal with people who would insist 110/143 is the "right" 
away. It's nice to provide more than option and you can expect many modern 
clients to default to requiring STARTTLS, and do proper certificate validation. 
On my own server I provide only 143, and I control all the clients. So you know 
my taste on the matter :)

Re: pop 110/995, imap 143/993 ?

[Gedalya]

On 08/21/2017 06:04 PM, Sebastian Arcus wrote:
>
> On 21/08/17 10:37, Gedalya wrote:
>> On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote:
>>> is there a 'preferred way'?  should I tell users to use 143 over 993 ? or
>>> 993 over 143? or?
>> There is no concrete answer. There are various opinions and feelings about 
>> this.
>> The opinion againt 993/995 is that these are not standard ports, 
>
> Out of curiosity, is there a source for this? It's the first time I hear that 
> 993/995 are not standard ports - and searching on the Internet, I can't find 
> any evidence to back it up? Also, pretty much all email software has been 
> using them for the past 20 years or so. It seems like a curiously high rate 
> of adoption for a non-standard :-)

What kind of evidence would support a negative? I don't understand.

Evidence could demonstrate that something is indeed a standard.
"Standard" and common practice are not the same thing. A "Standrd" is a 
document that describes what practice ought to look like.
C has a (series of) standard(s), Perl 5 is not exactly standardized. It's just 
implemented and documented.

Either way, at this point these ports are indeed listed here:

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

So perhaps it can be said that those still arguing against it on the basis of 
it being "non-standrd" are still arguing against officially assigning these 
port numbers, because the old ports are perfectly good, even after the 
assignment has already been listed by IANA.

Re: pop 110/995, imap 143/993 ?

[Gedalya]

On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote:
> is there a 'preferred way'?  should I tell users to use 143 over 993 ? or
> 993 over 143? or?
There is no concrete answer. There are various opinions and feelings about this.
The opinion againt 993/995 is that these are not standard ports, and there is no
need to allocate new ports for the secure version of each protocol since we can
use STARTTLS.

The problem with 110/143 is that security depends on settings on both ends:
The client must be configured to negotiate STARTTLS as mandatory, and refuse
to talk to the server when that doesn't work.
The server must also refuse to talk to clients without STARTTLS.
Since some mail clients support "opportunistic" STARTTLS, that is, use port 143
and use STARTTLS *if / when* available, some people feel there are too many
subtleties involved, and ports 993/995 just make all this go away.

Requiring STARTTLS on the server side doesn't prevent a man-in-the-middle
attack. The client must be configured to insist on negotiating STARTTLS with a
server with a verified certificate.

> my current understanding is that some (MS?) clients might not support
> StartTLS/143 ? so best to offer both ?
Their newest clients do support STARTTLS. I don't remember exactly but maybe
Outlook 2003 or so didn't support it.
> I think? some public WiFi block 993/995 but allow 143/110, hence, another
> advantage for using 143/110

Never heard of this either.

Re: Ubuntu 16.04 dovecot-core requires deprecated ntpdate

[Gedalya]

On 08/17/2017 09:57 PM, Michael Fox wrote:
> I'm building a new Ubuntu 16.04 machine, including Dovecot.
>
> When I select the dovecot-core package in Synaptic, it also wants to install
> ntpdate.
Install packages at the command line using apt-get. It lets you better see and 
understand what's going on.
dovecot-core /recommends/ ntpdate. This means you can install with apt-get 
--no-install-recommends and the Recommends will be shown but not installed, 
leaving the judgement to you.

> Now the dovecot-core package evidently requires ntpdate.  I can't imagine
> why this dependency would exist.  And I presume this dependency will prevent
> me from removing ntpdate after I install dovecot-core.
In apt-based systems, removing a package triggers removal of any depending 
packages, but not "recommending" packages.
Just try 'apt-get remove ntpdate'. It will prompt you, and quite likely it will 
say it is about to remove ntpdate and no other package.
It will do what it says it is going to do, and no more.

> Is the Debian package maintainer on the list?
He does read the list. In either case dovecot-core in ubuntu 17.04 and in 
Debian stretch and jessie don't have this Recommends.
> I don't know what to do.  Any suggestions?  
Remove ntpdate, you'll be fine.

For the record, the equivalent of ntpdate in terms of a non-daemon NTP client 
for ad-hoc use is the new sntp package in artful(U)/buster(deb)

Re: v2.2.28 released

[Gedalya]

On 03/07/2017 02:41 PM, Robert L Mathews wrote:
> As a result, I
> end up using what seems to be a mostly stable version, plus "extra
> patches I grabbed from reading the mailing list".

Pretty sure that's what the dovecot enterprise repo is.

Re: Problem with Let's Encrypt Certificate

[Gedalya]

On 02/19/2017 08:39 PM, Michael A. Peters wrote:
> Every time I change the private key -
>
> A) I have to make a TLSA record for the new key 

You're actually expected to pin the CA in your TLSA record, not your own key.

https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

http://www.internetsociety.org/deploy360/blog/2016/01/lets-encrypt-certificates-for-mail-servers-and-dane-part-1-of-2/

https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/

I had the privilege of being auto-yelled at by Viktor Dukhovni over forgetting 
to adjust my TLSA after changing certificates for SMTP. I would however prefer 
to automate the process of pushing new TLSA records, waiting out twice the TTL 
and then pushing the certificate. Going through this every time would ensure I 
have valid records every time, without having to worry about the CA key 
changing. This is on my to-do list, for SMTP, XMPP, IMAP etc.

Re: Is there a way to override Sieve's "not sending notification for auto-submitted message" behavior?

[Gedalya]

On 05/05/2016 01:33 PM, Gedalya wrote:
> you just might be able to set that up to test for the right conditions *when* 
> to do this, and then proceed to remove the header

Maybe using PCRE negative lookaheads

/^Subject: (?!google-calendar-notification)/DUNNO
/^From: (?!google)/DUNNO
/^Auto-Submitted:/IGNORE

maybe something vaguely like this?? didn't test this anywhere outside of my 
message compose window

Re: Is there a way to override Sieve's "not sending notification for auto-submitted message" behavior?

[Gedalya]

On 05/05/2016 01:02 PM, deoren wrote:
> On 5/5/2016 10:42 AM, Gedalya wrote:
>> On 05/05/2016 01:00 AM, deoren wrote:
>>> Goal:
>>>
>>> 1) Setup a Google Calendar entry for a biweekly task
>>> 2) Configure the email notification schedule
>>> 3) When the email notification from Google arrives have Sieve send a
>>> notification to an alias I have setup for my cell provider's email to
>>> text messaging gateway
>>> 4) Receive text message
>>>
>>> ...
>>>
>> If you can't do it with dovecot / pigeonhole then consider doing something 
>> in the MTA like removing the Auto-Submitted header before delivery
>
> Thank you for taking the time to read my email and offer suggestions!
>
> I was starting to think the same thing. I've been thinking about using a 
> local alias to pipe to a script to handle generating my own notifications for 
> Google Calendar emails. I also thought about creating some sort of 
> filter/milter to just strip out the header for those emails before letting 
> the Sieve filter handle the rest, but I've not yet had a chance to research 
> just how to go about that.
>
>> or of course you can just send your notification out of there.
>
> Like I mentioned above or is there a better way to go about it?
>
>> Which MTA are you using?
>>
>
> I'm using Postfix 2.11.x + Dovecot 2.2.x to handle our mail.
>
> Thanks again for your help!

So yea if you're on postfix I don't know of better/other terms to think of this 
in.
In exim, you could send out a notification and/or strip/add/modify headers 
without any external script or writing any "code" per se, just within exim's 
config file.
Although writing a milter for postfix isn't all that complicated either.
Postfix has [ http://www.postfix.org/header_checks.5.html ], you can use that 
to remove a header (IGNORE), you just might be able to set that up to test for 
the right conditions *when* to do this, and then proceed to remove the header. 
Gotta run now so I can't put more thought into it at the moment but do post if 
you figure it out :D

Re: Is there a way to override Sieve's "not sending notification for auto-submitted message" behavior?

[Gedalya]

On 05/05/2016 01:00 AM, deoren wrote:
> Goal:
>
> 1) Setup a Google Calendar entry for a biweekly task
> 2) Configure the email notification schedule
> 3) When the email notification from Google arrives have Sieve send a
> notification to an alias I have setup for my cell provider's email to
> text messaging gateway
> 4) Receive text message
>
> I know there are other products which likely handle this better, but I'm
> specifically attempting to replicate old behavior by getting text
> message reminders when a specific Google Calendar event occurs.
>
> The problem I'm having is that Sieve is attempting to help by NOT
> sending a notification for emails that it finds are automatically
> generated. I didn't found a lot of information when I searched for
> additional details, but I didn't find an earlier message thread on this
> list that led me to believe that the default behavior is likely chosen
> as some sort of safety net to prevent common issues from occurring.
>
> What I would like to do is override this behavior at some level (per
> rule, per user, system-wide, whatever) to allow for Sieve notifications
> when emails matching a specific pattern are detected regardless of
> whether they are auto-generated or not.
>
> I already found mention in the documentation[1] that the editheader
> extension refuses to remove the Auto-Submitted header, so setting up a
> per user or global rule to do just that wouldn't help. I also haven't
> come upon a way to simply modify the value for the Auto-Submitted
> header, so that doesn't look to work in this situation either.
>
> Does anyone know of a way to accomplish this? Thanks in advance for your
> help!
>
> [1] http://wiki2.dovecot.org/Pigeonhole/Sieve/Extensions/Editheader

If you can't do it with dovecot / pigeonhole then consider doing something in 
the MTA like removing the Auto-Submitted header before delivery, or of course 
you can just send your notification out of there.
Which MTA are you using?

Re: Changing Password Schemes

[Gedalya]

Just make sure it says:

WHERE password IS NULL OR password='';

With no space between the quote marks, this way it matches an empty string


On 05/03/2016 12:29 PM, Carl Jeptha wrote:
> Thank you,
> Due to changes I had to make to let password_query work, I think your "quick" 
> version should be like this my setup:
>
> UPDATE mailbox set password = ENCRYPT(clearpwd, CONCAT('$6$',sha(RAND( 
> WHERE password IS NULL OR password=' ';
>
> 
> You have a good day now, en mag jou môre ook so wees,
>
> Carl A Jeptha
>
> On 2016-05-03 18:10, Gedalya wrote:
>> The script I sent you should do the job of populating your cryptpwd column 
>> with a SHA512-CRYPT version of the clearpwd column.
>> The only reason why you would bother with a perl script is to get a better 
>> quality salt from /dev/urandom
>> If you don't care so much about the quality of the salt, you can just run 
>> this single query.
>> Make a backup of your database first!!
>>
>> UPDATE mailbox set cryptpwd = ENCRYPT(clearpwd, CONCAT('$6$',sha(RAND( 
>> WHERE cryptpwd IS NULL OR cryptpwd=' ';
>>
>> Here you are using MySQL's RAND() function to generate salt. It will do the 
>> minimum job of making the resulting encrypted password not equal to a SHA512 
>> of the password itself, but the salt isn't very random. So the perl script I 
>> sent you reads 12 bytes of better quality random data from /dev/urandom and 
>> uses that. This means that if your database gets stolen it will be harder to 
>> decrypt the passwords.
>>
>>
>> On 05/03/2016 11:58 AM, Carl Jeptha wrote:
>>> Steffen,
>>> If you can point me in the direction as to how to convert a column of clear 
>>> text passwords to SHA512-CRYPT I will be happy to follow it and close this 
>>> query, I only came here because I had spent almost two weeks trying to make 
>>> the dovecot wiki work and thought someone would point out the mistakes I 
>>> had made.
>>>
>>> But otherwise, I will move on, and not waste anyone's time anymore.
>>>
>>> 
>>> You have a good day now, en mag jou môre ook so wees,
>>>
>>>
>>> Carl A Jeptha
>>>
>>> On 2016-05-03 07:02, Steffen Kaiser wrote:
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA1
>>>>
>>>> On Tue, 3 May 2016, Carl Jeptha wrote:
>>>>
>>>>> OK QUERY is WORKING ("password_query" relies on having a field/column
>>>>> "password', hence the addition under WHERE):
>>>>> password_query = \
>>>>>   SELECT username AS USER, \
>>>>> IF(cryptpwd IS NULL OR cryptpwd=' ', CONCAT('{PLAIN}',clearpwd),
>>>>> cryptpwd) AS PASSWORD, \
>>>>> '/var/vmail/%d/%n' as userdb_home, \
>>>>>   'maildir:/var/vmail/%d/%n' as userdb_mail, 150 as userdb_uid, 8 as
>>>>> userdb_gid \
>>>>>   FROM mailbox \
>>>>>   WHERE username = '%u' AND active = '1' AND cryptpwd = password 
>>>>> ('%w')
>>>>>
>>>>> But still no happy dance, we now have a new error:
>>>>>
>>>>> dovecot: imap-login: Disconnected (auth failed, 3 attempts in 15
>>>>> secs): user=<u...@domain.tld>, method=PLAIN, rip=165.255.109.89,
>>>>> lip=10.0.0.12, TLS, session=<LywBS+0xdQCl/21Z>
>>>> 1st) You should also enable auth debugging.
>>>>
>>>> 2nd) You are poking in the dark with SQL without understanding it,
>>>>
>>>> WHERE ... cryptpwd = password ('%w')
>>>>
>>>> 
>>>>
>>>> 3rd) I had the impression that you want to upgrade lower hashed passwords 
>>>> into stronger hashed ones with a specific scheme and that you therefore 
>>>> need to authentificate against two columns, but update the strong hashes 
>>>> from the entered plain text password if missing.
>>>>
>>>> If you already have access to the clear/text passwords, hash them, put the 
>>>> hashes into the database and be fine. No need for different columns and a
>>>> post login script.
>>>>
>>>> Otherwise: Nobody answered this particular question. And I see no 
>>>> evidance, that Dovecot passes an environment variable named PLAIN_PASSWORD 
>>>> along. I've read the Wiki, but I see nothing like that in the code. Did 
>>>> you've verified that the post login script gets the plain password?
>>>

Re: Changing Password Schemes

[Gedalya]

The script I sent you should do the job of populating your cryptpwd column with 
a SHA512-CRYPT version of the clearpwd column.
The only reason why you would bother with a perl script is to get a better 
quality salt from /dev/urandom
If you don't care so much about the quality of the salt, you can just run this 
single query.
Make a backup of your database first!!

UPDATE mailbox set cryptpwd = ENCRYPT(clearpwd, CONCAT('$6$',sha(RAND( 
WHERE cryptpwd IS NULL OR cryptpwd=' ';

Here you are using MySQL's RAND() function to generate salt. It will do the 
minimum job of making the resulting encrypted password not equal to a SHA512 of 
the password itself, but the salt isn't very random. So the perl script I sent 
you reads 12 bytes of better quality random data from /dev/urandom and uses 
that. This means that if your database gets stolen it will be harder to decrypt 
the passwords.


On 05/03/2016 11:58 AM, Carl Jeptha wrote:
> Steffen,
> If you can point me in the direction as to how to convert a column of clear 
> text passwords to SHA512-CRYPT I will be happy to follow it and close this 
> query, I only came here because I had spent almost two weeks trying to make 
> the dovecot wiki work and thought someone would point out the mistakes I had 
> made.
>
> But otherwise, I will move on, and not waste anyone's time anymore.
>
> 
> You have a good day now, en mag jou môre ook so wees,
>
>
> Carl A Jeptha
>
> On 2016-05-03 07:02, Steffen Kaiser wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Tue, 3 May 2016, Carl Jeptha wrote:
>>
>>> OK QUERY is WORKING ("password_query" relies on having a field/column
>>> "password', hence the addition under WHERE):
>>> password_query = \
>>>  SELECT username AS USER, \
>>>IF(cryptpwd IS NULL OR cryptpwd=' ', CONCAT('{PLAIN}',clearpwd),
>>> cryptpwd) AS PASSWORD, \
>>>'/var/vmail/%d/%n' as userdb_home, \
>>>  'maildir:/var/vmail/%d/%n' as userdb_mail, 150 as userdb_uid, 8 as
>>> userdb_gid \
>>>  FROM mailbox \
>>>  WHERE username = '%u' AND active = '1' AND cryptpwd = password ('%w')
>>>
>>> But still no happy dance, we now have a new error:
>>>
>>> dovecot: imap-login: Disconnected (auth failed, 3 attempts in 15
>>> secs): user=<u...@domain.tld>, method=PLAIN, rip=165.255.109.89,
>>> lip=10.0.0.12, TLS, session=<LywBS+0xdQCl/21Z>
>>
>> 1st) You should also enable auth debugging.
>>
>> 2nd) You are poking in the dark with SQL without understanding it,
>>
>> WHERE ... cryptpwd = password ('%w')
>>
>> 
>>
>> 3rd) I had the impression that you want to upgrade lower hashed passwords 
>> into stronger hashed ones with a specific scheme and that you therefore need 
>> to authentificate against two columns, but update the strong hashes from the 
>> entered plain text password if missing.
>>
>> If you already have access to the clear/text passwords, hash them, put the 
>> hashes into the database and be fine. No need for different columns and a
>> post login script.
>>
>> Otherwise: Nobody answered this particular question. And I see no evidance, 
>> that Dovecot passes an environment variable named PLAIN_PASSWORD along. I've 
>> read the Wiki, but I see nothing like that in the code. Did you've verified 
>> that the post login script gets the plain password?
>>
>> If you have hashed passwords, CONCAT('{PLAIN}',clearpwd) is nonsense.
>>
>>>
>>>
>>>
>>> On Tue, May 3, 2016 at 11:10 AM, Carl Jeptha <cajep...@gmail.com> wrote:
>>>
>>>> Here is what is in phpmyadmin:
>>>> password_query =
>>>> SELECT
>>>> username as user,
>>>> SELECT
>>>> IF(
>>>> cryptpwd IS NULL
>>>> OR cryptpwd = '',
>>>> CONCAT('{PLAIN}', clearpwd),
>>>> cryptpwd
>>>>  ) as password,
>>>> '/var/vmail/%d/%n' as userdb_home,
>>>> 'maildir:/var/vmail/%d/%n' as userdb_mail,
>>>> 150 as userdb_uid,
>>>> 8 as userdb_gid
>>>> FROM
>>>> mailbox
>>>> WHERE
>>>> username = '%u'
>>>> AND active = '1'
>>>>
>>>> and the error now:
>>>> #1064 - You have an error in your SQL syntax; check the manual that
>>>> corresponds to your MySQL server version for the right syntax to use near
>>>> 'password_query =
>>>> SELECT
>>>>

Re: Changing Password Schemes

[Gedalya]

Oh, you uppercased PASSWORD again.

Change:

IF(cryptpwd IS NULL OR cryptpwd=' ', CONCAT('{PLAIN}',clearpwd), cryptpwd) AS 
PASSWORD

To:

IF(cryptpwd IS NULL OR cryptpwd=' ', CONCAT('{PLAIN}',clearpwd), cryptpwd) AS 
password

and again, try to understand what's going on here.


On 05/03/2016 08:08 AM, Carl Jeptha wrote:
> 1. Auth debug turned on, - nothing
> 2. cryptpwd is the name of my "password" column, have to specify that if
> you want to run password_query as it relies on a field "password" to work.
> 3. I have access to the "clear passwords" but none of my google searches
> worked for converting them to SHA512_CRYPT
>
> On Tue, May 3, 2016 at 1:02 PM, Steffen Kaiser <
> skdove...@smail.inf.fh-brs.de> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Tue, 3 May 2016, Carl Jeptha wrote:
>>
>> OK QUERY is WORKING ("password_query" relies on having a field/column
>>> "password', hence the addition under WHERE):
>>> password_query = \
>>>  SELECT username AS USER, \
>>>IF(cryptpwd IS NULL OR cryptpwd=' ', CONCAT('{PLAIN}',clearpwd),
>>> cryptpwd) AS PASSWORD, \
>>>'/var/vmail/%d/%n' as userdb_home, \
>>>  'maildir:/var/vmail/%d/%n' as userdb_mail, 150 as userdb_uid, 8 as
>>> userdb_gid \
>>>  FROM mailbox \
>>>  WHERE username = '%u' AND active = '1' AND cryptpwd = password ('%w')
>>>
>>> But still no happy dance, we now have a new error:
>>>
>>> dovecot: imap-login: Disconnected (auth failed, 3 attempts in 15
>>> secs): user=<u...@domain.tld>, method=PLAIN, rip=165.255.109.89,
>>> lip=10.0.0.12, TLS, session=<LywBS+0xdQCl/21Z>
>>>
>> 1st) You should also enable auth debugging.
>>
>> 2nd) You are poking in the dark with SQL without understanding it,
>>
>> WHERE ... cryptpwd = password ('%w')
>>
>> 
>>
>> 3rd) I had the impression that you want to upgrade lower hashed passwords
>> into stronger hashed ones with a specific scheme and that you therefore
>> need to authentificate against two columns, but update the strong hashes
>> from the entered plain text password if missing.
>>
>> If you already have access to the clear/text passwords, hash them, put the
>> hashes into the database and be fine. No need for different columns and a
>> post login script.
>>
>> Otherwise: Nobody answered this particular question. And I see no
>> evidance, that Dovecot passes an environment variable named PLAIN_PASSWORD
>> along. I've read the Wiki, but I see nothing like that in the code. Did
>> you've verified that the post login script gets the plain password?
>>
>> If you have hashed passwords, CONCAT('{PLAIN}',clearpwd) is nonsense.
>>
>>
>>
>>>
>>> On Tue, May 3, 2016 at 11:10 AM, Carl Jeptha <cajep...@gmail.com> wrote:
>>>
>>> Here is what is in phpmyadmin:
>>>> password_query =
>>>> SELECT
>>>> username as user,
>>>> SELECT
>>>> IF(
>>>> cryptpwd IS NULL
>>>> OR cryptpwd = '',
>>>> CONCAT('{PLAIN}', clearpwd),
>>>> cryptpwd
>>>>  ) as password,
>>>> '/var/vmail/%d/%n' as userdb_home,
>>>> 'maildir:/var/vmail/%d/%n' as userdb_mail,
>>>> 150 as userdb_uid,
>>>> 8 as userdb_gid
>>>> FROM
>>>> mailbox
>>>> WHERE
>>>> username = '%u'
>>>> AND active = '1'
>>>>
>>>> and the error now:
>>>> #1064 - You have an error in your SQL syntax; check the manual that
>>>> corresponds to your MySQL server version for the right syntax to use near
>>>> 'password_query =
>>>> SELECT
>>>> username as user,
>>>> SELECT
>>>> IF(
>>>> cryptpwd IS NULL
>>>> ' at line 1
>>>>
>>>> On Mon, May 2, 2016 at 2:07 PM, Gedalya <geda...@gedalya.net> wrote:
>>>>
>>>> On 05/02/2016 05:32 AM, Carl Jeptha wrote:
>>>>>> May  2 05:26:03 |** dovecot: auth-worker(3442): Error:
>>>>>> sql(u...@domain.tld,xxx.xxx.xxx.xxx): Password query must return a
>>>>>> field named 'password'
>>>>>>
>>>>> I'm not sure, maybe it's checking case-sensitive. Your query returns
>>>>> PASSWORD. Make it lowercase.
>>>>>
>>>>>
>&

Re: Changing Password Schemes

[Gedalya]

Drop this from the end of your query:
 AND cryptpwd = password ('%w')

and Steffen is right, it wouldn't hurt you to get a better understanding of the 
principles at work here.
Nothing in this thread has had anything to do with dovecot so far.


On 05/03/2016 08:08 AM, Carl Jeptha wrote:
> 1. Auth debug turned on, - nothing
> 2. cryptpwd is the name of my "password" column, have to specify that if
> you want to run password_query as it relies on a field "password" to work.
> 3. I have access to the "clear passwords" but none of my google searches
> worked for converting them to SHA512_CRYPT
>
> On Tue, May 3, 2016 at 1:02 PM, Steffen Kaiser <
> skdove...@smail.inf.fh-brs.de> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Tue, 3 May 2016, Carl Jeptha wrote:
>>
>> OK QUERY is WORKING ("password_query" relies on having a field/column
>>> "password', hence the addition under WHERE):
>>> password_query = \
>>>  SELECT username AS USER, \
>>>IF(cryptpwd IS NULL OR cryptpwd=' ', CONCAT('{PLAIN}',clearpwd),
>>> cryptpwd) AS PASSWORD, \
>>>'/var/vmail/%d/%n' as userdb_home, \
>>>  'maildir:/var/vmail/%d/%n' as userdb_mail, 150 as userdb_uid, 8 as
>>> userdb_gid \
>>>  FROM mailbox \
>>>  WHERE username = '%u' AND active = '1' AND cryptpwd = password ('%w')
>>>
>>> But still no happy dance, we now have a new error:
>>>
>>> dovecot: imap-login: Disconnected (auth failed, 3 attempts in 15
>>> secs): user=<u...@domain.tld>, method=PLAIN, rip=165.255.109.89,
>>> lip=10.0.0.12, TLS, session=<LywBS+0xdQCl/21Z>
>>>
>> 1st) You should also enable auth debugging.
>>
>> 2nd) You are poking in the dark with SQL without understanding it,
>>
>> WHERE ... cryptpwd = password ('%w')
>>
>> 
>>
>> 3rd) I had the impression that you want to upgrade lower hashed passwords
>> into stronger hashed ones with a specific scheme and that you therefore
>> need to authentificate against two columns, but update the strong hashes
>> from the entered plain text password if missing.
>>
>> If you already have access to the clear/text passwords, hash them, put the
>> hashes into the database and be fine. No need for different columns and a
>> post login script.
>>
>> Otherwise: Nobody answered this particular question. And I see no
>> evidance, that Dovecot passes an environment variable named PLAIN_PASSWORD
>> along. I've read the Wiki, but I see nothing like that in the code. Did
>> you've verified that the post login script gets the plain password?
>>
>> If you have hashed passwords, CONCAT('{PLAIN}',clearpwd) is nonsense.
>>
>>
>>
>>>
>>> On Tue, May 3, 2016 at 11:10 AM, Carl Jeptha <cajep...@gmail.com> wrote:
>>>
>>> Here is what is in phpmyadmin:
>>>> password_query =
>>>> SELECT
>>>> username as user,
>>>> SELECT
>>>> IF(
>>>> cryptpwd IS NULL
>>>> OR cryptpwd = '',
>>>> CONCAT('{PLAIN}', clearpwd),
>>>> cryptpwd
>>>>  ) as password,
>>>> '/var/vmail/%d/%n' as userdb_home,
>>>> 'maildir:/var/vmail/%d/%n' as userdb_mail,
>>>> 150 as userdb_uid,
>>>> 8 as userdb_gid
>>>> FROM
>>>> mailbox
>>>> WHERE
>>>> username = '%u'
>>>> AND active = '1'
>>>>
>>>> and the error now:
>>>> #1064 - You have an error in your SQL syntax; check the manual that
>>>> corresponds to your MySQL server version for the right syntax to use near
>>>> 'password_query =
>>>> SELECT
>>>> username as user,
>>>> SELECT
>>>> IF(
>>>> cryptpwd IS NULL
>>>> ' at line 1
>>>>
>>>> On Mon, May 2, 2016 at 2:07 PM, Gedalya <geda...@gedalya.net> wrote:
>>>>
>>>> On 05/02/2016 05:32 AM, Carl Jeptha wrote:
>>>>>> May  2 05:26:03 |** dovecot: auth-worker(3442): Error:
>>>>>> sql(u...@domain.tld,xxx.xxx.xxx.xxx): Password query must return a
>>>>>> field named 'password'
>>>>>>
>>>>> I'm not sure, maybe it's checking case-sensitive. Your query returns
>>>>> PASSWORD. Make it lowercase.
>>>>>
>>>>>
>>>>>> For

Re: Changing Password Schemes

[Gedalya]

On 05/02/2016 05:32 AM, Carl Jeptha wrote:
> May  2 05:26:03 |** dovecot: auth-worker(3442): Error:
> sql(u...@domain.tld,xxx.xxx.xxx.xxx): Password query must return a
> field named 'password'
I'm not sure, maybe it's checking case-sensitive. Your query returns PASSWORD. 
Make it lowercase.

>
> For testing purposes I put the query in PHPMyAdmin and it complains this
> (notice it drops "PASSWORD", but shows it in the query:
> #1064 - You have an error in your SQL syntax; check the manual that
> corresponds to your MySQL server version for the right syntax to use near '\
> IF(cryptpwd IS NULL OR cryptpwd='', CONCAT('{PLAIN}',clearpwd),
> cryptpwd) as ' at line 1
>
>
It also sarts with a \ ... did you leave that in? That is specific to the 
dovecot config file. In PHPMyAdmin you should remove the line-continuation 
backslashes.

Actually if you use the mysql command-line client, you would be able to paste 
that in with the backlashes.

Make sure to put in a real value in WHERE username = '%u' <<<

Re: Changing Password Schemes

[Gedalya]

You do need to complete the query. Don't just replace your query with the one I 
wrote. You have to have a WHERE clause, and you might need to return other 
fields.
Keep the password query you had before, just replace the 'password' column with 
"IF( ... ) as password"
The query as you have it now simply returns all the passwords for all the 
users, because you don't have a WHERE clause.

On 05/01/2016 11:27 AM, Carl Jeptha wrote:
> Hi,
> Was testing your solution and was receiving:
>
> May  1 11:10:03 mail2 dovecot: message repeated 5 times: [
> auth-worker(24202): Error: sql(u...@domain.com,xxx.xxx.xxx.xxx):
> Password query returned multiple matches]
>
> Here is my dovecot-sql.conf.ext file:
>
> driver = mysql
> connect = host=127.0.0.1 dbname=vmail user=* password=*
> default_pass_scheme = SHA512-CRYPT
> password_query = SELECT IF(cryptpwd IS NULL OR
> cryptpwd='',CONCAT('{PLAIN}',clearpwd),cryptpwd)as password FROM mailbox
>  user_query = SELECT '/var/vmail/%d/%n' as home, 'maildir:/var/vmail/%d/%n'
> as mail, 150 AS uid, 8 AS gid, concat('dirsize:storage=', quota) AS quota
> FROM mailbox WHERE username = '%u' AND active = '1'
>
> 
> You have a good day now, en mag jou môre ook so wees,
>
> Carl A Jeptha
>
>
> On Sun, May 1, 2016 at 3:02 AM, Gedalya <geda...@gedalya.net> wrote:
>
>> First of all, you can probably go online before you convert all passwords.
>> You can modify your query in dovecot-sql.conf.ext to something like the
>> following:
>>
>> SELECT IF(crypt_pass IS NULL OR crypt_pass='',
>> CONCAT('{PLAIN}',plain_pass), crypt_pass) as password FROM mailuser ..
>>
>> This is assuming that:
>>
>> * for incoming users, you have a plain_pass column containing just the
>> plaintext password, without a {PLAIN} prefix, which we are adding in the
>> query, letting dovecot process it correctly
>> * for these users, your other password column, "crypt_pass" in this
>> example, is either NULL or an empty string.
>> * once crypt_pass is populated, it will contain a usable value, and this
>> value will be returned by the query.
>>
>>
>> Now, as for converting your database, try this, after adjusting the
>> queries to fit your schema:
>>
>> #!/usr/bin/perl
>> use strict;
>> use warnings;
>> use DBI;
>> use MIME::Base64 'encode_base64';
>>
>> my $dbtype = 'mysql';
>> my $dbhost = 'localhost';
>> my $dbname = 'maildb';
>> my $dbuser = 'dbuser';
>> my $dbpass = 'password';
>>
>> my $dbh = DBI->connect("DBI:$dbtype:host=$dbhost;database=$dbname",
>> $dbuser, $dbpass)
>> or die "Could not connect to database: " . $DBI::errstr . "\n";
>> my $selectsth = $dbh->prepare('SELECT localpart, domain, plain_pass FROM
>> mailuser where crypt_pass IS NULL OR crypt_pass=""');
>> my $updatesth = $dbh->prepare('UPDATE mailuser SET crypt_pass=? where
>> localpart=? and domain=?');
>> $selectsth->execute;
>> while (my $row = $selectsth->fetchrow_hashref) {
>> open my $urand, '<', '/dev/urandom';
>> read $urand, my $salt, 12;
>> close $urand;
>> $salt = encode_base64($salt);
>> $salt =~ s/\+/\./g;
>> $salt =~ s/[^0-9a-z\.\/]//ig; #this shouldn't be needed
>> my $cryptpw = '{SHA512-CRYPT}' . crypt $row->{plain_pass}, '$6$'.$salt;
>> print "$row->{localpart}\@$row->{domain}: $cryptpw\n";
>> # uncomment this when you feel comfortable
>> #$updatesth->execute($cryptpw, $row->{localpart}, $row->{domain});
>> }
>>
>>
>> You can run this safely with the last line commended out, and review the
>> output. Perhaps try to test by manually updating one user with the
>> displayed output. If everything seems sane, uncomment the line and run
>> again.
>>
>>
>> On 04/30/2016 02:52 PM, Carl A Jeptha wrote:
>>> Sorry not truncated:
>>>
>> {SHA512-CRYPT}$6$wEn1UFuiMzl9OSjd$Vh/PZ95WDID1GwI02QWAQNNfY5.Rk9zcSetYTgRfo4SPKf8qzMXsruvvS8uaSUidlvwDTLLSr3cVsQx2e6cu2/
>>> 
>>> You have a good day now, en mag jou môre ook so wees,
>>>
>>> Carl A Jeptha
>>>
>>> On 2016-04-30 14:58, Patrick Domack wrote:
>>>> This looks good, except it is truncated, it should be something like
>> 95chars long, Is your hash column set to 128 or up around there or larger?
>>>>
>>>> Quoting Carl A Jeptha <cajep...@gmail.com>:
>>>>
>>>>> Sorry for double reply, but this what a password lo

Re: Changing Password Schemes

[Gedalya]

First of all, you can probably go online before you convert all passwords. You 
can modify your query in dovecot-sql.conf.ext to something like the following:

SELECT IF(crypt_pass IS NULL OR crypt_pass='', CONCAT('{PLAIN}',plain_pass), 
crypt_pass) as password FROM mailuser ..

This is assuming that:

* for incoming users, you have a plain_pass column containing just the 
plaintext password, without a {PLAIN} prefix, which we are adding in the query, 
letting dovecot process it correctly
* for these users, your other password column, "crypt_pass" in this example, is 
either NULL or an empty string.
* once crypt_pass is populated, it will contain a usable value, and this value 
will be returned by the query.


Now, as for converting your database, try this, after adjusting the queries to 
fit your schema:

#!/usr/bin/perl
use strict;
use warnings;
use DBI;
use MIME::Base64 'encode_base64';

my $dbtype = 'mysql';
my $dbhost = 'localhost';
my $dbname = 'maildb';
my $dbuser = 'dbuser';
my $dbpass = 'password';

my $dbh = DBI->connect("DBI:$dbtype:host=$dbhost;database=$dbname", $dbuser, 
$dbpass)
or die "Could not connect to database: " . $DBI::errstr . "\n";
my $selectsth = $dbh->prepare('SELECT localpart, domain, plain_pass FROM 
mailuser where crypt_pass IS NULL OR crypt_pass=""');
my $updatesth = $dbh->prepare('UPDATE mailuser SET crypt_pass=? where 
localpart=? and domain=?');
$selectsth->execute;
while (my $row = $selectsth->fetchrow_hashref) {
open my $urand, '<', '/dev/urandom';
read $urand, my $salt, 12;
close $urand;
$salt = encode_base64($salt);
$salt =~ s/\+/\./g;
$salt =~ s/[^0-9a-z\.\/]//ig; #this shouldn't be needed
my $cryptpw = '{SHA512-CRYPT}' . crypt $row->{plain_pass}, '$6$'.$salt;
print "$row->{localpart}\@$row->{domain}: $cryptpw\n";
# uncomment this when you feel comfortable
#$updatesth->execute($cryptpw, $row->{localpart}, $row->{domain});
}


You can run this safely with the last line commended out, and review the 
output. Perhaps try to test by manually updating one user with the displayed 
output. If everything seems sane, uncomment the line and run again.


On 04/30/2016 02:52 PM, Carl A Jeptha wrote:
> Sorry not truncated:
> {SHA512-CRYPT}$6$wEn1UFuiMzl9OSjd$Vh/PZ95WDID1GwI02QWAQNNfY5.Rk9zcSetYTgRfo4SPKf8qzMXsruvvS8uaSUidlvwDTLLSr3cVsQx2e6cu2/
>
> 
> You have a good day now, en mag jou môre ook so wees,
>
> Carl A Jeptha
>
> On 2016-04-30 14:58, Patrick Domack wrote:
>> This looks good, except it is truncated, it should be something like 95chars 
>> long, Is your hash column set to 128 or up around there or larger?
>>
>>
>> Quoting Carl A Jeptha <cajep...@gmail.com>:
>>
>>> Sorry for double reply, but this what a password looks like in the "hashed" 
>>> password column:
>>> {SHA512-CRYPT}$6$wEn1UFuiMzl9OSjd$Vh/PZ95WDID1GwI2
>>>
>>> 
>>> You have a good day now, en mag jou môre ook so wees,
>>>
>>> On 2016-04-30 01:14, Gedalya wrote:
>>>> That's not SHA512-CRYPT. That's just a simple sha512 of the password, 
>>>> without salt.
>>>>
>>>> A SHA512-CRYPT password will be generated with:
>>>>
>>>> printf "1234\n1234" | doveadm pw -s SHA512-CRYPT
>>>>
>>>> or:
>>>>
>>>> doveadm pw -s SHA512-CRYPT -p 1234
>>>>
>>>> or:
>>>>
>>>> mkpasswd -m sha-512 1234
>>>>
>>>> (without the "{SHA512-CRYPT}" prefix)
>>>>
>>>> What exactly is the difficulty you are having with converting the 
>>>> passwords?
>>>> What database engine are you using?
>>>>
>>>>
>>>> On 04/29/2016 03:20 PM, Bill Shirley wrote:
>>>>> Looks like an SQL update would do this:
>>>>> UPDATE `users`
>>>>> SET `passwd_SHA512` = SHA2(`passwd_clear`, 512);
>>>>>
>>>>> Bill
>>>>>
>>>>> On 4/29/2016 9:07 AM, Carl A Jeptha wrote:
>>>>>> converting the passwords in the database from clear/plain text to 
>>>>>> SHA512-CRYPT

Re: Changing Password Schemes

[Gedalya]

That's not SHA512-CRYPT. That's just a simple sha512 of the password, without 
salt.

A SHA512-CRYPT password will be generated with:

printf "1234\n1234" | doveadm pw -s SHA512-CRYPT

or:

doveadm pw -s SHA512-CRYPT -p 1234

or:

mkpasswd -m sha-512 1234

(without the "{SHA512-CRYPT}" prefix)

What exactly is the difficulty you are having with converting the passwords?
What database engine are you using?


On 04/29/2016 03:20 PM, Bill Shirley wrote:
> Looks like an SQL update would do this:
> UPDATE `users`
> SET `passwd_SHA512` = SHA2(`passwd_clear`, 512);
>
> Bill
>
> On 4/29/2016 9:07 AM, Carl A Jeptha wrote:
>> converting the passwords in the database from clear/plain text to 
>> SHA512-CRYPT 

Re: apt pinning specific dovecot version

[Gedalya]

On 04/26/2016 05:26 PM, Regan Jelčić wrote:
> I currently have the dovecot-core package from wheezy-backports pinned on one 
> of my servers to version '2.2.9', which has been working great. I now want to 
> upgrade that to the newest version under wheezy-backports which is:
>
> dovecot-core (1:2.2.13-11~bpo70+1)
> but I can't figure out how to get do it. I've tried a few different formats 
> of the name but apt-get update then apt-get dost-upgrade doesn't pick up the 
> new version - it ignores it when trying to do an update.
>
> This is what I've got in my apt preferences and pin files...
>
> /etc/apt/preferences
>
> Explanation: Stop ALL wheezy-backports updating system.
> Package: *
> Pin: release a=wheezy-backports,n=wheezy-backports
> Pin-Priority: 100 
> /etc/apt/preferences.d/dovecot.pref
>
> Explanation: Promote wheezy-backports version of Dovecot only
> Package: dovecot-core /2\.2\.9/
> Pin: release a=wheezy-backports
> Pin-Priority: 500
> Can anyone advise how I get it to pull the newer version??
>
> Thanks,

Have you tried something like:
apt-get --only-upgrade -twheezy-backports install dovecot-core dovecot-imapd 

recipient delimiter translation with exim

[Gedalya]

In case anyone is interested:

Say I want to allow multiple recipient delimiters, possibly more than one 
character long, and dovecot is configured to use the + sign.
In my case I decided to also allow the following: ".-" "__" and ".."

My last router in exim is mysql_user and the one before that is mysql_alias. I 
added the following before mysql_alias:

suffix_translate:
  debug_print = "R: suffix_translate for $local_part@$domain"
  driver = redirect
  domains = +virtual_domains
  local_part_suffix = .-* : __* : ..*
  data = 
${quote_local_part:$local_part${sg{$local_part_suffix}{\N^(\.-|__|\.\.)\N}{+}}}@$domain
# the following is an "optimization" or just a way to make the debug output 
less tedious. It prevents
# exim from going all the way back to the first router with the new address
  redirect_router = mysql_alias

In the dovecot_lmtp transport, I added the rcpt_include_affixes option.

With LDA, use the -a flag as follows:
-a $local_part$local_part_suffix@$domain

With LMTP, using the envelope_to_add option and configuring dovecot to use it 
with the lda_original_recipient_header option, I get an Envelope-To header 
populated with the original recipient, and dovecot uses that one for some 
reason. See my other message posted on this list.

Re: multiple recipient_delimiter

[Gedalya]

Would be useful to me as well, if this gets merged.


On 03/31/2016 11:42 PM, Patrick Domack wrote:
> No, my patch still applies to make this happen though. It's just a one 
> word/line patch.
>
>
> Quoting Jörg Backschues :
>
>> Hello,
>>
>> does the recipient_delimiter option accepts multiple delimiter by now?
>>
>> -- 
>> Regards
>> Jörg Backschues

Re: Option to not add "Received" header ?

[Gedalya]

On 03/21/2016 10:00 AM, Timo Sirainen wrote:
> On 21 Mar 2016, at 22:08, Tom Sommer  wrote:
>> On 2015-03-24 12:27, Florent B wrote:
>>
>>> I use Dovecot in lmtp mode to receive mails.
>>> I would like an option to tell Dovecot to not add a "Reveived" header on
>>> each server (I use a director, so Director also adds this header).
>> I would love this as well.
> How about the other way around: Does anybody want Dovecot LMTP to add a 
> Received header? dovecot-lda doesn't. And proxy/director logs nowadays about 
> what goes through them. Dovecot itself doesn't check the Received headers in 
> any way for looping or other purposes. Maybe Dovecot v2.3 shouldn't add any 
> Received headers at all?
I'd say definitely add an option. I can think of some deployments where I would 
set it one way and some where I would the other way.

Re: Logging the TLS cipher suite

[Gedalya]

Forgot the important part, sorry
http://wiki.dovecot.org/Variables


On 03/12/2016 12:30 AM, Gedalya wrote:

Add %k to login_log_format_elements (in conf.d/10-logging.conf)
for example

login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e 
%c %k session=<%{session}>



On 03/12/2016 12:20 AM, Luigi Rosa wrote:

Hi,
could it be possible to log the TLS cipher suite as Postfix does?

This is a typical TLS Dovecot log line:

imap-login: Login: user=<u...@acme.com>, method=DIGEST-MD5, 
rip=1.2.3.4, lip=4.3.2.1, mpid=19671, TLS, session=


This is the Postfix equivalent

postfix/smtp[59723]: Anonymous TLS connection established to 
mail.acmne.com[1.2.3.4]:25: TLSv1.2 with cipher AECDH-AES256-SHA 
(256/256 bits)

Re: Logging the TLS cipher suite

[Gedalya]

Add %k to login_log_format_elements (in conf.d/10-logging.conf)
for example

login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e %c 
%k session=<%{session}>



On 03/12/2016 12:20 AM, Luigi Rosa wrote:

Hi,
could it be possible to log the TLS cipher suite as Postfix does?

This is a typical TLS Dovecot log line:

imap-login: Login: user=, method=DIGEST-MD5, 
rip=1.2.3.4, lip=4.3.2.1, mpid=19671, TLS, session=


This is the Postfix equivalent

postfix/smtp[59723]: Anonymous TLS connection established to 
mail.acmne.com[1.2.3.4]:25: TLSv1.2 with cipher AECDH-AES256-SHA 
(256/256 bits)

Re: Ubuntu packages

[Gedalya]

On 03/07/2016 01:28 AM, Jaldhar H. Vyas wrote:

On Mon, 7 Mar 2016, Andrew McGlashan wrote:



Many of us Debian users hate the fact that systemd even exists. for
now we can run servers without systemd, but who knows in a few years or
a couple of releases.



I can't speak for the project as a whole but you'll take my sysvinit 
when you pry it from my cold dead hands :-)




Please keep it that way!! I use sysvinit on all machines - desktop, 
laptop, server, except where broken non-official packages (e.g. graylog) 
support only systemd.
I find systemd a horrendous little toy that sometimes behaves in 
outright silly ways. A Rube Goldberg machine is, by definition, 
something that never will go into production.

Re: Implementation of TLS OCSP Stapling

[Gedalya]

On 03/03/2016 08:17 AM, dove...@flut.demon.nl wrote:
> On 03-03-16 14:09, Gedalya wrote:
>> On 03/03/2016 07:30 AM, Stephan Bosch wrote:
>>> BTW, I can imagine that Thunderbird can already do that, as it shares much 
>>> of the Firefox code base.
>> Thunderbird definitely does validate certificates via OCSP, enabled by 
>> default and I've run into that the hard way a couple of times wrt StartSSL 
>> having issues with their responder. This isn't hypothetical, guys
> OCSP status querying isn't the same as verifying stapled OCSP responses
> though. Can't find Thunderbird's support for stapling unfortunately..
No, it's not the same, but the claim was no use of OCSP at all.
Either way, this guy claims Thunderbird uses stapling, but with HTTP?
http://mobilesociety.typepad.com/mobile_life/2015/03/ocsp-stapling-and-android-that-doesnt-care.html
As Stephan pointed out, it's the same code base as Firefox. If someone can name 
an IMAP server that supports stapling, we could test it.

Re: Implementation of TLS OCSP Stapling

[Gedalya]

On 03/03/2016 07:30 AM, Stephan Bosch wrote:
> BTW, I can imagine that Thunderbird can already do that, as it shares much of 
> the Firefox code base.
Thunderbird definitely does validate certificates via OCSP, enabled by default 
and I've run into that the hard way a couple of times wrt StartSSL having 
issues with their responder. This isn't hypothetical, guys

Re: v2.2.20 release candidate released

[Gedalya]

On 12/06/2015 07:19 AM, Gerhard Wiesinger wrote:
Session tickets are broken by DESIGN as they violate PFS (Perfect 
Forward Secrecy). If you can steal one AES key (all session tickets 
are encrypted for server lifetime with only one key) you can decrypt 
ALL sessions ever made with session tickets for the future.


I'm in no way an expert or an authority, but it is my understanding that 
there being only one key for the server's lifetime is not exactly by 
design, rather (sloppy) implementation. See [0] as an example of at 
least a discussion on key rotation or even smooth rollover.
Perhaps in a perfect world, those who don't find a session cache 
suitable could instead use a better implementation of session tickets. 
Until of course someone takes security shaming to the next level and 
declares session tickets unconditionally evil. Notably, Qualys isn't 
doing that yet. Even Google is currently otherwise engaged. 
Superficially speaking, both approaches sound like a matter of securing 
server memory space and rotating things out frequently.


[0] http://mailman.nginx.org/pipermail/nginx-devel/2013-October/004373.html

Re: v2.2.20 release candidate released

[Gedalya]

On 12/05/2015 04:32 AM, Gerhard Wiesinger wrote:

like in nginx


And OCSP Stapling would be nice too :-)

Re: Thanks for Dovecot

[Gedalya]

On 10/13/2015 04:00 PM, Steve Litt wrote:

Hi all,

Thanks for making Dovecot.

I just transitioned from Debian Wheezy to Void Linux. It was fairly
easy to get Dovecot working on my Void box, and having Dovecot makes
all of my email activities easier by doing one thing and doing it right.

Thank you for such great software.

SteveT


Hey, you know what? It's never a bad time to join in and say a simple:
Thank you!

Re: [Dovecot] dsync replication errors

[Gedalya]

On 02/17/2013 03:21 AM, Timo Sirainen wrote:

Although there's still some mail
duplication problem with maildir that doesn't log any errors about it.
I'm not sure why that happens.


While you're around, Timo :-)

I've had such an issue recently with 2.2.18, using Maildir, where emails 
were being replicated circularly creating more and more duplicate copies.
Replication should have been unidirectional in reality since changes 
were being made on one side only.
Nothing coherent was being logged. Only "Warning: Maildir 
/srv/mail/domains/.../Maildir: Expunged message reappeared, giving a new 
UID .. " appearing on the receiving side.
Is there any intelligence on the matter, or should I isolate this down 
and report it from scratch?

Re: How about an option to disbale headers? (was Re: Patch for doveadm -f table nit)

[Gedalya]

On 05/24/2015 03:08 AM, Gedalya wrote:

On 03/20/2015 02:47 PM, Timo Sirainen wrote:

Added -h parameter now to hg.


Using 2.2.18.
With -f table this behaves as expected, however with -t tab the output 
seems to include the separating tabs of the header line prepended to 
the first line of output.
In other words, the header line is printed partially - only the tabs, 
no actual headers and no newline.


Timo?

Re: Testin new installation

[Gedalya]

On 06/13/2015 01:41 PM, Steve Matzura wrote:

On Sat, 13 Jun 2015 10:36:21 -0600, you wrote:


Look at /etc/hosts ::1 is the ipv6 version of localhost.

Right. I actually knew that. So why does that take precedence for the
definition of localhost even though it's not the first line in the
file?

IPv6 is preferred when available.
See man 5 gai.conf

Re: Imap Notify

[Gedalya]

On 06/12/2015 03:38 PM, Tony Morehen wrote:

Despite this, NOTIFY did not show up it Dovecot's capabilities:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE 
IDLE AUTH=PLAIN] Dovecot ready. 


It should show up in the post-login capabilities.
Do a login first, then you get a second, much longer capability string

Re: FREAK/Logjam, and SSL protocols to use

[Gedalya]

On 05/27/2015 11:56 AM, Rick Romero wrote:

 Quoting Gedalya geda...@gedalya.net:


On 05/27/2015 09:55 AM, Rick Romero wrote:

Quoting Gedalya geda...@gedalya.net:


On 05/26/2015 10:37 AM, Ron Leach wrote:

https://weakdh.org/sysadmin.html

includes altering DH parameters length to 2048, and re-specifying the
allowable cipher suites - they give their suggestion.


It looks like there is an error on this page regarding 
regeneration. In

current dovecots ssl_parameters_regenerate defaults to zero, and this
means regeneration is disabled. The old default was 168 hours (1 
week).

The language on http://wiki2.dovecot.org/SSL/DovecotConfiguration is
confusing and could be understood to mean that the current default is
one week.
To enable regeneration you can manually set:
ssl_parameters_regenerate = 60 days
or:ssl_parameters_regenerate = 1 weeks


This is really cool and all, but for a low power proxy, it takes a good

5

minutes to regenerate the dh params, and Dovecot listens the entire

time.


If the socket were closed during regeneration, then a (basic) front-end
load balancer wouldn't still push connections to that proxy during

regen.


Rick


I wonder if what is taking 5 minutes is CPU usage or entropy starvation.
Might be worth looking into.


I'd say CPU usage - I have two identical VMs for dovecot proxies, one is
hosted on a dual Xeon 5450, the other a dual Opteron 2347HE.  Both hosts
are under similar load, but the Xeon host was done within 30 seconds. I
assume the Xeon, besides having a faster base CPU frequency, is just 
better

for that sort of workload.

I noticed a similar difference when generating params for the web 
servers,

but I did that externally.

I assume it'd probably be easier to do the dh_parameters config than to
fully disable the socket during regen..

Rick


Are the results repeatable? The time it takes openssl to generate new 
params is, well, literally random.
I wish someone could tell me why, but 'certtool --generate-dh-params 
--bits 2048' (from gnutls) takes just a few seconds, and openssl can 
take several minutes. And BTW on second thought I think openssl doesn't 
actually read much from /dev/random but just uses its own PRNG so 
entropy starvation might not actually apply here. So yea it's just CPU 
and sheer luck in terms of how quickly it stumbles upon the right 
primes. As for gnutls - I have no idea how that works, but it's very fast.


Anyway I've certainly seen newer Xeons than 5450 take well over 30 
seconds to generate 2048-bit dh params. If yours consistently does it in 
30 seconds then I'd love to understand how come.

Re: FREAK/Logjam, and SSL protocols to use

[Gedalya]

On 05/27/2015 12:15 PM, Ron Leach wrote:


I couldn't find an entry in 10-ssl.config that covered regeneration 
(though our version is 2.2.15 and the current release, 2.2.18, may 
differ). 


Yea it's just not there. You can 'discover' these 'hidden' options using 
doveconf -a, scattered docs, and the source code ;-)

Re: FREAK/Logjam, and SSL protocols to use

[Gedalya]

On 05/27/2015 09:55 AM, Rick Romero wrote:

 Quoting Gedalya geda...@gedalya.net:


On 05/26/2015 10:37 AM, Ron Leach wrote:

https://weakdh.org/sysadmin.html

includes altering DH parameters length to 2048, and re-specifying the
allowable cipher suites - they give their suggestion.


It looks like there is an error on this page regarding regeneration. In
current dovecots ssl_parameters_regenerate defaults to zero, and this
means regeneration is disabled. The old default was 168 hours (1 week).
The language on http://wiki2.dovecot.org/SSL/DovecotConfiguration is
confusing and could be understood to mean that the current default is
one week.
To enable regeneration you can manually set:
ssl_parameters_regenerate = 60 days
or:ssl_parameters_regenerate = 1 weeks


This is really cool and all, but for a low power proxy, it takes a good 5
minutes to regenerate the dh params, and Dovecot listens the entire time.

If the socket were closed during regeneration, then a (basic) front-end
load balancer wouldn't still push connections to that proxy during regen.

Rick


I wonder if what is taking 5 minutes is CPU usage or entropy starvation. 
Might be worth looking into.


However the entire reason why I wrote this comment was to correct the 
mistaken line saying #regenerates every week. It is not at this point 
emphasized anywhere, including on weakdh.org, that it is actually of 
high importance to regenerate your DH parameters frequently. This has 
been discussed extensively e.g. within the exim project and other 
places, and on dovecot too the default was changed to not regenerate. It 
seems that people are mostly just saying you should have locally 
generated parameters unique to your site.


But to address your point, if this feature is deemed worth maintaining, 
it seems it would be best to spawn a thread working on the new 
parameters in the background and replacing them when ready.


Otherwise dovecot can just implement a dh_parameters config option like 
all other daemons and you can maintain that externally as you please. 
But we're supposed to be focusing on EC anyway :-)

Re: FREAK/Logjam, and SSL protocols to use

[Gedalya]

On 05/27/2015 12:29 PM, Jacques Distler wrote:

It is not at this point emphasized anywhere, including on weakdh.org, that it 
is actually of high importance to regenerate your DH parameters frequently.

That's not really correct.

If you're using a prime of length at least 2048 bits, then the corresponding 
discrete-log problem is well-beyond the pre-computation ability of the NSA (or 
anyone else).

It is computationally intensive to generate such large primes, p (and 
corresponding base parameter, g). You need to ensure that p is actually prime 
(the costly step [1]) and that g is primitive.

Which is why most implementations have used shorter (= 1024 bit) primes.

Using shorter primes, and regenerating DH parameters at regular intervals, is 
only a linear-time improvement. By contrast, generating longer DH parameters 
(without bothering to regenerate) is an EXPONENTIAL improvement in security.

So the best setting is to set ssl_dh_parameters_length as large as feasible 
([2] recommends 2048 bits), and NOT to regenerate.


Well that's certainly what I meant to say. By referring to weakdh.org 
(and placing my message in the context of this entire thread) I was at 
the very least subtly alluding to the recommendation loudly stated there 
to use at least 2048 bits, which has been the recommendation for a very 
long time, anyway. The implementation in the various TLS libraries was 
never a very good reference point, to put it mildly. Some bad choices 
have been made presumably for pragmatic (= lazy) reasons and the harm 
is that these things are not transparent to most people.


But when you write NOT to regenerate, are you saying that using larger 
primes makes regenerating unnecessary, or are you telling us that it's 
somehow harmful?

Re: FREAK/Logjam, and SSL protocols to use

[Gedalya]

On 05/26/2015 10:37 AM, Ron Leach wrote:


https://weakdh.org/sysadmin.html

includes altering DH parameters length to 2048, and re-specifying the 
allowable cipher suites - they give their suggestion. 


It looks like there is an error on this page regarding regeneration. In 
current dovecots ssl_parameters_regenerate defaults to zero, and this 
means regeneration is disabled. The old default was 168 hours (1 week).
The language on http://wiki2.dovecot.org/SSL/DovecotConfiguration is 
confusing and could be understood to mean that the current default is 
one week.

To enable regeneration you can manually set:
ssl_parameters_regenerate = 60 days
or:
ssl_parameters_regenerate = 1 weeks

Re: How about an option to disbale headers? (was Re: Patch for doveadm -f table nit)

[Gedalya]

On 03/20/2015 02:47 PM, Timo Sirainen wrote:

Added -h parameter now to hg.


Using 2.2.18.
With -f table this behaves as expected, however with -t tab the output 
seems to include the separating tabs of the header line prepended to the 
first line of output.
In other words, the header line is printed partially - only the tabs, no 
actual headers and no newline.

Re: Controlling IP addresses for services

[Gedalya]

On 05/22/2015 11:40 PM, Alex Regan wrote:

service imap-login {
  inet_listener imaps {
listen=192.168.1.100
port = 993
  }
}


# dovecot -n
# 2.2.15: /etc/dovecot/dovecot.conf
doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf 
line 54: Unknown setting: listen 


http://wiki2.dovecot.org/Services#inet_listeners

Try address instead of listen

Re: doveadm -D and -v options

[Gedalya]

On 04/30/2015 02:51 AM, Reuben Farrelly wrote:
According to doveadm-dsync man page the above two options are valid, 
but they are rejected when used:


tornado # doveadm backup -v -u testuser remote:pi.me.name:4814
backup: invalid option -- 'v'
doveadm backup [-u user|-A] [-S socket_path] [-fPRU] [-l secs] 
[-r rawlog path] [-m mailbox] [-g mailbox_guid] [-n namespace 
| -N] [-x exclude] [-s state] -d|dest

tornado #
tornado # doveadm backup -D -u testuser remote:pi.me.name:4814
backup: invalid option -- 'D'
doveadm backup [-u user|-A] [-S socket_path] [-fPRU] [-l secs] 
[-r rawlog path] [-m mailbox] [-g mailbox_guid] [-n namespace 
| -N] [-x exclude] [-s state] -d|dest

tornado #

This is with 2.2.16 (latest -hg).   Looks to me like either a bug, or 
the documentation (man doveadm-sync) is incorrect...?


Reuben


The man page appears to be wrong. [-Dv] belongs right after doveadm, 
before [sync|backup]


doveadm -v backup -u testuser remote:pi.me.name:4814

Re: Xi broken

[Gedalya]

On 04/30/2015 01:52 PM, Stephan Bosch wrote:

Hi,

Xi is broken at the moment. This XenServer version won't boot jessie
kernel.

Can't fix this myself, so this may take some time.

Regards,

Stephan.


I had this issue too with XenServer. Changed to hvm to make it boot. It 
worked.

Re: Postpone email delivery with LMTP and Postfix

[Gedalya]

On 04/29/2015 04:47 PM, Miloslav Hůla wrote:

Hi,

is there any way, based on userdb/passwdb attribute, how to postpone 
an email delivery? The purpose is, I need to freeze an account 
(Maildir++) for a few minutes and new email must not be delivered. But 
emails must be delivered when account is unfrozen.


I found few things about Postfix filters, but I'm not sure it's a good 
way.


Thank you, Milo
The right way would probably be to use a transport map in postfix to 
defer deliveries for specific recipients.

Re: ManageSieve Dovecot v2 listen on localhost only

[Gedalya]

address = 127.0.0.1
port = 4190


On 04/17/2015 04:21 PM, tr...@skrilnetz.net wrote:


Hi,

How can I only listen on localhost for ManageSieve?

I tried:

port = localhost:4190

still listening *:
tcp0  0 0.0.0.0:4190 0.0.0.0:*   LISTEN  
0  515675 20540/dovecot


Would did I not get here?

Thanks,

Re: Replace autocreate after upgrading

[Gedalya]

On 04/17/2015 09:27 AM, tr...@skrilnetz.net wrote:

Hi,

I just upgraded to 2.2.9 and found out that autocreate should not be 
used any more. I had a look at 
http://wiki2.dovecot.org/MailboxSettings and I tried to replace my old 
config but I had no success. Would somebody be so and help me to 
change my config?


Here is my old config:
http://pastebin.com/zFUAQmV3

Thanks,



See http://wiki2.dovecot.org/MailboxSettings

This is in conf.d/10-mail.conf

namespace inbox {
type = private
separator = /
inbox = yes
}

This is in conf.d/15-mailboxes.conf, we're adding more settings into the 
same namespace


namespace inbox {
mailbox Trash {
auto = subscribe
# you probably want:
special_use = \Trash
}
mailbox Sent {
auto = subscribe
# you probably want:
special_use = \Sent
}
}

this you should remove: mail_plugins = autocreate

Re: ManageSieve Dovecot v2 listen on localhost only

[Gedalya]

http://wiki2.dovecot.org/Services