dovecot - Aug 2008 - Fwd: Re: sasl parameters missing (in postfix)

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 at porcupine.org>
To: Daniel Black <daniel.subs at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080807/2803832c/attachment-0002.bin>