Apple mail client 535 Incorrect authentication data errors in exim

T

twv

Verified User
Joined
Oct 31, 2003
Messages
219
This client uses exclusively Apple Mail. He and his employee are getting this error no matter which Mac they send from, but their emails go out fine.

There are hundreds of lines like this in the brute force monitor:
exim1 2014-01-27 13:48:39 plain authenticator failed for ([192.168.1.148]) [xx.xxx.xx.xxx]: 535 Incorrect authentication data ([email protected])
Click to expand...

In the exim log file, lines like that are immediately followed by a successful send when he tries to send something. Example:

2014-01-19 16:14:12 plain authenticator failed for [removed] ([192.168.0.102]) [xx.xxx.xx.xx]: 535 Incorrect authentication data ([email protected])
2014-01-19 16:14:13 1W4zh6-0001N7-Vp <= [email protected] H=[removed] ([192.168.0.102]) [xx.xxx.xx.xx] P=esmtpsa X=TLSv1:AES128-SHA:128 A=plain:[email protected] S=4299 [email protected] T="test email" from <[email protected]> for [email protected]
2014-01-19 16:14:14 1W4zh6-0001N7-Vp => [email protected] F=<[email protected]> R=lookuphost T=remote_smtp S=4390 H=xx.xxx.xx.xx [xx.xxx.xx.xx] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256 C="250 2.0.0 Ok: queued as 5CF351419AC"
2014-01-19 16:14:14 1W4zh6-0001N7-Vp Completed
Click to expand...

I went to his office and checked his setup and couldn't find any problems. He is the only client getting this type of error.

I'm not sure what the problem is. Any ideas?

He has his outbound server set to use an insecure connection to port 587 at mail.hisdomain.com. Could that be the problem?

He has SMTP set to use authentication, and the user name and password are correct. And, like I said, the emails do go out, but not before generating the error message.
 
It has to do with the way the /etc/exim.pl does authentication. I was getting the same thing with all of Macs too. I made my exim.pl look like this:
Code: 
        $extra          = Exim::expand_string('$3');
        $domain         = "";
        $unixuser       = 1;

        #check for netscape that offsets the login/pass by one
        if ($username eq $password)
        {
                $username = $password;
                $password = $extra;
        }
        elsif ($username eq "" && length($extra) > 0)
        {
                $username = $password;
                $password = $extra;
        }
And now I don't have that problem. I found someone else on the forum had the same problem, and noticed that Macs sent the username in $1 and $2 and the password in $3. This checks for that and resets the $username/$password and then does the other check for those clients that only send data in $2 and $3.
 
Thanks! So this is the part you added?

Code: 
        if ($username eq $password)
        {
                $username = $password;
                $password = $extra;
        }

(Plus the if -> elsif change)
 
toml said:
It has to do with the way the /etc/exim.pl does authentication. I was getting the same thing with all of Macs too. I made my exim.pl look like this:
Code: 
        $extra          = Exim::expand_string('$3');
        $domain         = "";
        $unixuser       = 1;

        #check for netscape that offsets the login/pass by one
        if ($username eq $password)
        {
                $username = $password;
                $password = $extra;
        }
        elsif ($username eq "" && length($extra) > 0)
        {
                $username = $password;
                $password = $extra;
        }
And now I don't have that problem. I found someone else on the forum had the same problem, and noticed that Macs sent the username in $1 and $2 and the password in $3. This checks for that and resets the $username/$password and then does the other check for those clients that only send data in $2 and $3.
Click to expand...

Thanks for your post, I ran into this same issue with some clients and it helped resolved that situation really quick.

However, there is a slight problem with the changes when users do something they really shouldn't: use their username as password.

My recommendation is this

Code: 
       if (length($extra) > 0 ) {

                if ($username eq "" || $username eq $password)
                {
                        $username = $password;
                        $password = $extra;
                }
        }

Similar to the original code, this makes sure there is something in $extra before doing value replacements.
 
Good point, of course you have to remember that later when someone swears to you they have the password correct, but their email isn't working, that you have this change.
 
toml said:
Good point, of course you have to remember that later when someone swears to you they have the password correct, but their email isn't working, that you have this change.
Click to expand...

I don't think that would arise since so far the scenarios for the 3 parameters are
A - 1: blank 2: username 3:password
B - 1: username 2:username 3:password
C - 1: username 2:password: 3: blank

The check for length of param 3 means only A & B will trigger this check.
For A, the existing code will substitute username and password correctly.
For B, all 3 values are the same so it will work too.

If I'm missing another scenario, please do point it out so the code can be further refined for anybody who runs into the same situation :)
 
