Re: [EXT] Re: dovecot-SASL for Postfix: EXTERNAL does not work.
(I removed Wietse Venema from Cc:.) Aki Tuomi wrote in <1972528099.4900.1598022980...@appsuite-dev-gw1.open-xchange.com>: ... |Sorry for duplicate mail, I accidentically pressed too many keys... *sigh* Sure. |Anyways, I'm not sure if you understood my point, I ment, have you \ |tried EXTERNAL auth with https://doc.dovecot.org/admin_manual/submission\ |_server/ ? No, i never did. I had to look into this, i do not think this is applicable? LMTP? The dovecot submission server, ok, as a frontend for postfix, this is what you mean? No, i have not done this yet. Start postfix on a different local port as a submission_relay_host= target, then start dovecot submission on :25, :587 and :465. I will try this out, thanks for the suggestion. 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)
Re: [EXT] Re: dovecot-SASL for Postfix: EXTERNAL does not work.
Aki Tuomi wrote in
<1907575568.4364.1597984769...@appsuite-dev-gw1.open-xchange.com>:
|> On 21/08/2020 02:17 Steffen Nurpmeso wrote:
...
|> Wietse Venema wrote in
|><4bxstk189nzj...@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?
...
|>|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)?
...
|I was trying to suggest that you could try dovecot submission server. \
|It might work better with EXTERNAL authentication.
Ok, thanks. Yes, i just faked it for my tests, carrying over the
IMAP/POP3 communication. (I use your output as a template and do
stuff like
smtp_script smtp -Ssmtp-config=-all,starttls,externanon \
-Stls-config-pairs=Certificate=client-pair.pem
{ smtp_ehlo && printf '\001
STARTTLS
\003
220 2.0.0 Ready to start TLS
' &&
smtp_ehlo 0 && printf '\001
AUTH EXTERNAL =
' &&
smtp_auth_ok && smtp_go; } |
../net-test -U -s .t.sh > "${MBOX}" 2>&1
check auth-7 0 "${MBOX}" '4294967295 0'
you know. Terrible this does not work for GSSAPI, i am about to
ask the MIT people to add two pseudo credentials, one which always
works and one which does not, so that automatic testing is
possible at all, and via unpriviledged account!)
But wouldn't this be an improvement, extending the protocol so
that it announces a fingerprint checksum digest, which then can be
used in return to report client certificate fingerprints to the
dovecot auth server? Like that even client certificate
verification could be handled by dovecot auth, aka via SASL, and
administrators would have to take care for one user database only?
Other than that i say
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)
Re: dovecot-SASL for Postfix: EXTERNAL does not work.
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.1597934431...@appsuite-dev-gw2.open-xchange.com>: The dovecot mail archive removed your HTML message :) (And given code like 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" it was right in doing so :-) ||On 20/08/2020 17:28 Steffen Nurpmeso <[1]stef...@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 <4bxstk189nzj...@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 <4bxstk189nzj...@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='stef...@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)
dovecot-SASL for Postfix: EXTERNAL does not work.
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)
