Page 1 of 1

[BUGFIX] SMTP Problem: "authentication failed: bad prot

Posted: Fri Apr 20, 2007 4:34 pm
by vanchuck
Hi there!

Swift Mailer Version 3.1.3
PHP 5.2.0 running on Debian 4.0

When connecting to my (remote) SMTP server, the server fails with a cryptic message: "authentication failed: bad protocol / cancel", regardless of SSL/TLS, PLAIN/LOGIN, etc.

The configuration of the SMTP server is:
- Debian 4.0
- Postfix 2.3.8
- SASL Authentication with PgSQL backend
- TLS, SSL both enabled

Because I use virtual users (also via the same PgSQL backend) on the mail server and use Postfix, it means that usernames must be specified in the "username@domain.tld" format, not just "username".

I tried manually connecting to the server and performing commands manually. I tried the well-documented format of "username@domain.tld\0username@domain.tld\0password", but got the same error.

I googled the above error and couldn't find anything useful, it seemed to be a very obscure problem. I figured it had to do with the @ character or something, but this ended up not being the case-- I'd get the error (via telnet:25) after entering even a simple character-only username. Interestingly I have Roundcube webmail set up and using SMTP/TLS to send emails to the same server without any problems, so after triple-checking settings, I figured Roundcube must be doing something differently to auth okay. After looking at the Roundcube source, it seems it uses the PEAR Net_SMTP lib. The string it uses to authenticate with PLAIN is as follows:

Code: Select all

$auth_str = base64_encode(chr(0) . $uid . chr(0) . $pwd);
Not only is the format different, but it is all base64_encode'd. I then modified Swift/Authenticator/PLAIN.php:34 to be the same:

Code: Select all

$credentials = base64_encode(chr(0) . $user . chr(0) . $pass);
And voilĂ ... it worked!

I checked the older versions of the Net_SMTP library, it seems the above way of doing it has been there since the first version in 2002. Net_SMTP is used by Horde and Roundcube, so it's probably safe to assume that the above method works fairly universally, though it's probably worth researching and double-checking.

Thought I would share my problem and solution in case it comes up for anyone else.

Cheers on the great package, looking forward to using it!
~vanchuck

Posted: Sat Apr 21, 2007 3:45 am
by Chris Corbyn
I'll get some tests together and patch that in with credit to yourself, thank you. I have just followed the RFC documentation to implement this and it worked for the servers I used. The only difference with your version is that you leave out the first parameter, whereas I duplicated username into the first parameter which is possibly having an adverse effect on your server.

Thanks for the patch tip :)

Posted: Sat Apr 21, 2007 3:57 am
by vanchuck
In my case, it seemed that it wasn't the order of the parameters-- in fact I just tried and it does work if you do "uid\0uid\0pwd". The problem seems to do with the character encoding-- for whatever reason it only works when the string (or any of the strings) are passed as a base64_encode'd string.

Not sure why, I couldn't find any information about it myself, but so it is! It could be it's just the "Debian way". Debian seems to have it's own way of doing a lot of things, sometimes I'm convinced it's done simply to be different.

Anyway, no need for credit, hopefully someone else will be saved some time. Happy to help wherever I can, even if it's just half a line of code ;-)

Posted: Sat Apr 21, 2007 4:11 am
by Chris Corbyn
No no you will be correct, base64 encoding responses is a common practise with authentication to ensure 7-bit transfer :)

The repository has been updated. I must be getting ready for a new release now ;)