On 09/10/2011 23:10, Colin wrote:
>
>> Then you'd have something like (untested):
>>
>> auth_plain:
>> driver = plaintext
>> public_name = PLAIN
>> server_advertise_condition = ${if def:tls_cipher}
>> server_prompts = :
>> server_condition = ${lookup{$auth2}lsearch{/etc/exim/passwd}\
>> {${if crypteq{$auth3}{$value}}}
>> {false}}
>> server_set_id = ${quote:$auth2}
>>
>> -Phil
>>
>
> Thank you very much for the reply Phil.
> Your untested auth_plain works a charm. I've amended my collection
> script to not put the :: on the end and authentication now seems to
> work. Turns out I'd followed a guide that used md5 passwords and had
> an md5 check in the condition which of course wouldn't work seen as
> the passwords aren't md5 passwords. All the OS concerned are CentOS 6
> built exactly the same so no problems with different routines.
> Its late here so I've put it in place on a backup server and will give
> it thorough testing tomorrow evening out of hours.
> Much appreciated.
> Regards,
> Colin.
>
It turns out that I might have spoken too soon.
After a few hours monitoring it would appear that a number of accounts
will not authenticate but there is no apparent reason.
Example 1: Using the same configuration and the same passwd file on two
servers. My Thunderbird client will not authenticate to server 1 but
will authenticate to server2 using the exact same details
Example 2: Numerous servers use server 1 as a smarthost. One reseller
has all their servers using a similar format of
generic@??? and the password is the same for all the
smarthost accounts. Most work but one or two do no. These all have
exactly the same hash in the passwd file so there is no reason why some
would work and others not.
It does log something:
2011-10-10 07:55:57 login_server authenticator failed for localhost
(my.server.name) [1.1.1.1]: 535 Incorrect authentication data
(set_id="generic@???")
So the next question I have is how do I debug this and figure out why
some authentications are failing?
Regards,
Colin.
