Re: Perl was: JMAP: Re: http API for IMAP

[Jean-Daniel via dovecot]

> Le 19 nov. 2019 à 09:14, Thomas Güttler via dovecot  a 
> écrit :
> 
> Am 18.11.19 um 16:18 schrieb Ralph Seichter via dovecot:
>> * Thomas Güttler via dovecot:
>>> https://github.com/guettli/programming-guidelines#regex-are-great---but-its-like-eating-rubbish
>> Thanks for including the disclaimer "It's my personal opinion and
>> feeling. No facts, no single truth." in your 'guidelines' (many of which
>> I disagree with). I just wish you had included the same disclaimer in
>> what you wrote in this thread, instead of presenting your personal
>> opinions and beliefs as facts.
>> Also, this has drifted far away from being related to Dovecot in any
>> useful way.
> 
> 
> You disagree? Great! I am curious. What is wrong in my personal
> guidelines?

Please, if you want to start a coding style flame war, do that in private.
I think we got enough mails from this this discussion that are completely off 
the dovecot list subject.

Re: IMAP4 extensions for Visual Voicemail (VVM)

[Jean-Daniel via dovecot]

> Le 20 oct. 2019 à 22:24, Mauricio Tavares via dovecot  a 
> écrit :
> 
> On Sun, Oct 20, 2019 at 10:43 AM Rajesh Bansal via dovecot
>  wrote:
>> 
>> Hi Team,
>> 
>> 
>> 
>> I need to develop Visual VoiceMail solution. In this solution I need a IMAP4 
>> server, from which I can get a hit for each mail retrieval. Can anyone help 
>> me if dovecot can be used for this purpose.
>> 
>  That is rather vague. Do you want to do something like ol' biff
> or what we used to do with Asterix 10 years ago (get an email with the
> voicemail as as attachment)?

I guess he is talking about that: 
https://www.gsma.com/newsroom/wp-content/uploads/2012/07/OMTP_VVM_Specification_1_3.pdf
 



> 
>> 
>> BR,
>> 
>> Rajesh Bansal
>> 
>> 

Re: Password issue

[Jean-Daniel via dovecot]

> Le 12 oct. 2019 à 03:26, @lbutlr via dovecot  a écrit :
> 
> On Oct 11, 2019, at 2:00 PM, Joseph Tam  wrote:
>> On Fri, 11 Oct 2019, @lbutlr wrote:
>> 
> Oct 09 16:02:50 imap-login: Info: Aborted login (auth failed, 5 attempts 
> in 33 secs): user=, xx.xx.xx.xx, PLAIN, TLS
>>> 
>>> This turns out to have been caused by the MUA attempting to connect to
>>> port 25 (despite clearly showing port 587 in the MUA settings).  Thanks
>>> to Mac/iOS account syncing, merely trying to change the port never
>>> seemed to work, but removing the account entirely and recreating it got
>>> it to connect to port 587 as configured.
>> 
>> Yes, MacOSX Mail.app seems to bumble around, even ignoring your
>> port settings to find the "correct" configuration.  (This happens,
>> for example, when there is a transient network problem).  You need to
>> disable "Automatically manage connections" to stop these mail readers
>> from wandering around and strictly use your settings.
> 
> There is no such setting in iOS or iPadOS though, and setting the explicit 
> port for SMTP and.or IMAP advanced settings didn’t change the port it 
> actually tried connecting go until I removed the account and re-added it.
> 
> No problems on iOS 12 or macOS 10.14 so far.

I encounter this issue on 10.14 this week, so it is present (with account using 
automatic server settings).

Re: lmtp and virtual users

[Jean-Daniel via dovecot]

You set ‘auth_bind' to ‘no' and  and you make sure ‘dn’ and ‘dnpass’ are 
properly configured with a user with enough privileges to read users passwords.

And also, you make sure your pass_attrs contains a password attributes 
(containing the user password hash).


> Le 2 oct. 2019 à 19:33, David Wells - Alfavinil S.A. via dovecot 
>  a écrit :
> 
> Is there anywhere an example of how this would be setup? I understand the use 
> of a service account which I already setup but I can't figure out how to use 
> this service account to retrieve information and authenticate users.
> 
> Thanks!
> Best regards,
> David Wells.
> 
> 
> El 02/10/2019 a las 04:29, Aki Tuomi escribió:
>> 
>> On 1.10.2019 17.33, David Wells - Alfavinil S.A. via dovecot wrote:
>>> Good morning.
>>> 
>>> I was just reading 
>>> https://wiki.dovecot.org/AuthDatabase/LDAP/PasswordLookups 
>>>  and found the 
>>> following statement
 When using LDA  and static userdb, deliver 
 can check if destination user exists. With auth binds this check isn't 
 possible.
>>> 
>>> Is this still relevant? Is there a workaround? It seems like using dovecots 
>>> lmtp in an active directory environment is not possible, is this correct?
>>> 
>> You cannot check user existence with auth binds because auth bind requires 
>> user credentials.
>> 
>> This is why I suggested you use a "service user" in LDAP to perform the 
>> database lookups instead of auth binds. You can still authenticate your 
>> users using kerberos.
>> 
>> Aki
>> 
> 

Re: TLS not working with iOS beta?

[Jean-Daniel via dovecot]

> Le 4 sept. 2019 à 21:35, Jean-Daniel via dovecot  a 
> écrit :
> 
>> 
>> Le 4 sept. 2019 à 20:11, Henrik Johansson via dovecot  
>> a écrit :
>> 
>> Hi,
>> 
>> Have anyone else experienced problems using Dovecot with the mail app in 
>> beta releases of iOS/iPadOS 13?
>> 
>> TLS is failing for my, it have worked fine for years and I am on the latest 
>> Dovecot version now, it works fine with older clients but not with the ones 
>> upgraded:
>> 
>> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x10, ret=1: before/accept 
>> initialization
>> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept 
>> initialization
>> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv2/v3 read 
>> client hello A
>> Sep 04 19:49:16 imap-login: Debug: SSL alert: where=0x4008, ret=552: fatal 
>> handshake failure
>> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x2002, ret=-1: error
>> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x2002, ret=-1: error
>> Sep 04 19:49:16 imap-login: Debug: SSL error: SSL_accept() failed: 
>> error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
>> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x2002, ret=-1: error
>> Sep 04 19:49:16 imap-login: Debug: SSL error: SSL_accept() failed: 
>> error:140800FF:SSL routines:ssl3_accept:unknown state
>> Sep 04 19:49:16 imap-login: Info: Disconnected (no auth attempts in 0 secs): 
>> user=<>, rip=11.22.33.44, lip=11.22.33.44, TLS handshaking: SSL_accept() 
>> failed: error:140800FF:SSL routines:ssl3_accept:unknown state, 
>> session=
>> 
>> Working client:
>> 
>> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x10, ret=1: before/accept 
>> initialization
>> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept 
>> initialization
>> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv2/v3 read 
>> client hello A
>> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read 
>> client hello A
>> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write 
>> server hello A
>> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write 
>> certificate A
>> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write key 
>> exchange A
>> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write 
>> server done A
>> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data
>> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read 
>> client certificate A
>> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read 
>> client key exchange A
>> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read 
>> client key exchange A
>> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read 
>> client key exchange A
>> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read 
>> client key exchange A
>> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read 
>> client key exchange A
>> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read 
>> certificate verify A
>> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read 
>> finished A
>> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read 
>> finished A
>> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write 
>> change cipher spec A
>> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write 
>> finished A
>> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data
>> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation 
>> finished successfully
>> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation 
>> finished successfully
>> Sep 04 19:58:03 imap-login: Info: Login: user=, method=LOGIN, 
>> rip=11.22.33.44, lip=11.22.33.44, mpid=28781, TLS, TLSv1.2 with cipher 
>> DHE-RSA-AES256-GCM-SHA384 (256/256 bits), session=
>> 
>> 
>> Config:
>> 
>> # egrep -v "^#|^$" 10-ssl.conf 10-auth.conf
>> 10-ssl.conf:ssl = required
>> 10-ssl.conf:ssl_cert = > 10-ssl.conf:ssl_key = > 10-ssl.conf:ssl_dh = > 10-ssl.conf:ssl_min_protocol = TLSv1.1
>> 10-ssl.conf:ssl_cipher_list = 
>> ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH
>> 10-auth.conf:disable_plaintext_auth = yes
>> 10-auth.conf

Re: TLS not working with iOS beta?

[Jean-Daniel via dovecot]

