Mail stopped working

igordashaar · December 17, 2023, 3:18pm

Nextcloud version (eg, 20.0.5): 27.1.5
Operating system and version (eg, Ubuntu 20.04): Ubuntu 22.04.3 LTS
Apache or nginx version (eg, Apache 2.4.25): Apache/2.4.52
PHP version (eg, 7.4): PHP 8.1.2-1ubuntu2.14

The mail stopped working some time ago, maybe with switch to NC26, but I noticed it just now, as there has not been any error message.
I now notice that no invitations are sent for calendar events and I cannot send a test mail using the configuration. The same configuration used to work and I did not change anything for the configuration besides updating the server.

Is this the first time you’ve seen this error? (Y/N): Yes

Steps to replicate it:

Enter credentials under Administration Settings → Basic settings → Email server
Send email
Get error message: “A problem occurred while sending the email. Please revise your settings. (Error: Email could not be sent. Check your mail server log)”

I am not sure which “mail server log” I could check. The mail server is a remote server. I checked the credentials with a seperate mail program (thunderbird) to verify the settings are working.

The output of your Nextcloud log in Admin > Logging:

no corresponding error/debugging messages in logging

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => '***removed sensitive information***',
  'passwordsalt' => '***removed sensitive information***',
  'secret' => '***removed sensitive information***',
  'trusted_domains' =>
  array (
    0 => '***removed sensitive information***',
    1 => '192.168.0.*',
    2 => '***removed sensitive information***',
    3 => '10.8.0.*',
  ),
  'datadirectory' => '/media/data/nextcloud',
  'dbtype' => 'mysql',
  'version' => '27.1.5.1',
  'overwrite.cli.url' => '***removed sensitive information***',
  'htaccess.RewriteBase' => '/',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'user_nc',
  'dbpassword' => '***removed sensitive information***',
  'installed' => true,
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => 'localhost',
    'port' => 6379,
    0 => 'timeout => 0.0',
  ),
  'simpleSignUpLink.shown' => false,
  'app_install_overwrite' =>
  array (
    0 => 'dicomviewer',
    1 => 'joplin',
    2 => 'files_3d',
    3 => 'whiteboard',
    4 => 'previewgenerator',
    5 => 'ehr',
    6 => 'spreed',
    7 => 'health',
    8 => 'ransomware_protection',
    9 => 'maps',
  ),
  'updater.release.channel' => 'stable',
  'default_phone_region' => 'DE',
  'updater.secret' => '***removed sensitive information***',
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'nameBeforeTheAtSymbol',
  'mail_domain' => 'domain.com',
  'mail_smtphost' => 'smtp.domain.com',
  'mail_smtpport' => '465',
  'mail_smtpauth' => 1,
  'mail_smtpname' => 'nameBeforeTheAtSymbol@domain.com',
  'mail_smtppassword' => '***removed sensitive information***',
  'mail_smtpsecure' => 'ssl',
);

Mornsgrans · December 17, 2023, 7:34pm

Check the mailserver logs resp. (if not your own mail serer) check the FAQ. Depending on the mail server provider sometimes the settings may be changed or more resrticted (like Google mail) to prevent spam or account hacking.

igordashaar · December 17, 2023, 8:46pm

Seems my mailprovider (goneo.de) does not show any error logs.
I tried with different credentials of another SMTP server (not goneo) and it worked. Any idea what might be the problem?

ernolf · December 17, 2023, 9:10pm

igordashaar:

  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'nameBeforeTheAtSymbol',
  'mail_domain' => 'domain.com',
  'mail_smtphost' => 'smtp.domain.com',
  'mail_smtpport' => '465',
  'mail_smtpauth' => 1,
  'mail_smtpname' => 'nameBeforeTheAtSymbol@domain.com',
  'mail_smtppassword' => '***removed sensitive information***',
  'mail_smtpsecure' => 'ssl',

