Unable to authenticate via `Zend\Mail\Protocol\Smtp\Auth\Plain`

Hello,

As far as I can tell I have followed the docs to the letter, but I am consistently getting 5.7.8 Error: authentication failed: which is not true because I have checked, double-checked and triple checked both username and password values and they are 110% correct.

Looking at my mailserver logs, zend-mail does not appear to be sending a username pam_unix(dovecot:auth): check pass; user unknown.

But, as I said, I'm doing everything by the letter of the docs, all the required parameters are passed:


        if (!$this->options = new SmtpOptions ([
            'name'  =>  "foo",
            'host'  =>  "foo",
            'port'  =>  25,
            'connection_class' => "plain",
            'connection_config' => [
                'username' => "foobar",
                'password' => "secretsquirrel",
                'ssl'      => "tls",
                'use_complete_quit' => "false"
        ],
        ])) { return false; }

I am therefore pretty sure that there is a bug of some sort in zend-mail preventing authentication from succeeding.

However, the apparent lack of debug functionality in zend-mail means I am left with little option but to dump zend-mail and use another PHP library instead.

Add debug functionality

What more could you need than the underlying layer's exception? The fact that you didn't provide a stack trace rather shows that you are unfamiliar with exception handling.

Well, the word "debug" gave you a hint !

How about being able to see what exactly zend-mail is sending to my server. You know, giving me the ability to debug.

It shows I am familiar with try{catch}. Your stacktrace was pretty unhelpful, but if you want it, here it is:


PHP Fatal error:  Uncaught Zend\Mail\Protocol\Exception\RuntimeException: 5.7.8 Error: authentication failed: 
 in /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Protocol/AbstractProtocol.php:350
Stack trace:
#0 /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Protocol/Smtp/Auth/Plain.php(78): Zend\Mail\Protocol\AbstractProtocol->_expect(Array)
#1 /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Protocol/Smtp.php(223): Zend\Mail\Protocol\Smtp\Auth\Plain->auth()
#2 /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Transport/Smtp.php(377): Zend\Mail\Protocol\Smtp->helo('my.example')
#3 /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Transport/Smtp.php(362): Zend\Mail\Transport\Smtp->connect()
#4 /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Transport/Smtp.php(373): Zend\Mail\Transport\Smtp->lazyLoadConnection()
#5 /usr/share/nginx/api/public/foobar/lib/vendor/zendfram in /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Protocol/AbstractProtocol.php on line 350

Fatal error: Uncaught Zend\Mail\Protocol\Exception\RuntimeException: 5.7.8 Error: authentication failed: 
 in /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Protocol/AbstractProtocol.php:350
Stack trace:
#0 /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Protocol/Smtp/Auth/Plain.php(78): Zend\Mail\Protocol\AbstractProtocol->_expect(Array)
#1 /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Protocol/Smtp.php(223): Zend\Mail\Protocol\Smtp\Auth\Plain->auth()
#2 /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Transport/Smtp.php(377): Zend\Mail\Protocol\Smtp->helo('my.example')
#3 /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Transport/Smtp.php(362): Zend\Mail\Transport\Smtp->connect()
#4 /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Transport/Smtp.php(373): Zend\Mail\Transport\Smtp->lazyLoadConnection()
#5 /usr/share/nginx/api/public/foobar/lib/vendor/zendfram in /usr/share/nginx/api/public/foobar/lib/vendor/zendframework/zend-mail/src/Protocol/AbstractProtocol.php on line 350

Your stacktrace was pretty unhelpful, but if you want it, here it is:

Given your stack trace, all you need is placing break points around these statements:

zend-mail/src/Protocol/Smtp/Auth/Plain.php

Lines 75 to 78 in 0e65a93

    
           $this->_send('AUTH PLAIN'); 
        
           $this->_expect(334); 
        
           $this->_send(base64_encode("\0" . $this->getUsername() . "\0" . $this->getPassword())); 
        
           $this->_expect(235);

That will give you all the info you need.

Putting the sent information in the exception is not viable, as that would lead consumers in outer layers (for example, loggers) to read that information, and therefore collect sensitive information (this is authentication, after all). If we did that, that would be a security issue.

You're just not listening are you.

(1) Why should I have to go hacking away in other people's libraries just to trobuleshoot and debug. It is POOR design.

(2) Don't give me that security rubbish excuse. As I said. The word is DEBUG. $debug=true="all data shown, warts and all" $debug=false="only basics, don't show sensitive stuff". You can tailor your exceptions and stack traces accordingly.

Sheesh. Just as well I'm not a commercial customer of Zend ! What poor software design.

(1) Why should I have to go hacking away in other people's libraries just to trobuleshoot and debug. It is POOR design.

There is no hacking involved at all: this is what you do with a breakpoint. The library is throwing an exception as expected.

(2) Don't give me that security rubbish excuse.

Security is the FIRST thing to keep in mind when designing software: everything else comes after that.

As I said. The word is DEBUG. $debug=true="all data shown, warts and all" $debug=false="only basics, don't show sensitive stuff". You can tailor your exceptions and stack traces accordingly.