> Le 4 sept. 2019 à 20:11, Henrik Johansson via dovecot  a 
> écrit :
> 
> Hi,
> 
> Have anyone else experienced problems using Dovecot with the mail app in beta 
> releases of iOS/iPadOS 13?
> 
> TLS is failing for my, it have worked fine for years and I am on the latest 
> Dovecot version now, it works fine with older clients but not with the ones 
> upgraded:
> 
> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x10, ret=1: before/accept 
> initialization
> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept 
> initialization
> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv2/v3 read 
> client hello A
> Sep 04 19:49:16 imap-login: Debug: SSL alert: where=0x4008, ret=552: fatal 
> handshake failure
> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x2002, ret=-1: error
> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x2002, ret=-1: error
> Sep 04 19:49:16 imap-login: Debug: SSL error: SSL_accept() failed: 
> error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
> Sep 04 19:49:16 imap-login: Debug: SSL: where=0x2002, ret=-1: error
> Sep 04 19:49:16 imap-login: Debug: SSL error: SSL_accept() failed: 
> error:140800FF:SSL routines:ssl3_accept:unknown state
> Sep 04 19:49:16 imap-login: Info: Disconnected (no auth attempts in 0 secs): 
> user=<>, rip=11.22.33.44, lip=11.22.33.44, TLS handshaking: SSL_accept() 
> failed: error:140800FF:SSL routines:ssl3_accept:unknown state, 
> session=
> 
> Working client:
> 
> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x10, ret=1: before/accept 
> initialization
> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept 
> initialization
> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv2/v3 read 
> client hello A
> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read 
> client hello A
> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write 
> server hello A
> Sep 04 19:57:58 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write 
> certificate A
> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write key 
> exchange A
> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write 
> server done A
> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data
> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read 
> client certificate A
> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read 
> client key exchange A
> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read 
> client key exchange A
> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read 
> client key exchange A
> Sep 04 19:58:01 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read 
> client key exchange A
> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read 
> client key exchange A
> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read 
> certificate verify A
> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read 
> finished A
> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read 
> finished A
> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write 
> change cipher spec A
> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write 
> finished A
> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data
> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation 
> finished successfully
> Sep 04 19:58:03 imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation 
> finished successfully
> Sep 04 19:58:03 imap-login: Info: Login: user=, method=LOGIN, 
> rip=11.22.33.44, lip=11.22.33.44, mpid=28781, TLS, TLSv1.2 with cipher 
> DHE-RSA-AES256-GCM-SHA384 (256/256 bits), session=
> 
> 
> Config:
> 
> # egrep -v "^#|^$" 10-ssl.conf 10-auth.conf
> 10-ssl.conf:ssl = required
> 10-ssl.conf:ssl_cert =  10-ssl.conf:ssl_key =  10-ssl.conf:ssl_dh =  10-ssl.conf:ssl_min_protocol = TLSv1.1
> 10-ssl.conf:ssl_cipher_list = 
> ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH
> 10-auth.conf:disable_plaintext_auth = yes
> 10-auth.conf:auth_mechanisms = login
> 10-auth.conf:!include auth-system.conf.ext
> 
> # dovecot --version
> 2.3.7.2 (3c910f64b)

Just a wild guess as I didn’t try to configure Mail on Catalina yet, but it 
looks like your server only supports ‘DHE-RSA…’ ciphers.
I think that modern systems prefers using ECDHE key exchange and would not be 
surprise if iOS requires it.

What version of OpenSSL are you using ?

Re: [Bug] Sieve vacation :addresses match only case-sensitive?

[Jean-Daniel via dovecot]

> Le 4 sept. 2019 à 19:37, Roger Klorese via dovecot  a 
> écrit :
> 
> 
> 
> On Wed, Sep 4, 2019 at 8:25 AM Philipp Faeustlin via dovecot 
> mailto:dovecot@dovecot.org>>
> Further investigation showed me that it has to be a bug.
> 
> I tested with Dovecot 2.2.36.3 (a7d78f5a2), Pigeonhole version 0.4.24 
> (5a7e9e62):
> 
> In this version the additional addresses in vacation :addresses 
> ["t...@example.com "] are handled case-insensitive.
> 
> In the new version: Dovecot 2.3.7.2 (3c910f64b), Pigeonhole version 
> 0.5.7.2 (7372921a) installed via https://repo.dovecot.org/ 
> , (same sieve, 
> same configuration) these addresses are handled case-sensitive.
> 
> The case-sensitive matching of mail addresses, doesn't make any sense to me.
> 
> Could someone confirm this behavior?
> 
> 
> Isn’t RFC-compliant behavior to treat the local part as case-sensitive and 
> the domain-part as case-insensitive?

It is not recommended to rely on local-part case, but it is indeed 
case-sensitive.

And this is to avoid such issues that postfix supports address 
cleanup/canonicalisation before forwarding mails to dovecot.

