Exim SMTP auth problem

A

andyl

Verified User
Joined
Jul 12, 2004
Messages
23
Location
Seattle, WA
I'm having difficulty with SMTP authentication in a new DA installation on FreeBSD 5.2.1. I've walked thorough exim.pl, even put debug logging statements in it, and it appears that it successfully verifies users (that is, returns "yes"); however, exim returns:

Code: 
 plain authenticator failed for ([192.168.0.11]) [xx.yy.zz.aa]: 535 Incorrect authentication data ([email protected])

The same problem appears when I authenticate a user whose information is in the system passwd file, as opposed to in virtual domain authentication files.

This is with the stock Exim 4.24.

Does anyone have any idea what might be going on?

Thanks,
Andy
 
This was with Mozilla Thunderbird 0.7.2 and Apple Mail; I'll use a packet sniffer later today to see if I can find anything useful from that.

Thanks,
Andy
 
andyl said:
This was with Mozilla Thunderbird 0.7.2 and Apple Mail; I'll use a packet sniffer later today to see if I can find anything useful from that.

Thanks,
Andy
Click to expand...

IIRC, Apple Mail has "issues" with Exim's authentication. There were several threads on Apple's discussion boards.

Solution, set Apple Mail for no authentication (after setting for authentication and entering username and password) and make sure POPb4SMTP is enabled and it will work fine.

HTH

Steve
 