Give this a try:

  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'nameBeforeTheAtSymbol',
  'mail_domain' => 'domain.com',
  'mail_smtphost' => 'smtp.domain.com',
  'mail_smtpport' => '587',
  'mail_smtpauth' => 1,
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpname' => 'nameBeforeTheAtSymbol@domain.com',
  'mail_smtppassword' => '***removed sensitive information***',
  'mail_smtpsecure' => '',

That will send your mail using STARTTLS.
Starttls is the successor of the old ssl and should normally work better.

I hope that it works for you!

Much luck,
ernolf

igordashaar · December 18, 2023, 8:46am

Thanks for your suggestion! Unfortunately no luck. Also tried changing to STARTTLS in the web interface but the error message stays the same.

igordashaar · December 18, 2023, 9:05am

Found another user with the same issue:

Solution: disable IPV6 https://linuxconfig.org/how-to-disable-ipv6-address-on-ubuntu-22-04-lts-jammy-jellyfish

found out by trying to ping my smtp adress.
ping smpt.domain.com resultet in a timeout.
ping -4 smpt.domain.com worked.

bb77 · December 18, 2023, 9:30am

Well, yes and no. Actually, since it has been officially standardised, SMTPS over port 465 for submission (client to server communication) could be called the successor to STARTTLS, although both have been around for a long time and both are still in use. However, neither of them is a successor to the “old” SMTPS over port 465, which was originally registered as the “smtps” port for server to server communication.

I’ve have written something about this in another forum, and I’m just pasting it here… I’s actually kind of intersting.

Historically port 465 was briefly registered for “smtps” (sever to server), which didn’t make much sense, as SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. As a result, the registration was revoked and was subsequently reassigned to a protocol called “urd”. So far so good…

However, as widely used email software began to use port 465 for “Submission over TLS” (client to server with Implicit TLS), the port became a de-facto standard for this use case which then led to RFC 8314, a one-time procedural exception, that assigned “Submission over TLS” to Port 465, even though the port was already assigned to another protocol.

Sources:

465 This port was deprecated after RFC 2487, until the issue of RFC 8314.

IANA has assigned an alternate usage of TCP port 465 in addition to the current assignment using the following template [RFC6335]:

Service Name: submissions
Transport Protocol: TCP
Assignee: IESG iesg@ietf.org
Contact: IETF Chair chair@ietf.org
Description: Message Submission over TLS protocol Reference: RFC 8314
Port Number: 465

This is a one-time procedural exception to the rules in [RFC6335]. This requires explicit IESG approval and does not set a precedent. Note: Since the purpose of this alternate usage assignment is to align with widespread existing practice and there is no known usage of UDP port 465 for Message Submission over TLS, IANA has not assigned an alternate usage of UDP port 465.

Historically, port 465 was briefly registered as the “smtps” port. This registration made no sense, as the SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. As a result, the registration was revoked and was subsequently reassigned to a different service. In hindsight, the “smtps” registration should have been renamed or reserved rather than revoked. Unfortunately, some widely deployed mail software interpreted “smtps” as “submissions” [RFC6409] and used that port for email submission by default when an end user requested security during account setup. If a new port is assigned for the submissions service, either (a) email software will continue with unregistered use of port 465 (leaving the port registry inaccurate relative to

Port 465 is presently used for two purposes: for submissions by a large number of clients and service providers and for the “urd” protocol by one vendor. Actually documenting this current state is controversial, as discussed in the IANA Considerations section. However, there is no good alternative. Registering a new port for submissions when port 465 is already widely used for that purpose will just create interoperability problems. Registering a port that’s only used if advertised by an SRV record (RFC 6186) would not create interoperability problems but would require all client deployments, server deployments, and software to change significantly, which is contrary to the goal of promoting the increased use of TLS. Encouraging the use of STARTTLS on port 587 would not create interoperability problems, but it is unlikely to have any impact on the current undocumented use of port 465 and makes the guidance in this document less consistent. The remaining option is to document the current state of the world and support future use of port 465 for submission, as this increases consistency and ease of deployment for TLS email submission.

system · December 26, 2023, 9:31am

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.