--
RFC 5321:

"Local-part = Dot-string / Quoted-string ; MAY be case-sensitive
[…]
While the above definition for Local-part is relatively permissive, for maximum 
interoperability, a host that expects to receive mail SHOULD avoid defining 
mailboxes where the Local-part requires (or uses) the Quoted-string form or 
where the Local-part is case-sensitive."
 

Re: 2.3.7 + stats

[Jean-Daniel via dovecot]

Some of the behaviours you observe may be due to the same bug I encountered:

https://dovecot.org/pipermail/dovecot/2019-July/116475.html

Especially, regarding the ‘successful' field for auth, which does not exists 
and is really named ‘success', and which is never set anyway.


> Le 15 août 2019 à 23:57, Matt Bryant via dovecot  a 
> écrit :
> 
> Is there any additional documentation/information around the new stats module.
> 
> Have added some metrics just to see what they produce
> 
> ##
> ## Metrics
> ###
> 
> metric imap {
> event_name = imap_command_finished
> #source_location = example.c:123
> 
> #categories =
> 
> fields = name args running_usecs bytes_in bytes_out
> 
> #filter {
> #field_key = wildcard
> #}
> }
> 
> metric sql {
> event_name = sql_query_finished
> }
> 
> metric auth {
> event_name = auth_request_finished
> fields = user transport error successful
> }
> 
> and get the following
> 
> 
> [root@stargate dovecot]# doveadm stats dump
> metric_namefieldcountsumminmaxavg medianstddev
> %95
> imapduration370200790449913062955249 5426768.922068   
>  16436817.3760026465
> imapname3700000.0000.000
> imapargs00000.0000.000
> imaprunning_usecs370200786533081 629551275426663.05
> 199116436816.7660026329
> imapbytes_in3705366217314.508 19.0435
> imapbytes_out37021199710941517 5729.654153760.89  
>   2082
> sqlduration182899199123051610.61 1660377.36
> 2305
> authduration122604698081467079879 2170581.67847730
> 2457811.237079879
> authuser120000.0000.000
> authtransport120000.0000.00 0
> autherror00000.0000.000
> authsuccessful00000.0000.00 0
> 
> the main wiki page on stats/events doesnt really hold much detail whats 
> stores for each event the above fields dont make much sense
> 
> and top no longer works out of the box
> 
> [root@stargate dovecot]# doveadm stats top
> 
> usage: doveadm [-Dv] [-f ] stats  []
>   dump [-s ] [-r] [-f ]
> 
> 
> has is been removed ? do you need to specify something additional now ???
> 
> 
> rgds
> 
> 
> Matt
> 
> 
> 

Re: Solr, Dovecot & macOS / iOS

[Jean-Daniel via dovecot]

> Le 13 août 2019 à 14:53, Sami Ketola  a écrit :
> 
> 
> 
>> On 13 Aug 2019, at 15.37, Jean-Daniel via dovecot > <mailto:dovecot@dovecot.org>> wrote:
>> 
>> 
>> 
>>> Le 13 août 2019 à 14:16, Sami Ketola via dovecot >> <mailto:dovecot@dovecot.org>> a écrit :
>>> 
>>> 
>>> 
>>>> On 13 Aug 2019, at 14.58, James Brown via dovecot >>> <mailto:dovecot@dovecot.org>> wrote:
>>>> 
>>>> I’m thinking of getting Solr working with my Dovecot server. Server is new 
>>>> 6-core Mac Mini, mail store of over 1/2 TB. Mailboxes with 100s of 
>>>> thousands of messages.
>>>> 
>>>> But I’m not sure if:
>>>> 
>>>> a) it will make enough of a difference and
>>> 
>>> Choose mailbox format wisely. sdbox preferred unless HFS+ has problems with 
>>> 100s of thousands of small files in same directory. If so, then use mdbox 
>>> with periodic purges.
>>> 
>>>> 
>>>> b) does Mail.app and other mail clients on Macs or iOS devices perform 
>>>> searches on their local copy of mail or does it just send a search request 
>>>> to the server?
>>> 
>>> None of the apple devices use IMAP SEARCH. They ALL maintain and use their 
>>> own local search database on the device. Also they seem to refresh the 
>>> database every now and then redownloading all emails.
>> 
>> Do you have a source for that. My experience is that without server search 
>> support, iOS is very slow at returning result. Moreover, it keep only latest 
>> messages and never download message until you read them.
> 
> I'm a apple device user myself. I have couple of iPhones, couple of iPads, 
> couple if MacBooks and Mail.app on any of them is not using IMAP SEARCH.
> And I cannot find any configuration option to enable it. Only spotlight index 
> is used. On Mac OS Mail.App seems to store the indexed data to:
> 
> samik@samikworkmac:~>ls -1 Library/Mail/V6/MailData/Envelope\ Index*
> Library/Mail/V6/MailData/Envelope Index
> Library/Mail/V6/MailData/Envelope Index-shm
> Library/Mail/V6/MailData/Envelope Index-wal
> 
> if those files are removed or spotlight search for mails is disabled Mail.App 
> can't find anything anymore. It does not fall back to IMAP SEARCH.
> 