Thanks for the tip about Apple Mail - although interestingly (and maybe not related, since it's a different authenticator), I'm using a non-DA Exim 4.34 server for another client with Apple Mail and it's doing authentication without a hitch, although it's using CRAM-MD5 instead of login or plain.

I'll give your suggestion a try as soon as I get a chance.

Thanks,
Andy
 
sbchasin said:
IIRC, Apple Mail has "issues" with Exim's authentication. There were several threads on Apple's discussion boards.

Solution, set Apple Mail for no authentication (after setting for authentication and entering username and password) and make sure POPb4SMTP is enabled and it will work fine.

HTH

Steve
Click to expand...

Okay, using tcpdump and ethereal to look at a failed attempt to send mail and replaying the session using exim -bh, I was able to get smtp auth (only for "login" authentication, not "plain", more details below) working - it turned out that what Exim was choking on was /etc/virtual/pophosts not having been created yet. Once I created that file, relaying worked.

Here's what the failed session looked like (somewhat sanitized):

Code: 
% exim -bh 11.22.33.44

**** SMTP testing session as if from host 11.22.33.44
**** but without any ident (RFC 1413) callback.
**** This is not for real!

>>> host in host_lookup? no (option unset)
>>> host in host_reject_connection? no (option unset)
>>> host in sender_unqualified_hosts? no (option unset)
>>> host in recipient_unqualified_hosts? no (option unset)
>>> host in helo_verify_hosts? no (option unset)
>>> host in helo_try_verify_hosts? no (option unset)
>>> host in helo_accept_junk_hosts? no (option unset)
220 domain.com ESMTP Exim 4.24 Tue, 13 Jul 2004 19:27:37 -0700
EHLO some.domain.com
>>> some.domain.com in helo_lookup_domains? no (end of list)
>>> host in pipelining_advertise_hosts? yes (matched "*")
>>> host in auth_advertise_hosts? yes (matched "*")
>>> host in tls_advertise_hosts? yes (matched "*")
250-domain.com Hello some.domain.com [11.22.33.44]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
AUTH PLAIN A[...]
>>> plain authenticator:
>>>   $1 = 
>>>   $2 = [email][email protected][/email]
>>>   $3 = password
>>> expanded string: 0
535 Incorrect authentication data
LOG: plain authenticator failed for (some.domain.com) 
[11.22.33.44]: 535 Incorrect authentication data ([email protected])
AUTH LOGIN
>>> host in smtp_accept_max_nonmail_hosts? yes (matched "*")
334 VXNlcm5hbWU6
Y[...]
334 UGFzc3dvcmQ6
N[...]
>>> login authenticator:
>>>   $1 = [email][email protected][/email]
>>>   $2 = password
>>> expanded string: yes
235 Authentication succeeded
MAIL FROM:<[email protected]>
250 OK
RCPT TO:<[email protected]>
>>> using ACL "check_recipient"
>>> processing "accept"
>>> check hosts = :
>>> host in ":"? no (end of list)
>>> accept: condition test failed
>>> processing "accept"
>>> check domains = +local_domains
>>> domain2.com in "lsearch;/etc/virtual/domains"? no (end of list)
>>> domain2.com in "+local_domains"? no (end of list)
>>> accept: condition test failed
>>> processing "accept"
>>> check domains = +relay_domains
>>> domain2.com in "lsearch;/etc/virtual/domains :
 localhost"? no (end of list)
>>> domain2.com in "+relay_domains"? no (end of list)
>>> accept: condition test failed
>>> processing "accept"
>>> check hosts = +relay_hosts
LOG: failed to open /etc/virtual/pophosts for linear search: 
No such file or directory

So, with the username and password getting put in $2 and $3 when using plain authentication - is that a problem with the mail client (Mozilla Thunderbird in this case, but Apple Mail does the same thing, and doesn't appear to do login authentication, so it won't relay), or with exim.pl?

Thanks,
Andy
 
Last edited:
Okay, one more reply to myself:

By editing exim.pl to have a second subroutine that has:

Code: 
$username       = Exim::expand_string('$2');
$password       = Exim::expand_string('$3');

and having the plain authenticator call that subroutine, I'm able to get plain authentication working.

Andy
 
does this work with using Apple Mail connecting to the IMAP instead of POP.

Also if I change these to $2 and $3 how will it affect clients which currently work with $1 and $2
 
does this work with using Apple Mail connecting to the IMAP instead of POP.
Click to expand...

If you are using IMAP, then da-popb4smtp does not enter your IP address in /etc/virtual/pophosts, so if you wish to relay through the server, you need to use authentication. Apple Mail, connecting to the DA server using IMAP, and sending mail using PLAIN authentication is a setup I frequently use.

Also if I change these to $2 and $3 how will it affect clients which currently work with $1 and $2
Click to expand...

As I understand the RFCs, no clients that use PLAIN auth will work with $1 and $2; that's why you need two subroutines, one for LOGIN auth, one for PLAIN auth.

See Exim's docs, and the RFC that describes PLAIN auth for more information.

Exim Specification - 34.2:

The PLAIN authentication mechanism (RFC 2595) specifies that three strings be sent as one item of data (that is, one combined string containing two NUL separators). The data is sent either as part of the AUTH command, or subsequently in response to an empty prompt from the server.

The second and third strings are a user name and a corresponding password.
Click to expand...

RFC 2595:

6. PLAIN SASL mechanism [...] The mechanism consists of a single message from the client to the server. The client sends the authorization identity (identity to login as), followed by a US-ASCII NUL character, followed by the authentication identity (identity whose password will be used), followed by a US-ASCII NUL character, followed by the clear-text password. The client may leave the authorization identity empty to indicate that it is the same as the authentication identity.
Click to expand...

Andy
 
Last edited:
This problem with Python (smtplib)

After receiving the same problem in Python with PLAIN authentification I resolved the problem adding to exim.pl the next piece of code:

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

#=== BEGIN ======================
# PLAIN authenticacion with Python
if ($username eq $password)
{
$username=$password;
$password=$extra;
}
#=== END ======================

#check for netscape that offsets the login/pass by one
.....

That resolved my problem:

--- BEFORE ---
AUTH PLAIN [...]
>>> plain authenticator:
>>> $1 = [email protected]
>>> $2 = [email protected]
>>> $3 = password
>>> expanded string: no
535 Incorrect authentication data
LOG: plain authenticator failed for localhost (mail.domain.dom) [127.0.0.1]: 535 Incorrect authentication data ([email protected])

--- AFTER ---
AUTH PLAIN [...]
>>> plain authenticator:
>>> $1 = [email protected]
>>> $2 = [email protected]
>>> $3 = password
>>> expanded string: yes
235 Authentication succeeded

1) Is there some security risk in the code that I added?

