Steffen Nurpmeso: > 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?
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