That check was less technical and more social. It was to prevent a user from using a username and password that match each other. I think that is one of the first things a brute-force password checker does.
 
toml said:
That check was less technical and more social. It was to prevent a user from using a username and password that match each other. I think that is one of the first things a brute-force password checker does.
Click to expand...

I'd agree 100% it's not a good idea for an user to use their username as a password.

However, I think the enforcement should not be done on the MTA side, but at the control panel side to disallow setting passwords as usernames since it is a policy issue rather than mail issue. After all, the customer (or often the non-IT person chosen as the admin) isn't going to be happy that SMTP doesn't work but there was no warning when he sets them.
 
Since a few days I have a client which uses Apple Mail and he gets constantly banned by fail2ban (of course u can blame jail settings BUT...)
Code: 
plain authenticator failed for (apn-5-174-2-32.dynamic.gprs.plus.pl) [5.174.2.32]: 535 Incorrect authentication data

I'm using exim.pl VERSION=15

Need once again any confirmation that this is rightful manual fix, I won't break anything else using that fix?

Code: 
 $username       = Exim::expand_string('$1');
        $password       = Exim::expand_string('$2');
        $extra          = Exim::expand_string('$3');
        $domain         = "";
        $unixuser       = 1;

        #FIX: http://forum.directadmin.com/showthread.php?t=48234

        #      if (length($extra) > 0 ) {
        #        if ($username eq "" || $username eq $password)
        #        {
        #                $username = $password;
        #                $password = $extra;
        #        }
        #}
        #end FIX

        #check for netscape that offsets the login/pass by one
        if ($username eq "" && length($extra) > 0)
        {
                $username = $password;
                $password = $extra;
        }
 
Thanks, but - I'forgot to mention - I'm using the same code from here on this(); topic only merged with user @cadmin 's addon.

About DA fix, the problem even exists back in 2004 as I saw here http://forum.directadmin.com/showthread.php?t=3936, mentioned a year ago here http://forum.directadmin.com/showthread.php?t=47951

Other workaround is when a client uses CRAM-MD5 instead of PLAIN it works NP and it's confirmed in that y2004 thread. But that's not an option to me.

This issue is odd, beacuse with sb can blame user-conf. settings for this in the first place, and what is worse - fai2ban regex's can bring user to NO-NO state just before that :)
 
The code you have between "#FIX" and "#end FIX" should do the trick, it is a replacement for the code you have below the "#check for netscape" though, not in addition to. It does the same thing as the code I posted but in a few less lines.
 
If someone will post a definitive fix as a diff file to SpamBlocker 4 (as published here (nobaloney.net) I'll install it on one of my servers and then give it a test. If it works well I'll add it to my codebase and suggest it as an addition to the main DirectAdmon exim configuration.

HOWEVER: It must fix the Apple issue without cresating any issues for any other platform.

I'm not sure of the true nature of the problem because I have several major clients logging in with OS-X. In the case of one client, with two domains on the same server but the same OS-X settings, one of the domains throws a lot of the errors, but the other absolutely none.

Jeff
 
Jeff,
The diff is for the exim.pl which you don't have any longer in your SpamBlocker 4 folder. The diff against the http://files.directadmin.com/services/exim.pl file would look like this. I have been running with this change for quite some time and the only authentication errors I see now in the log file are from spammers.

Code: 
[root@otto ~]# diff exim.pl.orig exim.pl
130,133c130,135
< 	if ($username eq "" && length($extra) > 0)
< 	{
< 		$username = $password;
< 		$password = $extra;
---
> 	if (length($extra) > 0 ) {
> 		if ($username eq "" || $username eq $password)
> 		{
> 			$username = $password;
> 			$password = $extra;
> 		}
 
So now I'm even more confused. Here all along I was reading this thread and each time I saw 'exim.pl' I mus have been thinking 'exim.conf' even though obviously the code examples are from the .pl file and not the .conf file.

But I've never even looked ito how/why/where exim.pl has anything to do with authentication.

But the bright light that's finally gone off in my head makes this a lot easier for me, since I no longer keep my own exim.pl file but depend on the latest one from DirectAdmin.

So the last question is simly:

Is this ready to ask John to include it in exim.pl?

Any final comments, especially anyone with any problems it may have caused?

Jeff
 
Just had the same problem exactly and added the fix above.
Let's see if this will be fine for all existing users.
 
nobaloney said:
Is this ready to ask John to include it in exim.pl?

Any final comments, especially anyone with any problems it may have caused?
Click to expand...

I think it'd be great if DA included it. I haven't had any problems since making the change and my formerly disgruntled Mac user is now very happy that his IP address is no longer getting banned. (I use fail2ban, too).
 
You must log in or register to reply here.
Back
Top