Re: Upgrading to v2.3.X breaks ssl san?

[Aki Tuomi via dovecot]

On 8.8.2019 21.31, Hauke Fath via dovecot wrote:
> On Wed, 7 Aug 2019 20:24:13 +0300 (EEST), Aki Tuomi via dovecot wrote:
>>> i thought ssl_ca is where to put the intermediate cert?
> Well, it surely worked that way until v2.3...
>
>> (Sorry for duplicate mail, keyboard acted up...)
>>
>> No, that has always been a mistake and it was fixed in 2.3. Our SSL 
>> pages in documentation & wiki have always recommended concatenating 
>> the intermediates with the cert.
> Aki, after the issue came up last time 
> ,
>  
> you appeared to have changed your mind? What happened?
>
> Cheerio,
> Hauke
>

I don't see any change of mind here.

As you can see in the quote you mentioned,

> > Including ssl_ca with cert is not actually a good idea, but perhaps
this should
> > indeed be mentioned in the upgrading page. Not a regression in any
case.

Aki

Auth driver

[Riccardo Paolo Bestetti via dovecot]

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.
The rationale is that such a solution would provide better decoupling between 
Dovecot and the user authentication and enumeration logic. Existing integrated 
logic (auth/ directory in the source tree) is, even encompassing a great number 
of common use cases, ultimately inflexible. Writing custom drivers implementing 
logic, while being a solution to the inflexibility problem, is clearly not what 
drivers were engineered for: for one they don't support dynamic loading, making 
it necessary to recompile Dovecot to make changes, which is unacceptable in 
many situations, e.g.  when using a packaged or containerized version of the 
software.
In this email, I intend to explain what characteristics my driver will have and 
why it solves the proposed problem better than existing code (such as 
CheckPassword, Lua and proxy), in the hope to get useful feedback and I will 
pose some technical questions to which I could not find definitive answers by 
myself yet.

These are going to be the characteristics of my driver (with particular 
emphasis to the differences to the existing drivers):
- It is going to be a completely generic mechanism exposing all funcionality of 
Dovecot's interface, both password check and enumeration, and will fully 
support authentication methods with continuations.
- It is going to be performant, communicating with external programs through 
sockets (unix or inet).
- It is going to communicate using a simple, dynamic-schema, well-understood 
protocol, which is probably going to be JSON, being very easy to generate and 
parse.