My question was more about iOS. I know that macOS Mail does not rely on any way 
on remote indexing and has it’s own local index, but as it also store all 
messages locally, it’s an easy requirement. For iOS that only download messages 
meta-data by default, I was not so sure. 

I’m accessing my mail server using Apple devices only, and see some imap SEARCH 
requests in dovecot stats, but can’t figure out where they came from though. So 
you may be right.

Re: Solr, Dovecot & macOS / iOS

[Jean-Daniel via dovecot]

> Le 13 août 2019 à 14:16, Sami Ketola via dovecot  a 
> écrit :
> 
> 
> 
>> On 13 Aug 2019, at 14.58, James Brown via dovecot  
>> wrote:
>> 
>> I’m thinking of getting Solr working with my Dovecot server. Server is new 
>> 6-core Mac Mini, mail store of over 1/2 TB. Mailboxes with 100s of thousands 
>> of messages.
>> 
>> But I’m not sure if:
>> 
>> a) it will make enough of a difference and
> 
> Choose mailbox format wisely. sdbox preferred unless HFS+ has problems with 
> 100s of thousands of small files in same directory. If so, then use mdbox 
> with periodic purges.
> 
>> 
>> b) does Mail.app and other mail clients on Macs or iOS devices perform 
>> searches on their local copy of mail or does it just send a search request 
>> to the server?
> 
> None of the apple devices use IMAP SEARCH. They ALL maintain and use their 
> own local search database on the device. Also they seem to refresh the 
> database every now and then redownloading all emails.

Do you have a source for that. My experience is that without server search 
support, iOS is very slow at returning result. Moreover, it keep only latest 
messages and never download message until you read them.

Re: Auth driver

[Jean-Daniel via dovecot]

I’m not familiar with dovecot code, but as I’m using ldap, so I know that the 
ldap authdb support is not part of dovecot-core package, and is provided as a 
plugin in an extra package.

And a quick look at the libauthdb_ldap.so file (installed by the dovecot-ldap 
package) shows me these symbols: authdb_ldap_init / passdb_ldap_plugin

So I guess that you don’t have to search very far to find such examples.