2) Am I loosing some usability of exim.pl with some email client because this code?

Thank you!
 
Authentification Security Bug?

Why exim.pl let me to authenticate with longer passwords that doesn't fix with the original one?

Example:

=== CONFIGURATION ===
[email protected] -> password1
[email protected] -> shortpassword
[email protected] -> p

=== ALL OF THIS CAN AUTHENTICATE WITH ===
[email protected] -> password1asdlkjf
[email protected] -> password1
[email protected] -> password11111
[email protected] -> password13414asdf
[email protected] -> password1mmmmmm

[email protected] -> shortpassword
[email protected] -> shortpassword234
[email protected] -> shortpasswordsdfas
[email protected] -> shortpassword34dfa
[email protected] -> shortpassworddsaf34
[email protected] -> shortpassword11111

[email protected] -> p
[email protected] -> perl
[email protected] -> pico
[email protected] -> paint
[email protected] -> pretty
[email protected] -> pdlkfjldksjf
[email protected] -> pasd0219u43
[email protected] -> psdlfakja234sadfsjf

Why don't you control the end of the password string?

Sincerely,
 
Re: Authentification Security Bug?

br0th3r said:
Why exim.pl let me to authenticate with longer passwords that doesn't fix with the original one?

...

Why don't you control the end of the password string?

Sincerely,
Click to expand...

From what I see in exim.pl, it does control the end of the string. It is using
Code: 
$crypted_pass eq crypt($password, $crypted_pass)
to do the test. The eq basically does a strcmp on the two strings. If your crypt is broken and returns the same crypted_pass for "p" as well as "psdlfakja234sadfsjf" then there is a problem with crypt. I tried it on my computer(s) and they all returned different values for both of them, so authentication would fail, if I tried to use "psdlfakja234sadfsjf" as the password if it shouldhave been "p".
 
Extrange...

When I tried was it from Python using PLAIN...I checked exim.pl and I have also the check for encrypted password....and there isn't "yes" if crypted password doesn't verify (so I have the same as you)...I don't understand what is going on.

The next script.perl:
1 $test_password="14e/uWSkOV5EI";
2
3 print crypt("antolina",$test_password); print "\n";
4 print crypt("antolina22",$test_password); print "\n";
5 print crypt("antolina33",$test_password); print "\n";
6 print crypt("antolina44",$test_password); print "\n";
7 print crypt("antolin",$test_password); print "\n";
8 print crypt("antolan",$test_password); print "\n";
9 print crypt("antolina",$test_password); print "\n";
10 print "\n";
11 print crypt($test_password,"anto"); print "\n";
12 print crypt($test_password,"anto222"); print "\n";
13 print crypt($test_password,"anto333"); print "\n";
14 print crypt($test_password,"anto"); print "\n";
15 print crypt($test_password,"adao"); print "\n";
16 print crypt($test_password,"anao"); print "\n";
17 print crypt($test_password,"anto"); print "\n";

After executing...gives the next list:
14e/uWSkOV5EI
14e/uWSkOV5EI
14e/uWSkOV5EI
14e/uWSkOV5EI
14O.BpeUGMN5c
14t1uFFwrBRH.
14e/uWSkOV5EI

ani8KERBZ0oO2
ani8KERBZ0oO2
ani8KERBZ0oO2
ani8KERBZ0oO2
adDpaeqwTSIlg
ani8KERBZ0oO2
ani8KERBZ0oO2

I tried this in 2 diferents machines (both from Debian Linux...first with pure Debian Linux, second with Kubuntu Linux)

Some ideas?

Sincerely,
 
I can see lines 11+ returning what you see, since you are only changing the salt, which this version of crypt only uses the first two characters. The fisrt lines, are working the way they do, because this version of crypt only uses the first 8 characters of the password to produce the encrypted string.
 
You must log in or register to reply here.
Back
Top