This is why the existing drivers do not already provide what I described:
- CheckPassword is heavy (fork & 2*exec), and it's generally a mess, having 
initially been provided as a compatibility feature and having then been hacked 
to support additional functionality; it's architecturally unfeasable to support 
continuations with it and anyway any further extension will probably make it 
explode :)
- Lua works but it's limited, in that it dictates a language and also dictates 
that the auth logic should run on the same server as Dovecot (and under 
Dovecot's control). It also doesn't seem to support plain password checks, but 
only user-password enumeration, making it non-generic (at least this is what 
can be inferred from the documentation and examples.)
- Other possible solutions, such as (mis)using the proxy driver to communicate 
with an external program are not well documented and nothing guarantees the 
proxy protocol will not change anyway, being an internal feature.

And now, the technical questions. I know these could be answered by reading the 
code, which is something I'm doing, but I'm finding some architectural details 
quite difficult to grasp due to their complexity:
- From what I gather from [1], auth-worker processes only process a single 
request before being killed from auth. Would setting service_count to something 
different cause auth-workers to be reused or would it just leak the 
auth-workers? In the first case, is the preinit of the auth driver repeated, or 
is the existing instance of the auth driver reused? You could also point me to 
the relevant code sections which start, keep track of and initialize 
auth-workers.
- How does a driver specify what to run in an auth-worker as opposed to in the 
auth process? (This is strongly related to the first question, and maybe it is 
more general, so you may want to answer this one first.)

Please, feel free to only answer parts of my email. Any input on any of the 
matters is very welcome.

Best regards,
Riccardo P. Bestetti

[1] https://wiki.dovecot.org/Services#auth-worker

Re: Auth driver

[Aki Tuomi via dovecot]

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

Auth driver

[Riccardo Paolo Bestetti via dovecot]

(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

Should dovecot not be using different logging facility and severity levels?

[Marc Roos via dovecot]

Should dovecot not be using different severity levels like auth.warn? On 
my system everything goes to loglevel info:


lev_info:Aug  9 16:18:24 mail03 dovecot: imap-login: Aborted login (auth 
failed, 1 attempts in 2 secs): user=, method=PLAIN, rip=x.x.x.x, 
lip=x.x.x.x, TLS, session=
lev_info:Aug  9 16:18:29 mail03 dovecot: auth-worker(28656): 
pam(krinfo,188.206.104.240,): unknown user
lev_info:Aug  9 16:18:50 mail03 dovecot: imap-login: Aborted login (auth 
failed, 1 attempts in 25 secs): user=, method=PLAIN, rip=x.x.x.x, 
lip=x.x.x.x, TLS: Disconnected, session=
lev_info:Aug  9 16:18:53 mail03 dovecot: auth-worker(28656): 
pam(krinfo,188.206.104.240,): unknown user
lev_info:Aug  9 16:19:01 mail03 dovecot: imap-login: Aborted login (auth 
failed, 1 attempts in 8 secs): user=, method=PLAIN, rip=x.x.x.x, 
lip=x.x.x.x, TLS, session=
lev_info:Aug  9 16:19:13 mail03 dovecot: auth-worker(28656): 
pam(krinfo,188.206.104.240,): unknown user
lev_info:Aug  9 16:19:15 mail03 dovecot: imap-login: Aborted login (auth 
failed, 1 attempts in 2 secs): user=, method=PLAIN, rip=x.x.x.x, 
lip=x.x.x.x, TLS, session=
lev_info:Aug  9 16:19:24 mail03 dovecot: auth-worker(28656): 
pam(krinfo,188.206.104.240,): unknown user
lev_info:Aug  9 16:19:26 mail03 dovecot: imap-login: Aborted login (auth 
failed, 1 attempts in 2 secs): user=, method=PLAIN, rip=x.x.x.x, 
lip=x.x.x.x, TLS, session=
lev_info:Aug  9 16:19:27 mail03 dovecot: auth-worker(28656): 
pam(krinfo,188.206.104.240,): unknown user
lev_info:Aug  9 16:19:29 mail03 dovecot: imap-login: Aborted login (auth 
failed, 1 attempts in 2 secs): user=, method=PLAIN, rip=x.x.x.x, 
lip=x.x.x.x, TLS, session=
lev_info:Aug  9 16:19:47 mail03 dovecot: auth-worker(29664): 
pam(krinfo,188.206.104.240,<14Pb3a+Pih68zmjw>): unknown user
lev_info:Aug  9 16:19:49 mail03 dovecot: imap-login: Aborted login (auth 
failed, 1 attempts in 2 secs): user=, method=PLAIN, rip=x.x.x.x, 
lip=x.x.x.x, TLS, session=<14Pb3a+Pih68zmjw>
lev_info:Aug  9 16:19:51 mail03 dovecot: auth-worker(29664): 
pam(krinfo,188.206.104.240,<99cO3q+Pix68zmjw>): unknown user
lev_info:Aug  9 16:19:53 mail03 dovecot: imap-login: Aborted login (auth 
failed, 1 attempts in 2 secs): user=, method=PLAIN, rip=x.x.x.x, 
lip=x.x.x.x, TLS, session=<99cO3q+Pix68zmjw>


This is how failed attempts are logged by vsftpd

fac_authpriv:Aug  9 16:24:42 web01 vsftpd[7255]: pam_ldap(vsftpd:auth): 
Authentication failure; user=x
fac_authpriv:Aug  9 16:24:42 web01 vsftpd[7255]: pam_unix(vsftpd:auth): 
authentication failure; logname= uid=0 euid=0 tty=ftp ruser=x 
rhost=x  user=x
fac_ftp:Aug  9 16:24:44 web01 vsftpd[7255]: [x] FAIL LOGIN: Client 
"x.x.x.x"
lev_notice:Aug  9 16:24:42 web01 vsftpd[7255]: pam_ldap(vsftpd:auth): 
Authentication failure; user=x
lev_notice:Aug  9 16:24:42 web01 vsftpd[7255]: pam_unix(vsftpd:auth): 
authentication failure; logname= uid=0 euid=0 tty=ftp ruser=x 
rhost=x  user=x
lev_warn:Aug  9 16:24:44 web01 vsftpd[7255]: [x] FAIL LOGIN: Client 
"x.x.x.x"


Using dovecot-2.2.36-3.el7.x86_64 on CentOS7

Dovecot for imap with LDAP

[Joseph Mays via dovecot]

I am looking at replacing our creaky old courier-imap server, which takes 
authentication and user info from an LDAP database, with dovecot imap. Any 
comments on the wisdom of this choice of action, or anything I should know 
about the setting up before starting to work on it?

What does `iterate_query` for SQL want as output?

[Coy Hile via dovecot]

Hi all,

In an earlier thread, 
https://dovecot.org/pipermail/dovecot/2019-August/116694.html I got a lot of 
useful help about migration. On my older host, everything was static; on the 
newer host, I’m storing user information in Postgres. usernames are of the form 
, say ‘h...@coyhile.com’ as basically a Kerberos principal, and 
authentication and individual lookups work.

My `users` table looks thus:

mail=> \d users
Table "public.users"
  Column  | Type | Modifiers
--+--+---
 username | text | not null
 domain   | text | not null
 password | text | not null

mail=>

and contains, as an example:

 username |   domain|   
password
--+-+---
 h...@coyhile.com | coyhile.com | [REDACTED] 
(1 row)

Naively, I’d expect something this to work for the iteration query:

iterate_query = SELECT username, domain FROM users


But, when I do that, I end up 

doveadm backup -D -A -R -f ssh -i id_rsa.dsync imap01.coyhile.com 
/opt/local/bin/doveadm dsync-server -A
doveadm(h...@coyhile.com@coyhile.com): Info: User no longer exists, skipping
[root@81716ec5-bca4-6d53-ed81-bd1a55d46b4f /tmp]#

Note the extra “@coyhile.com” in there.

Thanks,

— 
Coy Hile
coy.h...@coyhile.com

Re: What does `iterate_query` for SQL want as output?

[Aki Tuomi via dovecot]

> On 09/08/2019 22:16 Coy Hile via dovecot  wrote:
> 
>  
> Hi all,
> 
> In an earlier thread, 
> https://dovecot.org/pipermail/dovecot/2019-August/116694.html I got a lot of 
> useful help about migration. On my older host, everything was static; on the 
> newer host, I’m storing user information in Postgres. usernames are of the 
> form , say ‘h...@coyhile.com’ as basically a Kerberos principal, 
> and authentication and individual lookups work.
> 
> My `users` table looks thus:
> 
> mail=> \d users
> Table "public.users"
>   Column  | Type | Modifiers
> --+--+---
>  username | text | not null
>  domain   | text | not null
>  password | text | not null
> 
> mail=>
> 
> and contains, as an example:
> 
>  username |   domain| 
>   password
> --+-+---
>  h...@coyhile.com | coyhile.com | [REDACTED] 
> (1 row)
> 
> Naively, I’d expect something this to work for the iteration query:
> 
> iterate_query = SELECT username, domain FROM users
> 
> 
> But, when I do that, I end up 
> 
> doveadm backup -D -A -R -f ssh -i id_rsa.dsync imap01.coyhile.com 
> /opt/local/bin/doveadm dsync-server -A
> doveadm(h...@coyhile.com@coyhile.com): Info: User no longer exists, skipping
> [root@81716ec5-bca4-6d53-ed81-bd1a55d46b4f /tmp]#
> 
> Note the extra “@coyhile.com” in there.
> 
> Thanks,
> 
> — 
> Coy Hile
> coy.h...@coyhile.com

If your username field already contains domain, you do not need to return 
domain field separately. It is only needed if your username field only contains 
local part.

Aki

Re: What does `iterate_query` for SQL want as output?

[Coy Hile via dovecot]

> On Aug 9, 2019, at 3:45 PM, Aki Tuomi  wrote:
> 
> 
>> On 09/08/2019 22:16 Coy Hile via dovecot  wrote:
>> 
>> 
>> Hi all,
>> 
>> In an earlier thread, 
>> https://dovecot.org/pipermail/dovecot/2019-August/116694.html I got a lot of 
>> useful help about migration. On my older host, everything was static; on the 
>> newer host, I’m storing user information in Postgres. usernames are of the 
>> form , say ‘h...@coyhile.com’ as basically a Kerberos 
>> principal, and authentication and individual lookups work.
>> 
>> My `users` table looks thus:
>> 
>> mail=> \d users
>>Table "public.users"
>>  Column  | Type | Modifiers
>> --+--+---
>> username | text | not null
>> domain   | text | not null
>> password | text | not null
>> 
>> mail=>
>> 
>> and contains, as an example:
>> 
>> username |   domain| 
>>   password
>> --+-+---
>> h...@coyhile.com | coyhile.com | [REDACTED] 
>> (1 row)
>> 
>> Naively, I’d expect something this to work for the iteration query:
>> 
>> iterate_query = SELECT username, domain FROM users
>> 
>> 
>> But, when I do that, I end up 
>> 
>> doveadm backup -D -A -R -f ssh -i id_rsa.dsync imap01.coyhile.com 
>> /opt/local/bin/doveadm dsync-server -A
>> doveadm(h...@coyhile.com@coyhile.com): Info: User no longer exists, skipping
>> [root@81716ec5-bca4-6d53-ed81-bd1a55d46b4f /tmp]#
>> 
>> Note the extra “@coyhile.com” in there.
>> 
>> Thanks,
>> 
>> — 
>> Coy Hile
>> coy.h...@coyhile.com
> 
> If your username field already contains domain, you do not need to return 
> domain field separately. It is only needed if your username field only 
> contains local part.

That’s what I thought, and a simpler query returns the data I expect:

mail=> select username from users;
 username
--
 h...@coyhile.com
(1 row)

mail=>


Or SELECT username AS user FROM users; (if the iterate query is the column to 
be named `user`?) When I configure the iterate_query to be SELET username AS 
user FROM users; I get this:

doveadm backup -D -A -R -f ssh -i id_rsa.dsync imap01.coyhile.com 
/opt/local/bin/doveadm dsync-server -A
Error: User listing returned failure
doveadm: Error: Failed to iterate through some users
dsync-local(h...@coyhile.com): Error: read(remote) 
failed: EOF (version not received)


Which brings up two questions: 
(1) Is there a way to get more useful debugging information than “failed to 
iterate through some users”? (FWIW there’s nothing relevant in syslog.)
(2) Is there a way to isolate and exercise just that particular bit so that I 
know I’m giving it what it expects?

The SQL documentation https://wiki.dovecot.org/AuthDatabase/SQL indicates that 

iterate_query = SELECT username AS user FROM users

should return what it wants.

— 
Coy Hile
coy.h...@coyhile.com

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: Autoexpunge not working for Junk?

[@lbutlr via dovecot]

On 8 Aug 2019, at 13:03, Amir Caspi  wrote:
> IMHO the setting should apply regardless of protocol, but is that actually 
> the case in practice?

It seems to be broken.

I have

namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
autoexpunge = 14 days
auto = subscribe
special_use = \Junk
}
… 
}

and I have messages in my Junk Mail from 16 July 2019



-- 
I AM ZOMBOR! (kelly) ZOMBOR!