On Mon, Aug 19, 2002 at 05:26:40PM +0200, Tony Earnshaw wrote:
> "Exim -bt has nothing to do with it".
>
> Nor has it, quite right.
>
> But when I send SSL/TLS encrypted mail with the following, it works
> perfectly, anyway:
>
> Replace:
>
> {user="mail=${quote_ldap:$2}
>
> With:
>
> {user="mail=${quote_ldap:"$2"}
Well, actually I can't see what SSL/TLS has to do with it either.
You said you had something like this in your configuration:
fixed_plain:
...
server_condition = ${if ldapauth \
{user="mail=${quote_ldap:$2},\
ou=people,ou=groups,dc=billy,dc=demon,dc=nl" pass="$3"\
ldap:///}{yes}{no}}
That's an authenticator. So to trigger it, the client has to send an SMTP
AUTH command (over either a normal or TLS connection, it doesn't make any
difference). To test, encode a string like this:
$ perl -MMIME::Base64 -e 'print encode_base64("\0tonni\@billy.demon.net\0password")'
AHRvbm5pQGJpbGx5LmRlbW9uLm5ldABwYXNzd29yZA==
then telnet to your mailhost port 25 and send "AUTH PLAIN <this string>". If
you get a 235 response, you have authenticated successfully.
At the same time you should see the LDAP query going off to your LDAP
server, perhaps most easily seen by running
tcpdump -n -s1500 -X tcp port 389
on the host at the same time. This is how I discovered that quote_ldap was
mangling 'foo@???' to 'foo%40example.com'
If your clients are not actually using SMTP AUTH then of course you can put
whatever you like inside server_condition, as it won't do anything :-)
Regards,
Brian.