Hello.
Wietse Venema wrote in
<4bwxll093mzj...@spike.porcupine.org>:
|Steffen Nurpmeso:
|> I have no idea of the inner sensitivities of postfix, but i do not
|> understand where the problem lies. Why does postfix "wave
|> through" the SASL offering of EXTERNAL when it does not support
|> it? (I have no idea of SASL library interfaces.)
|
|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.
I see. So postfix sees the AUTH and then switches to SASL
inclusive the immediate response and henceforth yields everything
until SASL says it is done?!. How could EXTERNAL ever work like
that in a client/server->auth-server situation?
|> Ie postfix is configured to check client certificates, why does
|> it not "simply" allow the same configuration setting that dovecot
|> supports, something like auth_ssl_username_from_cert=yes, then
|> requires that for case(EXTERNAL) nothing but an empty immediate
|> response is passed, then passed the user given in the certificate
|> to the dovecot process? Or do also allow a username, but ensure
|> the given one is identical to that specified in the certificate?
|
|Are you suggesting that we create new SASL protocol support in
|Postfix to handle the EXTERNAL protocol inside Postfix? There
|currently is no code in Postfix for any SASL mechanism at all.
I am sorry to have blamed postfix for this. Looking at this by
searching for cert_user in the dovecot source it seems what would
be needed would be at least two new strings in the dovecot
interaction, valid_cert (or so, forgotten) and cert_username, so
that the authentication server can act accordingly (blindly
trusting the correspondent, so to say)!
I think i will unsubscribe here and go there, they have broken
GSSAPI authentication with v2.3.11.3 (the ML thread already
exists, however)! Thank you!
P.S.: but regarding the list of mechanisms, postfix _does_ do
something about it even as smtpd, especially
xsasl_dovecot_server_mech_filter()
cought my eye now?
P.P.S.: while i am here, i wonder how LMDB support could ever
worked for postfix. In 2018 i had implemented LMDB support for
bogofilter, by then on AlpineLinux with musl C library. I looked
around also in postfix (my plan was to have an all-LMDB based
email chain), and saw (and see still)
if ((status = mdb_env_create(&env)) != 0)
...
if ((status = mdb_env_set_mapsize(env, slmdb->curr_limit)) != 0
|| (status = mdb_env_open(env, path, lmdb_flags, 0644)) != 0
but this caused reproducable crashes. It forced me to write an
alternative implementation which does not resize at all. However
that is optional and the original, resizing based approach was
implemented (but we do not jump, we use a nice little cache):
/* TODO We may not do this unless going for a huge fixed size, because with
* TODO v0.9.22 a further DB open will then crash in mdb_*_put() after
* TODO a growing _mapsize call! ... */
#ifdef a_BFLM_FIXED_SIZE
e = mdb_env_set_mapsize(rv->bflm_env, a_BFLM_FIXED_SIZE);
if(e != MDB_SUCCESS){
emsg = "mdb_env_set_mapsize()";
goto jerr2;
}
#endif
e = mdb_env_open(rv->bflm_env, rv->bflm_filepath, MDB_NOSUBDIR, 0660);
I.e., initial spacing caused later crashes, at least on this
specific AlpineLinux (gcc / musl C) combination. But since the
postfix user base is so large and noone reported a problem, i did
not by then, too.
Ciao from Germany!
| Wietse
--End of <4bwxll093mzj...@spike.porcupine.org>
--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)
