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)