# Mail stopped working

**URL:** <https://help.nextcloud.com/t/mail-stopped-working/176896>\
**Category:** ℹ️ Support\
**Created:** [December 17, 2023, 3:18pm UTC](https://help.nextcloud.com/t/mail-stopped-working/176896 "2023-12-17T15:18:16Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![igordashaar](https://help.nextcloud.com/letter_avatar/igordashaar/32/6_22734026db12803ebb3e059622ac3534.png) [@igordashaar](https://help.nextcloud.com/u/igordashaar)\
**Post date:** [December 17, 2023, 3:18pm UTC](https://help.nextcloud.com/t/mail-stopped-working/176896/1 "2023-12-17T15:18:16Z")

</div>

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:

1. Enter credentials under Administration Settings → Basic settings → Email server
2. Send email
3. 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.

 ![grafik](https://help.nextcloud.com/uploads/default/original/3X/3/a/3a1ffc5185754543c8a3939208e342a91b75f279.png)

The output of your Nextcloud log in **Admin \> Logging** :

```auto
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!):

```auto
<?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',
);
```

---

<div class="post-metadata">

**Author:** ![Mornsgrans](https://help.nextcloud.com/user_avatar/help.nextcloud.com/mornsgrans/32/40386_2.png) [@Mornsgrans](https://help.nextcloud.com/u/Mornsgrans)\
**Post date:** [December 17, 2023, 7:34pm UTC](https://help.nextcloud.com/t/mail-stopped-working/176896/2 "2023-12-17T19:34:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![igordashaar](https://help.nextcloud.com/letter_avatar/igordashaar/32/6_22734026db12803ebb3e059622ac3534.png) [@igordashaar](https://help.nextcloud.com/u/igordashaar)\
**Post date:** [December 17, 2023, 8:46pm UTC](https://help.nextcloud.com/t/mail-stopped-working/176896/3 "2023-12-17T20:46:34Z")

</div>

Seems my mailprovider ([goneo.de](http://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?

---

<div class="post-metadata">

**Author:** ![ernolf](https://help.nextcloud.com/user_avatar/help.nextcloud.com/ernolf/32/77874_2.png) [@ernolf](https://help.nextcloud.com/u/ernolf)\
**Post date:** [December 17, 2023, 9:10pm UTC](https://help.nextcloud.com/t/mail-stopped-working/176896/4 "2023-12-17T21:10:35Z")

</div>

> [@igordashaar](#):
>
> ```auto
> '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:

```auto
  '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

---

<div class="post-metadata">

**Author:** ![igordashaar](https://help.nextcloud.com/letter_avatar/igordashaar/32/6_22734026db12803ebb3e059622ac3534.png) [@igordashaar](https://help.nextcloud.com/u/igordashaar)\
**Post date:** [December 18, 2023, 8:46am UTC](https://help.nextcloud.com/t/mail-stopped-working/176896/5 "2023-12-18T08:46:01Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![igordashaar](https://help.nextcloud.com/letter_avatar/igordashaar/32/6_22734026db12803ebb3e059622ac3534.png) [@igordashaar](https://help.nextcloud.com/u/igordashaar)\
**Post date:** [December 18, 2023, 9:05am UTC](https://help.nextcloud.com/t/mail-stopped-working/176896/6 "2023-12-18T09:05:29Z")

</div>

Found another user with the same issue:

> [@Mail client cannot connect to SMTP server](https://help.nextcloud.com/t/mail-client-cannot-connect-to-smtp-server/175493):
>
> Nextcloud version: 27.1.3 (Snap) Operating system and version: Ubuntu 22.04 Apache or nginx version: Don’t know PHP version: Don’t know I have just set up a new Nextcloud instance using the snap package and everything but the SMTP mailer works flawlessly. When I try to test my settings using the “send email” button, I always get the response "A problem occurred while sending the email. Please revise your settings. (Error: Email could not be sent. Check your mail server log)" … after some…

Solution: disable IPV6 [https://linuxconfig.org/how-to-disable-ipv6-address-on-ubuntu-22-04-lts-jammy-jellyfish](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.

---

<div class="post-metadata">

**Author:** ![bb77](https://help.nextcloud.com/letter_avatar/bb77/32/6_22734026db12803ebb3e059622ac3534.png) [@bb77](https://help.nextcloud.com/u/bb77)\
**Post date:** [December 18, 2023, 9:30am UTC](https://help.nextcloud.com/t/mail-stopped-working/176896/7 "2023-12-18T09:30:31Z")

</div>

> [@ernolf](#):
>
> Starttls is the successor of the old ssl and should normally work better.

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:

> **[Simple Mail Transfer Protocol | Ports](https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#Ports)**
>
> Communication between mail servers generally uses the standard TCP port 25 designated for SMTP.
> Mail clients however generally don't use this, instead using specific "submission" ports. Mail services generally accept email submission from clients on one of:
> 1.465 This port was deprecated after RFC 2487, until the issue of RFC 8314. |
> 2.587 (Submission), as formalized in RFC 6409 (previously RFC 2476) Port 2525 and others may be used by some individual providers, but have never been officially ...

> 465 This port was deprecated after [RFC](https://en.wikipedia.org/wiki/RFC_(identifier)) [2487](https://datatracker.ietf.org/doc/html/rfc2487), until the issue of [RFC](https://en.wikipedia.org/wiki/RFC_(identifier)) [8314](https://datatracker.ietf.org/doc/html/rfc8314).

> **[RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security...](https://datatracker.ietf.org/doc/html/rfc8314#section-7.3)**
>
> RFC 8314 RFC - Proposed Standard | This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail...

> IANA has assigned an alternate usage of TCP port 465 in addition to the current assignment using the following template [[RFC6335](https://datatracker.ietf.org/doc/html/rfc6335)]:

> Service Name: submissions  
> Transport Protocol: TCP  
> Assignee: IESG [iesg@ietf.org](mailto:iesg@ietf.org)  
> Contact: IETF Chair [chair@ietf.org](mailto:chair@ietf.org)  
> Description: Message Submission over TLS protocol Reference: [RFC 8314](https://datatracker.ietf.org/doc/html/rfc8314)  
> Port Number: 465

> This is a one-time procedural exception to the rules in [[RFC6335](https://datatracker.ietf.org/doc/html/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](https://datatracker.ietf.org/doc/html/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

> **[RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security...](https://datatracker.ietf.org/doc/html/rfc8314#appendix-A)**
>
> RFC 8314 RFC - Proposed Standard | This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail...

> 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.

---

<div class="post-metadata">

**Author:** ![system](https://help.nextcloud.com/user_avatar/help.nextcloud.com/system/32/29333_2.png) [@system](https://help.nextcloud.com/u/system)\
**Post date:** [December 26, 2023, 9:31am UTC](https://help.nextcloud.com/t/mail-stopped-working/176896/8 "2023-12-26T09:31:17Z")

</div>

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