Cant send test mail after upgrade to Nextcloud 17

Nextcloud version (eg, 17.0) : 17.0

Operating system and version (eg, Ubuntu 17) : 11.2-STABLE FreeBSD 11.2-STABLE #0 r325575+5920981193f(HEAD): Mon Sep 16 23:00:13 UTC 2019

Apache or nginx version (eg, Apache 2.4.25) : Server version: Apache/2.4.41 (FreeBSD)
PHP version (eg, 7.1) : PHP 7.2.23 (cli) (built: Oct 1 2019 01:15:37) ( NTS )

So I upgraded to Nextcloud 17 (argh. hate upgrades), and now the mail settings don’t work – such as when trying to send test mail in Basic Settings ->Email server

Nothing shows up in the logs at all, but here is the error I get when I push button “Send email”

A problem occurred while sending the email. Please revise your settings. (Error: Address in mailbox given [kevdog@] does not comply with RFC 2822, 3.6.2.)

I’m using gmail as the smtp server and I have enabled 2 step authentication and I’m using app specific password. It doesnt matter what I put in the credentials box – I can put any name since the error posted above is always shown. I’ve included by config.php and you can see the options at the bottom of the file" Do I rebuild the database or something? It’s really screwy?

$ sudo cat config.php
$CONFIG = array (
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/usr/local/www/nextcloud/apps',
      'url' => '/apps',
      'writable' => true,
    1 =>
    array (
      'path' => '/usr/local/www/nextcloud/apps-pkg',
      'url' => '/apps-pkg',
      'writable' => false,
  'logfile' => '/var/log/nextcloud/nextcloud.log',
  'loglevel' => '0',
  'logdateformat' => 'F d, Y H:i:s',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'instanceid' => 'ocny42d5quk3',
  'passwordsalt' => 'salt',
  'secret' => 'secret',
  'trusted_domains' =>
  array (
    0 => '',
    1 => '',
    2 => '',
    3 => '',
  'datadirectory' => '/mnt/data',
  'dbtype' => 'mysql',
  'version' => '',
  'overwrite.cli.url' => '',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost:/tmp/mysql.sock',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud_admin',
  'dbpassword' => 'pass',
  'installed' => true,
  'redis' =>
  array (
    'host' => '/tmp/redis.sock',
    'port' => 0,
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'maintenance' => false,
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'nextcloud-admin',
  'mail_domain' => '',
  'mail_smtphost' => '',
  'mail_smtpport' => '465',
  'mail_smtpauth' => 1,
  'mail_smtpsecure' => 'ssl',
  'mail_smtpname' => '',
  'mail_smtppassword' => 'pass',
  'theme' => '',
  'mail_smtpauthtype' => 'PLAIN',

Can you please show us which values you’ve entered as you sent email.

I interpret this message as if the domain part of the sender address is missing.


You would think your assumptions would be correct – because thats what I thought.

However I entered my real email address into the credentials box – But I still received the error kevdog@. I did some further investigating — I entered a bunch of different values into the field – another email address, a word, left it blank — and I always received the error message – kevdog@. I went and looked and the config.php with each change, and I noticed the mail_smtpname was never updated with each change – it was consistently and always ‘’. I then went manually into the config.php file and put in my entire email address – and same result. It’s like its pulling my name part of my email from a different location (a database perhaps???) rather than from the config.php file. I don’t know how to explain it since this should just work. Nothing shows up in the logs other than this message displayed in the GUI in red.

That’s the reason why I ask you to provide the parameters you’ve set under Settings > Maintenance > General > Email Server. There you have to enter an email domain in a separate field which might be used for sending that email:

But additionally it might be of importance, that I haven’t set “mail_smtpname” in my configuration but “mail_domain”.

Hopefully this helps. – I’m not sendmail but smtp
Although I do have postfix set up on the server which I could use as well

Does nextcloud smtp use php swiftmail? Something in cache isn’t being cleared. I totally changed by email settings as you can see in picture – yet I get the same exact error:


I solved the problem – however I don’t really understand the solution since the solution was a hack

Somewhere the php cache was being cleared properly. If I knew how to clear the php cache I would from command line. However when all else fails – reboot the machine – which worked.

If you know how to flush the php cache however that would be helpful for debugging. I can’t find any documentation anywhere how to do this, or what mailer nextcloud is using on the backend to make this go.

I made the experience, that if you use the standard php modules, a restart of your web server should be sufficient to clear the cache, but if you use php-fpm you need to restart this to get the cache cleared.

I don’t know a lot about php so I might be totally incorrect – but after changing entries in the email section – would it not be possible for the program to reset the cache at that point rather than waiting on a apache/nginx restart?

I think this is not a good idea, because Nextcloud is a multi instances/user environment and clearing the cache would impact all active users too. Therefore it is always better to let the system administrator decide, when the cache should be cleared.

It does. It’s possible that invalidation does not work if you change something via occ. The reason is that cli and php-fpm (or mod_php) does not share the same opcache.


This error is related to the recipient address. Test mail sends an email to the email address in your user profile. The from address seems to be fine

The problem was solved with a reboot, however if you read my post above, the recipient address was clearly specified both in the user profile and in the box where I typed the email address. I could type any address in the box and no matter what I typed I received the same error. Something was likely “stuck” somewhere – not sure where - but a restart of apache seemed to fix the problem.

Fine by me. Removed it from my previous post to not send people the wrong way. Thanks for the explanation :+1: