On 11/10/2011 10:40, Drav Sloan wrote:
Todd Lyons wrote:
Temporarily turn off the TLS requirement (comment out that line).
Configure the client not to use TLS. tcpdump the session and see if
it's sending the password you think it should.
Personally I prefer to run:
exim -d -bd -oX 4444
And then configure my client to use port 4444. That way you maintain
security and also get a full exim debug output of what is going on.
Tcpdump would be a fallback position.
Also with thunderbird you can enable client debugging
Create a batch file with:
set NSPR_LOG_MODULES=SMTP:5
set NSPR_LOG_FILE=C:\thunderbird.log
start /d "C:\Program Files\Mozilla Thunderbird" thunderbird.exe
Where NSPR_LOG_FILE is the path to where you want the log file
and the arguement to /d is the location of your thunderbird install.
This will give more insight as to what has been sent on the client
side.
Regards
D.
Thanks for the reply but I am certain the client side has nothing to do
with this.
Thunderbird was simply an easy test environment. We have numerous
servers and pieces of equipment all round the region set up to authenticate.
If the authentication is handled by the original backend server, they
work fine but if I use the authenticator on the front end servers it may
or may not work. The problem is consistent in that the same details will
fail all the time on a particular server. It is inconsistent in that the
details that fail on one server will succeed on a different server.
The client is sending the correct details, tcpdump has shown that the
auth string is identical whether the auth attempt succeeds or not.
Regards,
Colin.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
