In response to my request for postfix to support dovecot auth arguments I got the forwarded reply.
If someone gets around to this before me I won't be offended.
Story is I deployed a webmail with certificate based authentication that substitutes a global master password (http://wiki.dovecot.org/Authentication/MasterUsers) when the certificate matches. The webmail accesses the inbox by imap and reuses the password for smtp through postfix.
I configured dovecot sasl authentication to allow a particular global password to be allowed from one IP address of the webmail server. Unfortuanately it seems as though postfix doesn't pass rip= (remote ip) or the other AUTH parameters of the protocol (http://dovecot.org/doc/auth-protocol.txt).
Is adding these parameters to postfix's sasl authentication a useful feature request?
---------- Forwarded Message ----------
Subject: Re: sasl parameters missing Date: Thu, 7 Aug 2008 From: Wietse Venema wietse@porcupine.org To: Daniel Black daniel.subs@internode.on.net
Daniel Black:
Thanks Wietse,
On Tue, 5 Aug 2008 09:30:44 am Wietse Venema wrote:
Postfix passes the information in the SMTP client's AUTH command. This is how I got the Dovecot extension from Timo. If someone is willing to monitor his docs for changes,
it seems fairly stable. Going off the doc/auth-protocol.txt changelog Nov 12 2006 lport/rport was added. Aug 07 2005 changed valid-client-cert to ssl-valid-cert Oct 22 2004 original documentation
Current implementation of the authentication server in dovecot seems to ignore parameters it doesn't understand.
then they are welcome to do so. I won't.
On the basis of this apparent stability and compatibility would you consider accepting a patch?
Yes. No promise, though, that it will be adopted.
One consideration is that Postfix does not talk directly to Dovecot, but instead talks to an abstraction layer that is used for both Cyrus SASL and for Dovecot.
Obviously, that XSASL abstraction layer must not be made specific to the underlying Cyrus SASL or Dovecot implementation. The solution therefore is not to extend XSASL functions with one extra argument for each Dovecot feature. Apart from being Dovecot-specific, functions with many parameters are difficult to update correctly; compilers can't always tell that two arguments should be swapped.
I solved the problem of many-parameter functions by using macros such as TLS_SERVER_START(). This gives more assurance that data is passed correctly, and it less likely to break due to human maintainer error.
Wietse--
Daniel Black
Proudly a Gentoo Linux User. Gnu-PG/PGP signed and encrypted email preferred http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x76677097 GPG Signature D934 5397 A84A 6366 9687 9EB2 861A 4ABA 7667 7097