This is something that I've never seen on any library/adapter that involves sending sensitive information to clients. If you need a logger, then inject one at __construct in the Smtp constructor. This would need a patch that you can gladly send.

As I suggested, the DEBUG you should do is placing a breakpoint in the affected lines (which I identified for you above).

Sheesh. Just as well I'm not a commercial customer of Zend !

This is not a commercial project, but a community project: you are talking to a volunteer that is gladly going to ignore your next non-constructive complaint. You are not my customer, you are just an internet rando that is asking for help, getting some help from myself (other internet rando) and then telling the person that is helping you that "You're just not listening are you.".

What poor software design.

You are talking about ~10 year old stable software that works just fine.

Given the comments above, I am hereby:

closing the issue
suggesting that you debug the issue as described above
inviting you to send a patch to Zend\Mail\Protocol\Smtp.php to allow usage of a PSR-3 logger (although it's not needed and likely to be rejected, in my opinion).

@udf2457 Just my mustard 😏

Don't be rude, this is a community.
Settings breakpoints is a better solution, than a debug log. Even with a debug log you may have to debug through..
Your auth.log excerpt is incomplete. Usually there are further lines, with ruser, so you would see the user. user unknown doesn't mean Zend Mail would not supply a username. It means the user could not be found in your user authentication db (pam this case). Also look into your mail.log/dovecot.log (depending on your setup)
Are you sure your dovecot server accepts PLAIN auth and doesn't require CRAM/DIGEST auth?
After that, check your authentication config of dovecot

And finally, if you would have debugged that line as directed instead of ranting around, you would have saved time, seen that username/pw is supplied (I'm 99% sure on that) and thus have known you need to look into dovecot or modify your config.

Again, why should I waste my time hacking away at other people's libraries. I've got enough code of my own to write and maintain. Plus what happens when you roll out a new version of your library ? Oh yeah, that's right, I've got to waste my time re-hacking all the debug stuff I've custom-coded to suit your new version. No thanks.

Also spare me trying to blame my setup. As I said at the start, I have triple checked everything AND it works perfectly well on any of the non-Zend mail libraries. So its nothing to do with my system, thank you very much.

Again, why should I waste my time hacking away at other people's libraries.

Why would we waste time helping you then? :-P

what happens when you roll out a new version of your library ? Oh yeah, that's right, I've got to waste my time re-hacking all the debug stuff I've custom-coded to suit your new version. No thanks.

I said "debugger": no code to be changed. I would never suggest editing vendor code, nor hotfixing it.

See https://www.sitepoint.com/debugging-and-profiling-php-with-xdebug/ for further pointers on what the suggested approach is (it will be helpful with other issues/tools too).

Setting a breakpoint is not hacking another people's library. It's setting a breakpoint in your IDE to look into the content of the variables sent and to verify your config is right. If this is sent to dovecot, it's your setup to blame. Sorry, that's a fact. A quick googling for your auth.log message primary shows all config errors.

Multiple considerations:

Dovecot doesn't accept PLAIN auth. You either have it restricted to LOGIN or CRAMMD5
With STARTTLS dovecot looks somewhere else (would feel crazy) or doesn't allow auth
Your auth configuration has a failure with plain auth (maybe errors in the SQL string...)

Look into your dovecot.log and provide it, otherwise you are not eligible to blame the project!

I would never suggest editing vendor code

A bit rich coming from the very person who pointed me vendor source code, gave me line numbers and told me to hack my own debug !

As said user unknown !== no user sent. user unknown === the provided user is not found in your user db!

A bit rich coming from the very person who pointed me vendor source code, gave me line numbers and told me to hack my own debug !

No, he said you should add a breakpoint here and see with xdebug which values you get there. That's not editing vendor code!

As said user unknown !== no user sent. user unknown === the provided user is not found in your user db!

And as I said. The user DOES exist. The username/password WORKS PERFECTLY WELL with non Zend libraries.

Please. Stop trying to pass the buck. The issue is with Zend.

As long as you don't show your full auth.log and mail.log/dovecot.log during the execution of your script, you're not eligible to blame Zend Mail. Show it and we can help further.

Otherwise I would recommend @Ocramius to close comments ^^

Good site tip: Post your problem on StackOverflow, but take care to read https://stackoverflow.com/help/how-to-ask first. Btw the "How to ask a good question?" also applies to GitHub issues if you want to get fast and good answers here.

You're not interested in helping. Its quite apparent. As I said, I'm now using a different PHP libary with the same username/password, and it works perfectly. You can figure out your own bugs.

I'm interested in helping, but we can only help if you provide the full logs and debug that line with xdebug to verify that the configured values are the one you configured.

Another possibility: You're setting the SMTP options on a different instance than you're using to send.

Another possibility: You're setting the SMTP options on a different instance than you're using to send.

That's a lame excuse and you know it.

Locking this: @patkar was trying to help and @udf2457 is obviously being abusive here. There's no need to help further, as all the necessary support was already given.

	$this->_send('AUTH PLAIN');
	$this->_expect(334);
	$this->_send(base64_encode("\0" . $this->getUsername() . "\0" . $this->getPassword()));
	$this->_expect(235);