Hello.
I am not subscribed and new here, so first of all i want to thank
you for dovecot. I personally do not use it in "production"
(yet), but it is my sole point of interaction for testing the
little MUA i maintain for quite some years. I also have used its
code for affirmation purposes. (Interesting that OAUTHBEARER
treats hostname and port as optional. I currently do
OAUTHBEARER.)
So then i stumbled over GSSAPI not being usable anymore with the
latest release, but it seems there is an ML thread with a fix.
I have not tried it, i reverted to the last release here, though.
When i implemented EXTERNAL authentication last year i could not
figure out how to make postfix+dovecot-SASL work with it. First
of all i had to switch configs back and forth, but in the meantime
i learned a very nice trick: if i use two password databases
passdb {
driver = passwd-file
mechanisms = external
args = /etc/dovecot/pass-external.db
override_fields = nopassword
}
passdb {
driver = passwd-file
args = /etc/dovecot/pass.db
}
userdb {
driver = passwd
}
which are effectively the same except that one does not have
passwords while the other has, i can use EXTERNAL (with and
without additional user-via-protocol in combination with
auth_ssl_username_from_cert=yes and it just works!
Whereas EXTERNAL works just fine for IMAP and POP3 it does not for
SMTP. Last year when i did it i saw a postfix ML thread in
action, so i have not looked further into that. Looking again
with things unchanged in the postfix 3.5 that they mentioned by
then i think, i now posted to the postfix list myself yesterday
[1], and it turned out that postfix seems incapable to do
something about it, because the dovecot auth protocol does not
offer the possibility to specify a valid-user-certificate-seen
flag as well as pass the username from the certificate. (Or even
pass the entire certificate as a base64 string, less postfix CA,
.. or whatever.)
[1] https://marc.info/?l=postfix-users&m=159785887710910&w=2
What is really terrible with the current situation is that postfix
announces the EXTERNAL, with Wietse Venema saying
Short summary: Postfix does not implement a single iota of SASL
AUTH support. Postfix simply propagates the names of mechanisms
that the backend (Cyrus or Dovecot) claims to support, and Postfix
proxies requests and responses between the remote SMTP client and
the SASL backend. Postfix has no idea what SASL mechanisms are,
including EXTERNAL. It just proxies stuff.
If Dovecot claims to support SASL EXTERNAL but does not handle it,
that that is a bit of a WTF.
It would be tremendous to have true EXTERNAL support all through,
i personally really like EXTERNAL, i would rather have some
password-protected crytographically secured certificates in my
local store, and have client certificates in all the IoT devices,
than have to mess around with the OAUTH that the major players
press forward, for example.
Thanks,
and Ciao from Germany,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<div>
</div>
<blockquote type="cite">
<div>
On 20/08/2020 17:28 Steffen Nurpmeso <<a
href="mailto:steffen@sdaoden.eu">steffen@sdaoden.eu</a>>
wrote:
</div>
<div>
</div>
<div>
</div>
<div>
Hello.
</div>
<div>
</div>
<div>
I am not subscribed and new here, so first of all i want to thank
</div>
<div>
you for dovecot. I personally do not use it in "production"
</div>
<div>
(yet), but it is my sole point of interaction for testing the
</div>
<div>
little MUA i maintain for quite some years. I also have used its
</div>
<div>
code for affirmation purposes. (Interesting that OAUTHBEARER
</div>
<div>
treats hostname and port as optional. I currently do
</div>
<div>
OAUTHBEARER.)
</div>
<div>
</div>
<div>
So then i stumbled over GSSAPI not being usable anymore with the
</div>
<div>
latest release, but it seems there is an ML thread with a fix.
</div>
<div>
I have not tried it, i reverted to the last release here, though.
</div>
<div>
</div>
<div>
When i implemented EXTERNAL authentication last year i could not
</div>
<div>
figure out how to make postfix+dovecot-SASL work with it. First
</div>
<div>
of all i had to switch configs back and forth, but in the meantime
</div>
<div>
i learned a very nice trick: if i use two password databases
</div>
<div>
</div>
<div>
passdb {
</div>
<div>
driver = passwd-file
</div>
<div>
mechanisms = external
</div>
<div>
args = /etc/dovecot/pass-external.db
</div>
<div>
override_fields = nopassword
</div>
<div>
}
</div>
<div>
passdb {
</div>
<div>
driver = passwd-file
</div>
<div>
args = /etc/dovecot/pass.db
</div>
<div>
}
</div>
<div>
userdb {
</div>
<div>
driver = passwd
</div>
<div>
}
</div>
<div>
</div>
<div>
which are effectively the same except that one does not have
</div>
<div>
passwords while the other has, i can use EXTERNAL (with and
</div>
<div>
without additional user-via-protocol in combination with
</div>
<div>
auth_ssl_username_from_cert=yes and it just works!
</div>
<div>
</div>
<div>
Whereas EXTERNAL works just fine for IMAP and POP3 it does not for
</div>
<div>
SMTP. Last year when i did it i saw a postfix ML thread in
</div>
<div>
action, so i have not looked further into that. Looking again
</div>
<div>
with things unchanged in the postfix 3.5 that they mentioned by
</div>
<div>
then i think, i now posted to the postfix list myself yesterday
</div>
<div>
[1], and it turned out that postfix seems incapable to do
</div>
<div>
something about it, because the dovecot auth protocol does not
</div>
<div>
offer the possibility to specify a valid-user-certificate-seen
</div>
<div>
flag as well as pass the username from the certificate. (Or even
</div>
<div>
pass the entire certificate as a base64 string, less postfix CA,
</div>
<div>
.. or whatever.)
</div>
<div>
</div>
<div>
[1] <a
href="https://marc.info/?l=postfix-users&m=159785887710910&w=2"
target="_blank"
rel="noopener">https://marc.info/?l=postfix-users&m=159785887710910&w=2</a>
</div>
<div>
</div>
<div>
What is really terrible with the current situation is that postfix
</div>
<div>
announces the EXTERNAL, with Wietse Venema saying
</div>
<div>
</div>
<div>
Short summary: Postfix does not implement a single iota of SASL
</div>
<div>
AUTH support. Postfix simply propagates the names of mechanisms
</div>
<div>
that the backend (Cyrus or Dovecot) claims to support, and Postfix
</div>
<div>
proxies requests and responses between the remote SMTP client and
</div>
<div>
the SASL backend. Postfix has no idea what SASL mechanisms are,
</div>
<div>
including EXTERNAL. It just proxies stuff.
</div>
<div>
</div>
<div>
If Dovecot claims to support SASL EXTERNAL but does not handle it,
</div>
<div>
that that is a bit of a WTF.
</div>
<div>
</div>
<div>
It would be tremendous to have true EXTERNAL support all through,
</div>
<div>
i personally really like EXTERNAL, i would rather have some
</div>
<div>
password-protected crytographically secured certificates in my
</div>
<div>
local store, and have client certificates in all the IoT devices,
</div>
<div>
than have to mess around with the OAUTH that the major players
</div>
<div>
press forward, for example.
</div>
<div>
</div>
<div>
Thanks,
</div>
<div>
and Ciao from Germany,
</div>
<div>
</div>
<div>
--steffen
</div>
<div>
|
</div>
<div>
|Der Kragenbaer, The moon bear,
</div>
<div>
|der holt sich munter he cheerfully and one by one
</div>
<div>
|einen nach dem anderen runter wa.ks himself off
</div>
<div>
|(By Robert Gernhardt)
</div>
</blockquote>
<div>
</div>
<div class="default-style">
You could try out dovecot submission service. It should work better with
EXTERNAL.
</div>
<div class="io-ox-signature">
<pre>---
Aki Tuomi</pre>
</div>
</body>
</html>
<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<div>
</div>
<blockquote type="cite">
<div>
On 20/08/2020 17:28 Steffen Nurpmeso <<a
href="mailto:steffen@sdaoden.eu">steffen@sdaoden.eu</a>>
wrote:
</div>
<div>
</div>
<div>
</div>
<div>
Hello.
</div>
<div>
</div>
<div>
I am not subscribed and new here, so first of all i want to thank
</div>
<div>
you for dovecot. I personally do not use it in "production"
</div>
<div>
(yet), but it is my sole point of interaction for testing the
</div>
<div>
little MUA i maintain for quite some years. I also have used its
</div>
<div>
code for affirmation purposes. (Interesting that OAUTHBEARER
</div>
<div>
treats hostname and port as optional. I currently do
</div>
<div>
OAUTHBEARER.)
</div>
<div>
</div>
<div>
So then i stumbled over GSSAPI not being usable anymore with the
</div>
<div>
latest release, but it seems there is an ML thread with a fix.
</div>
<div>
I have not tried it, i reverted to the last release here, though.
</div>
<div>
</div>
<div>
When i implemented EXTERNAL authentication last year i could not
</div>
<div>
figure out how to make postfix+dovecot-SASL work with it. First
</div>
<div>
of all i had to switch configs back and forth, but in the meantime
</div>
<div>
i learned a very nice trick: if i use two password databases
</div>
<div>
</div>
<div>
passdb {
</div>
<div>
driver = passwd-file
</div>
<div>
mechanisms = external
</div>
<div>
args = /etc/dovecot/pass-external.db
</div>
<div>
override_fields = nopassword
</div>
<div>
}
</div>
<div>
passdb {
</div>
<div>
driver = passwd-file
</div>
<div>
args = /etc/dovecot/pass.db
</div>
<div>
}
</div>
<div>
userdb {
</div>
<div>
driver = passwd
</div>
<div>
}
</div>
<div>
</div>
<div>
which are effectively the same except that one does not have
</div>
<div>
passwords while the other has, i can use EXTERNAL (with and
</div>
<div>
without additional user-via-protocol in combination with
</div>
<div>
auth_ssl_username_from_cert=yes and it just works!
</div>
<div>
</div>
<div>
Whereas EXTERNAL works just fine for IMAP and POP3 it does not for
</div>
<div>
SMTP. Last year when i did it i saw a postfix ML thread in
</div>
<div>
action, so i have not looked further into that. Looking again
</div>
<div>
with things unchanged in the postfix 3.5 that they mentioned by
</div>
<div>
then i think, i now posted to the postfix list myself yesterday
</div>
<div>
[1], and it turned out that postfix seems incapable to do
</div>
<div>
something about it, because the dovecot auth protocol does not
</div>
<div>
offer the possibility to specify a valid-user-certificate-seen
</div>
<div>
flag as well as pass the username from the certificate. (Or even
</div>
<div>
pass the entire certificate as a base64 string, less postfix CA,
</div>
<div>
.. or whatever.)
</div>
<div>
</div>
<div>
[1] <a
href="https://marc.info/?l=postfix-users&m=159785887710910&w=2"
target="_blank"
rel="noopener">https://marc.info/?l=postfix-users&m=159785887710910&w=2</a>
</div>
<div>
</div>
<div>
What is really terrible with the current situation is that postfix
</div>
<div>
announces the EXTERNAL, with Wietse Venema saying
</div>
<div>
</div>
<div>
Short summary: Postfix does not implement a single iota of SASL
</div>
<div>
AUTH support. Postfix simply propagates the names of mechanisms
</div>
<div>
that the backend (Cyrus or Dovecot) claims to support, and Postfix
</div>
<div>
proxies requests and responses between the remote SMTP client and
</div>
<div>
the SASL backend. Postfix has no idea what SASL mechanisms are,
</div>
<div>
including EXTERNAL. It just proxies stuff.
</div>
<div>
</div>
<div>
If Dovecot claims to support SASL EXTERNAL but does not handle it,
</div>
<div>
that that is a bit of a WTF.
</div>
<div>
</div>
<div>
It would be tremendous to have true EXTERNAL support all through,
</div>
<div>
i personally really like EXTERNAL, i would rather have some
</div>
<div>
password-protected crytographically secured certificates in my
</div>
<div>
local store, and have client certificates in all the IoT devices,
</div>
<div>
than have to mess around with the OAUTH that the major players
</div>
<div>
press forward, for example.
</div>
<div>
</div>
<div>
Thanks,
</div>
<div>
and Ciao from Germany,
</div>
<div>
</div>
<div>
--steffen
</div>
<div>
|
</div>
<div>
|Der Kragenbaer, The moon bear,
</div>
<div>
|der holt sich munter he cheerfully and one by one
</div>
<div>
|einen nach dem anderen runter wa.ks himself off
</div>
<div>
|(By Robert Gernhardt)
</div>
</blockquote>
<div>
</div>
<div class="io-ox-signature">
<pre>---
Aki Tuomi</pre>
</div>
</body>
</html>
Hello and good evening.
Sorry for responding so late, it is midsummer and i spend as much
time as possible on the outside (bicycle, mostly). (Just one more
day, then 10 degrees colder!!)
I Cc: Wietse Venema, because i quote a message of him.
(this is "set quote-add-cc" here.)
Aki Tuomi wrote in
<84881193.5398.1597934431687 at appsuite-dev-gw2.open-xchange.com>:
The dovecot mail archive removed your HTML message :)
(And given code like
<div>
</div>
<div>
</div>
<div>
Hello.
</div>
<div>
</div>
<div>
I am not subscribed and new here, so first of all i want to thank
</div>
<div>
you for dovecot. I personally do not use it in "production"
</div>
it was right in doing so :-)
||On 20/08/2020 17:28 Steffen Nurpmeso <[1]steffen at sdaoden.eu[/1]>
wrote:
...
||What is really terrible with the current situation is that postfix
|
||announces the EXTERNAL, with Wietse Venema saying
It seems he has read the dovecot documentation again in the
meantime, different to me :(, so i have to apologise for saying
|[1], and it turned out that postfix seems incapable to do
|something about it, because the dovecot auth protocol does not
|offer the possibility to specify a valid-user-certificate-seen
|flag as well as pass the username from the certificate. (Or even
|pass the entire certificate as a base64 string, less postfix CA,
|.. or whatever.)
because Wietse Venema now says
Wietse Venema wrote in
<4BXSTk189nzJrP3 at spike.porcupine.org>:
...
|Steffen Nurpmeso:
...
|> until SASL says it is done?!. How could EXTERNAL ever work like
|> that in a client/server->auth-server situation?
|
|There's a chicken and egg question in there somewhere.
|
|https://wiki1.dovecot.org/Authentication%20Protocol mentions
|two attributes that might be relevant, and that Postfix can send:
|
|secured
| Remote user has secured transport to auth client] (eg. localhost, \
| SSL, TLS)
|
|valid-client-cert
| Remote user has presented a valid SSL certificate.
|
|But these are booleans. What protocol attribute would Postfix use
|to pass certificate name information (and which name, as there
|can be any number of them)?
|
| Wietse
| Wietse
--End of <4BXSTk189nzJrP3 at spike.porcupine.org>
I think i will spend some time tomorrow and try to do some
coding with postfix. Let's see wether the immediate response of
EXTERNAL can work with dovecot's SASL, even in conjunction with
auth_ssl_username_from_cert=yes that is!
Otherwise i think what he says here.
|You could try out dovecot submission service. It should work better \
|with EXTERNAL.
For the internal test network this may really be an option. But
for my web vm: ach, i am not an administrator, it is pain to get
used to all that. In real life i use the DMA here, and external
mail goes via my MUA through ssh only:
set mta=/usr/bin/ssh
set mta-arguments='steffen at sdaoden.eu /usr/sbin/sendmail -t'
set mta-argv0=ssh
That sendmail is postfix, then. And there is such a tremendous
amount of noise in the logs of postfix and the lighttpd web server
that are available easily from the network, it is terrible. Even
with very rigid firewall rules, and things like postfix's error
limits, junk command limit, record deadlines, timeouts, active
sleeping in restrictions ... And for now i would not even know
whether dovecot has equivalents, nor how to apply this
correctly. These are all very capable and highly configurable
applications. dovecot for example, i track the source for
a couple of years, comes with
568 files changed, 26488 insertions(+), 6969 deletions(-)
for my last update (v2.3.10.1 to v2.3.11.3). This is a lot.
Thank you.
And Ciao! and good night from Germany,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)