Why does exim.pl use 1st & 2dn parameter for AUTH PLAIN when it should be 2nd & 3rd ?

[dkzr]

Why does exim.pl use 1st & 2dn parameter for AUTH PLAIN when it should be 2nd & 3rd ?

Hi,

It's been reported before and solutions have been posted, but why doen't exim.pl provide a fallback when an email client (like Apple Mail) offers a RFC valid AUTH PLAIN string?

A fallback for Netscape is already in place (exim.pl the smtpauth method around line 130). When changing this test to:

	#check for netscape and others that offsets the identity/login/pass by one
	if (length($extra) > 0)
	{
		$username = $password;
		$password = $extra;
	}

I have this working now on my server without problems. Shouldn't this be default for exim.pl ?

Background
The exim manual page on AUTH PLAIN explains that the client should send three strings combined:

<empty><NUL>username<NUL>mysecret

The RFC explains the first part should be the identity, so the string would be:

identity<NUL>username<NUL>mysecret

Now: Apple Mail first tries the RFC way, using:

username<NUL>username<NUL>mysecret

When this fails, it tries the Exim way with an empty first part.

Some previous relevant posts
http://forum.directadmin.com/showthread.php?t=33313
http://forum.directadmin.com/showthread.php?t=3936&p=24324#post24324

 

[nobaloney]

Are these inherited bugs from the upstream exim mainainers? Or are the introduced in the version used in DirectAdmin? If the former, then this forum may not be the best place to discuss it and since our version of exim.pl is only for use with DirectAdmin, we may not be the best folk to change it.

Have Dr Hazel and staff just not seen this for many years, or do they have a reason for doing what they do?

Over all these years, has this caused a problem with exim which needs to be fixed? Or in other words, does it make it impossible for certain senders to not be able to send email through our exim configuration?

Is this really for us to arbitrarily fix?

Or do you suggest we should be presenting it as a bug to the exim maintainers? If the latter, when I'd suggest you'd be the person to present it, since you're presenting it to us.

Or am I seeing it wrong; is the problem only in our exim.pl file?

Thanks.

Jeff

 

[dkzr]

Hi Jeff,

As far as I can see, the issue is with exim.pl. The configuration example of exim uses 2nd and 3rd parameter (see http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_plaintext_authenticator.html#SECID172 ). Also the RFC uses 2nd and 3rd (the text at http://tools.ietf.org/search/rfc4616#section-2 ).

Is there an upstream version of exim.pl? I could not find one in the Exim source, so I don't know if this is an upstream issue. If anybody can point me to the upstream I will check.

I guess 99.9 % of the time, the first parameter is empty anyway and everything works fine, but searching the forum I've seen several threads where people have issues related to this (see links in original post).

My personal experience using Apple Mail as primary mail client is that my mail log is full of authorization errors.
Combined with the CSF plugin, every location from which I send some mails gets blacklisted (but you can also blame that on the CSF settings, offcourse

My thinking was that, since there is a fix for Netscape in the exim.pl code, why not modify that to fix the above too?

Thanks,

Joost de Keijzer

 

[dkzr]

I see this issue has been resolved in exim.pl 17 (and 16). Great!