> Le 9 août 2019 à 14:08, Riccardo Paolo Bestetti via dovecot 
>  a écrit :
> 
> (resending to the list; I apologize, I'm not using my usual email client)
> 
> Hello,
> 
> That's actually great news. The perspective of working in-tree didn't make me 
> particularly happy.
> 
> Could you point me to any documentation or examples? While I can find many 
> plugins in the repo and around the Internet, I could find none which add 
> authdb drivers.
> 
> Best Regards,
> Riccardo P. Bestetti
> 
> 
> 
> 
> 
> 
> Da: Aki Tuomi 
> 
> Inviato: venerdì 9 agosto 2019 13:56
> 
> A: Riccardo Paolo Bestetti ; dovecot@dovecot.org 
> 
> 
> Oggetto: Re: Auth driver
> 
> 
> 
> 
> 
> 
> On 9.8.2019 14.51, Riccardo Paolo Bestetti via dovecot wrote:
> 
> > Greetings!
> 
> >
> 
> > I'm planning to implement a new auth driver. It's going to be, in concept, 
> > similar to the Lua and CheckPassword drivers, in that it allows an user 
> > program to carry out the authentication and user enumeration steps.
> 
> 
> 
> If you do this, please make it as 3rd party repository. Dovecot auth
> 
> supports plugins.
> 
> 
> 
> Aki

Re: submission configuration issues

[Jean-Daniel via dovecot]

My configuration has 2 listeners. The default one (submission) on port 587 
(which does not appear on "dovecot -n » output as it is the default)

And a second one on port 465 that is configured to use submission over TLS 
(note the ssl = yes in the configuration and the ’s’ at the end of the name: 
submissions )

According to RFC8314 (https://tools.ietf.org/html/rfc8314), this is now the 
recommended setting:

«  In brief, this memo now recommends that:

…

   o  Connections to Mail Submission Servers and Mail Access Servers be
  made using "Implicit TLS" (as defined below), in preference to
  connecting to the "cleartext" port and negotiating TLS using the
  STARTTLS command or a similar command.

» 



> Le 27 juil. 2019 à 22:39, Bob Gustafson via dovecot  a 
> écrit :
> 
> service submission-login {
>   inet_listener submissions {
> haproxy = no
> port = 465
> reuse_port = no
> ssl = yes
>   }
> }
> 
> Shouldn't the port be 587 here?
> 
> My config file looks like:
> 
> service submission-login {
>   inet_listener submission {
> #port = 587
>   }
> }
> 
> The # comment must also mean something..
> 
> On 7/27/19 3:21 PM, Jean-Daniel via dovecot wrote:
>> 
>> 
>>> Le 27 juil. 2019 à 14:30, Stephan Bosch  a écrit :
>>> 
>>> On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote:
>>>> Hello,
>>>> 
>>>> I'm having trouble configuring the submission proxy.
>>>> 
>>>> I have configured the submission service as follow:
>>>> 
>>>> submission_host = smtp.example.com
>>>> submission_relay_host = localhost
>>>> submission_relay_port = 8587
>> 
>> 
>>> Le 27 juil. 2019 à 14:30, Stephan Bosch  a écrit :
>>> 
>>> On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote:
>>>> Hello,
>>>> 
>>>> I'm having trouble configuring the submission proxy.
>>>> 
>>>> I have configured the submission service as follow:
>>>> 
>>>> submission_host = smtp.example.com
>>>> submission_relay_host = localhost
>>>> submission_relay_port = 8587
>>>> submission_relay_rawlog_dir = /var/log/dovecot/
>>>> submission_relay_trusted = yes
>>>> 
>>>> My main issue is that until I login, dovecot-submission won't connect to 
>>>> the backend and query the capabilities and so won't report the right 
>>>> capabilities.
>>>> 
>>>> That mean that the first EHLO message don't get the right capabilities 
>>>> list.
>>>> 
>>>> "
>>>> EHLO example.com
>>>> 
>>>> 250-smtp.example.com
>>>> 250-8BITMIME
>>>> 250-AUTH PLAIN LOGIN
>>>> 250-BURL imap
>>>> 250-CHUNKING
>>>> 250-ENHANCEDSTATUSCODES
>>>> 250-SIZE
>>>> 250 PIPELINING
>>>> "
>>>> 
>>>> This list don't contains VRFY, DNS, and SIZE is not specified (all of 
>>>> these is present in backend EHLO response).
>>>> After login, if I send an new EHLO command, everything is properly 
>>>> reported. The raw log shows that unlike what the documentation says,
>>>> dovecot don't try to connect to the backend until the user is properly 
>>>> logged.
>>>> 
>>>> In my raw log I show that after I logged in dovecot-submission, the later 
>>>> open a connection to the backend and send a X-CLIENT command.
>>>> 
>>>> 
>>>> Now, if I try to force the capabilities by using:
>>>> 
>>>> submission_backend_capabilities = VRFY 8BITMIME DSN
>>>> 
>>>> dovecot properly reports all SMTP capabilities in the first EHLO response, 
>>>> but it completely stops emitting X-CLIENT command to the backend
>>>> and try to simply forward the command without authentication, which result 
>>>> in postfix rejecting the command with an unauthorized user error.
>>>> 
>>>> What is wrong with my configuration ?
>>>> Thanks.
>>> 
>>> Can you send us your complete configuration (output from `dovecot -n`)?
>> 
>> Yes (see below).
>> 
>> Some additional information:
>> 
>> ===
>> 
>> When I connect directly to dovecot-submission using nc and send an EHLO 
>> command, I got the following result (the SIZE is configured in dovecot 
>> config, that

Re: submission configuration issues

[Jean-Daniel via dovecot]

> Le 27 juil. 2019 à 23:13, Stephan Bosch  a écrit :
> 
> 
> 
> On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote:
>> Hello,
>> 
>> I'm having trouble configuring the submission proxy.
>> 
>> I have configured the submission service as follow:
>> 
>> submission_host = smtp.example.com
>> submission_relay_host = localhost
>> submission_relay_port = 8587
>> submission_relay_rawlog_dir = /var/log/dovecot/
>> submission_relay_trusted = yes
>> 
>> My main issue is that until I login, dovecot-submission won't connect to the 
>> backend and query the capabilities and so won't report the right 
>> capabilities.
> 
> That is true and expected. No connection to the relay server is made until 
> the user is logged in.
> 
>> That mean that the first EHLO message don't get the right capabilities list.
>> 
>> "
>> EHLO example.com
>> 
>> 250-smtp.example.com
>> 250-8BITMIME
>> 250-AUTH PLAIN LOGIN
>> 250-BURL imap
>> 250-CHUNKING
>> 250-ENHANCEDSTATUSCODES
>> 250-SIZE
>> 250 PIPELINING
>> "
>> 
>> This list don't contains VRFY, DNS, and SIZE is not specified (all of these 
>> is present in backend EHLO response).
>> After login, if I send an new EHLO command, everything is properly reported. 
>> The raw log shows that unlike what the documentation says,
>> dovecot don't try to connect to the backend until the user is properly 
>> logged.
> Oh, then we need to adjust the documentation. This is normal behavior.

This is in the default 20-submission.conf file:

# By default, the submission service first connects to the relay server to
# determine the support for such capabilities before sending the initial EHLO
# reply to the client. If the list of capabilities returned by the relay server
# is somehow unreliable or it is undesirable to start the connection to the
# relay server before the first mail transaction is started, the backend
# capabilities can be configured explicitly using the
# submission_backend_capabilities setting.
…
#submission_backend_capabilities =

Re: submission configuration issues

[Jean-Daniel via dovecot]

> Le 27 juil. 2019 à 14:30, Stephan Bosch  a écrit :
> 
> On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote:
>> Hello,
>> 
>> I'm having trouble configuring the submission proxy.
>> 
>> I have configured the submission service as follow:
>> 
>> submission_host = smtp.example.com
>> submission_relay_host = localhost
>> submission_relay_port = 8587


> Le 27 juil. 2019 à 14:30, Stephan Bosch  a écrit :
> 
> On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote:
>> Hello,
>> 
>> I'm having trouble configuring the submission proxy.
>> 
>> I have configured the submission service as follow:
>> 
>> submission_host = smtp.example.com
>> submission_relay_host = localhost
>> submission_relay_port = 8587
>> submission_relay_rawlog_dir = /var/log/dovecot/
>> submission_relay_trusted = yes
>> 
>> My main issue is that until I login, dovecot-submission won't connect to the 
>> backend and query the capabilities and so won't report the right 
>> capabilities.
>> 
>> That mean that the first EHLO message don't get the right capabilities list.
>> 
>> "
>> EHLO example.com
>> 
>> 250-smtp.example.com
>> 250-8BITMIME
>> 250-AUTH PLAIN LOGIN
>> 250-BURL imap
>> 250-CHUNKING
>> 250-ENHANCEDSTATUSCODES
>> 250-SIZE
>> 250 PIPELINING
>> "
>> 
>> This list don't contains VRFY, DNS, and SIZE is not specified (all of these 
>> is present in backend EHLO response).
>> After login, if I send an new EHLO command, everything is properly reported. 
>> The raw log shows that unlike what the documentation says,
>> dovecot don't try to connect to the backend until the user is properly 
>> logged.
>> 
>> In my raw log I show that after I logged in dovecot-submission, the later 
>> open a connection to the backend and send a X-CLIENT command.
>> 
>> 
>> Now, if I try to force the capabilities by using:
>> 
>> submission_backend_capabilities = VRFY 8BITMIME DSN
>> 
>> dovecot properly reports all SMTP capabilities in the first EHLO response, 
>> but it completely stops emitting X-CLIENT command to the backend
>> and try to simply forward the command without authentication, which result 
>> in postfix rejecting the command with an unauthorized user error.
>> 
>> What is wrong with my configuration ?
>> Thanks.
> 
> Can you send us your complete configuration (output from `dovecot -n`)?

Yes (see below).

Some additional information:

===

When I connect directly to dovecot-submission using nc and send an EHLO 
command, I got the following result (the SIZE is configured in dovecot config, 
that’s why it is properly announced), but no raw_log are generated at all.

$ nc smtp.example.com 587

220 smtp.example.com Dovecot ready.
EHLO mydomain.com
250-smtp.example.com
250-8BITMIME
250-AUTH 
250-BURL imap
250-CHUNKING
250-ENHANCEDSTATUSCODES
250-SIZE 41943040
250-STARTTLS
250 PIPELINING
QUIT
221 2.0.0 Bye

===

Ditto if I use openssl s_client -starttls smtp -crlf -connect 
smtp.example.com:587 and send the EHLO after STARTTLS.

===

For the record, here is the result of a direct connect to postfix:

$ nc 127.0.0.1 8587
220 smtp.example.com ESMTP Postfix
EHLO example.com
250-smtp.example.com
250-PIPELINING
250-SIZE 41943040
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT LOGIN DESTADDR DESTPORT
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8

===

And here is the content of the row logs when a mail is sent.

 rawlog.in

1564258521.813430 220 smtp.example.com ESMTP Postfix
1564258521.814206 250-smtp.example.com
1564258521.814206 250-PIPELINING
1564258521.814206 250-SIZE 41943040
1564258521.814206 250-VRFY
1564258521.814206 250-ETRN
1564258521.814206 250-STARTTLS
1564258521.814206 250-AUTH PLAIN LOGIN
1564258521.814206 250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT LOGIN 
DESTADDR DESTPORT
1564258521.814206 250-ENHANCEDSTATUSCODES
1564258521.814206 250-8BITMIME
1564258521.814206 250-DSN
1564258521.814206 250 SMTPUTF8
1564258521.848159 220 smtp.example.com ESMTP Postfix
1564258521.849506 250-smtp.example.com
1564258521.849506 250-PIPELINING
1564258521.849506 250-SIZE 41943040
1564258521.849506 250-VRFY
1564258521.849506 250-ETRN
1564258521.849506 250-STARTTLS
1564258521.849506 250-AUTH PLAIN LOGIN
1564258521.849506 250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT LOGIN 
DESTADDR DESTPORT
1564258521.849506 250-ENHANCEDSTATUSCODES
1564258521.849506 250-8BITMIME
1564258521.849506 250-DSN
1564258521.849506 250 SMTPUTF8
1564258521.854093 250 2.1.0 Ok
1564258521.909487 250 2.1.5 Ok
1564258521.983093 354 End data with .
1564258522.115312 250 2.0.0 Ok: queued as DDBCCD53B

 rawlog.out

1564258521.813739 EHLO smtp.example.com
1564258521.846054 XCLIENT HELO=[10.188.153.106] PROTO=ESMTP LOGIN=info 
PORT=47564 ADDR=46.193.33.66
1564258521.848701 EHLO smtp.example.com
1564258521.850122 MAIL FROM: AUTH=info
1564258521.889896 RCPT TO:
1564258521.981094 DATA
1564258521.983757 Received: from [10.188.153.106] ([46.193.33.66])

Re: Purpose of stats-writer and why doveadm try to open it to dump stats ?

[Jean-Daniel via dovecot]

> Le 14 juil. 2019 à 11:58, Reio Remma  a écrit :
> 
> On 14.07.2019 10:10, Jean-Daniel via dovecot wrote:
>> Hello,
>> 
>> I want to monitor dovecot stats, and so I have an exporter process that run 
>> with limited rights.
>> The monitoring user has only access to /var/run/dovecot/stats-reader and it 
>> works fine.
>> Doveadm stats dump returns the list of all stats as expected.
>> 
>> But each time I run doveadm stats dump, it logs the following error:
>> 
>> Error: net_connect_unix(/var/run/dovecot/stats-writer) failed: Permission 
>> denied
>> 
>> So what is the purpose of the stats-writer socket, and why doveadm try to 
>> open it to simply dump stats ?
>> Is it really something it needs and I should update my user permissions or 
>> is it a doveadm bug ?
>> 
> 
> Hello!
> 
> Depending on the system you're running on, there may be SELinux etc. doing 
> its work.
> 

I know why stats-writer is not accessible, this is on purpose (doveadm run with 
a uid that explicitly don’t have access to stats-writer).

What I want to know is why does doveadm even try to open it to simply dump the 
stats.

Purpose of stats-writer and why doveadm try to open it to dump stats ?

[Jean-Daniel via dovecot]

Hello,

I want to monitor dovecot stats, and so I have an exporter process that run 
with limited rights. 
The monitoring user has only access to /var/run/dovecot/stats-reader and it 
works fine.
Doveadm stats dump returns the list of all stats as expected.

But each time I run doveadm stats dump, it logs the following error:

Error: net_connect_unix(/var/run/dovecot/stats-writer) failed: Permission denied

So what is the purpose of the stats-writer socket, and why doveadm try to open 
it to simply dump stats ? 
Is it really something it needs and I should update my user permissions or is 
it a doveadm bug ?