SMTP - authentication failure - (one more time...)

Support
1

What type of hardware are you using: Raspberry Pi 0, 1 or 2
What YunoHost version are you running: 12.1.39
How are you able to access your server: SSH
Are you in a special context or did you perform specific tweaking on your YunoHost instance ?: No

Describe your issue

Impossible to send email using SMTP server.

I already had a similar problem here ( SMTP - authentication failure - #9 )
, but i can not solve it now.

Please can somebody help?

Here is what i have already tried (many hours…)

  1. i have regened the initial conf with yunohost tools regen-conf dovecot postfix slapd -force
  2. I have changed /etc/postfix/main.cf and master.cf to get into debug mode , by changing the *loglevel directives
  3. I then changed /etc/dovecot/dovecot.conf to get into debug mode withlog_debug = (category=auth) OR (category=smtp)
  4. Here is my actual thoughts:

    1. postfix receives a connexion

    2. it opens a connexion with dovecot, as written in /etc/postfix/main.cf

    3. dovecot search in ldap for the sending user:

      1. see line ‘Performing passdb lookup’
      2. ldap request : bind search: base=ou=users,dc=yunohost,dc=org filter=(&(objectClass=inetOrgPerson)(uid=marc)(permission=cn=mail.main,ou=permission,dc=yunohost,dc=org))

    4. dovecot does not find and return (uid= marc; uid unused)

    5. But when i search in ldap with the same filter, it works:

      ldapsearch -x -LLL -b ou=users,dc=yunohost,dc=org ‘(&(objectClass=inetOrgPerson)(uid=marc)(permission=cn=mail.main,ou=permission,dc=yunohost,dc=org))'

Any idea?

Thanks in advance

Share relevant logs or error messages

2

Hi @marc,

I looked at the logs and the problem doesn’t seem to be related to the LDAP filter or permissions. The message uid=marc; uid unused is not an error, it’s a normal debug message.

The problem: slapd (LDAP) too slow

The timeline from the logs:

22:09:06 - Connection lost to LDAP server, reconnecting
22:09:06 - Can't connect to server: 127.0.0.1
22:09:25 - Dovecot starts LDAP lookup for SMTP
22:09:35 - Postfix gives up (10s timeout): "Connection lost to authentication server"
22:09:46 - Dovecot FINALLY completes the lookup successfully

Postfix waits a maximum of ~10 seconds for a response from Dovecot, but your LDAP query takes 10-20 seconds. Result: SMTP fails systematically, while IMAP works (because it’s more tolerant of delays).

To check

  1. slapd status:

    systemctl status slapd
journalctl -u slapd --since "1 hour ago" | tail -50

  2. Raspberry Pi resources (often the issue on Pi 1-2):

    free -h
uptime

  3. Restart slapd and test immediately:

    sudo systemctl restart slapd
sleep 5
sudo systemctl restart dovecot postfix

    Then try sending an email right away.

Questions:

  • How long has the server been running without a reboot?
  • Did the problem appear suddenly or did it degrade progressively?
  • Do you have enough RAM available? (free -h)

If slapd restarts and it works temporarily then degrades again, it’s probably a resource issue (RAM/swap) on the Raspberry Pi.

EDIT : traduction EN

3

Hi djez,

Thank you very much for your help. You analyze is fine and gives hope

Here are the results of the commands

  1. for

result:

● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
Loaded: loaded (/etc/init.d/slapd; generated)
Drop-In: /usr/lib/systemd/system/slapd.service.d
└─slapd-remain-after-exit.conf
/etc/systemd/system/slapd.service.d
└─ynh-override.conf
Active: active (running) since Tue 2026-01-20 22:29:37 GMT; 34min ago
Docs: man:systemd-sysv-generator(8)
Process: 28028 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
Tasks: 6 (limit: 1569)
CPU: 4min 5.581s
CGroup: /system.slice/slapd.service
└─28037 /usr/sbin/slapd -h “ldap://localhost:389/ ldaps:/// ldapi:///” -g openldap -u openldap -F /etc/ldap/slapd.d

for

see here https://paste.yunohost.org/raw/ibovavemid

  • for

$ free -h
total used free shared buff/cache available
Mem: 921Mi 401Mi 53Mi 25Mi 562Mi 519Mi
Swap: 511Mi 243Mi 268Mi
$ uptime
23:08:35 up 6 days, 2:07, 2 users, load average: 0.13, 0.19, 0.19

for

Still fails. See here: https://paste.yunohost.org/raw/owepodokeg

  • Dovecot needs 12 s for imap LDAP request (seen in another log file)
  • And you are right, request of POSTFIX fails before the end of LDAP request

Your questions:

  • i recently rebooted it

  • it degraded suddenly last week, when i de-installed LUFI. But i already had the same kind of problem, due to memory and number of threads, solved by changing some request parameters in nlscd.conf : see Impossible to connect to SSH or to SMTP

  • RAM available: 53Mi Mem, 268 Mi RAM

4

Hi marc,

Your logs confirm the issue: LDAP queries take 12-24 seconds, but Postfix gives up after ~10 seconds waiting for Dovecot’s response.

With only 53Mi free RAM and heavy swap usage, your Pi is struggling — same root cause as your October SSH issue.

Can you show me what’s consuming memory?

bash

ps aux --sort=-%mem | head -15

The real fix is to free up resources. Increasing timeouts would just be a band-aid on a resource problem.

5

Hi,

Here is the result:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql      742  0.2 11.0 560864 104024 ?       Ssl  13:25   0:02 /usr/sbin/mariadbd
root       572  0.9  3.3  54956 31756 ?        Ss   13:25   0:09 python3 /usr/bin/yunohost-api
root       548  2.0  3.2 232500 30480 ?        Ssl  13:25   0:19 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
sogo      1340  0.1  3.0  94884 28684 ?        Ss   13:25   0:01 /usr/sbin/sogod -WOWorkersCount 3 -WOPidFile /run/sogo/sogo.pid -WOLogFile /var/log/sogo/sog
ynh-por+   574  0.6  2.9  46968 27904 ?        Ss   13:25   0:06 python3 /usr/bin/yunohost-portal-api
sogo      1341  0.0  2.4  91132 23504 ?        Ss   13:25   0:00 /usr/sbin/sogod -WOWorkersCount 3 -WOPidFile /run/sogo/sogo.pid -WOLogFile /var/log/sogo/sog
sogo      1342  0.0  2.4  91136 23120 ?        Ss   13:25   0:00 /usr/sbin/sogod -WOWorkersCount 3 -WOPidFile /run/sogo/sogo.pid -WOLogFile /var/log/sogo/sog
sogo      1248  0.2  2.2  90052 21692 ?        S    13:25   0:02 /usr/sbin/sogod -WOWorkersCount 3 -WOPidFile /run/sogo/sogo.pid -WOLogFile /var/log/sogo/sog
vaultwa+   569  0.1  2.2 184660 20988 ?        Ssl  13:25   0:01 /var/www/vaultwarden/live/vaultwarden
root       556  0.0  2.2 210092 20980 ?        Ss   13:25   0:00 php-fpm: master process (/etc/php/8.3/fpm/php-fpm.conf)
www-data  1266  0.2  2.1 280284 20376 ?        S    13:25   0:02 nginx: worker process
www-data  1267  0.1  2.1 279700 20028 ?        S    13:25   0:01 nginx: worker process
root       558  0.0  2.0 208664 19784 ?        Ss   13:25   0:00 php-fpm: master process (/etc/php/8.4/fpm/php-fpm.conf)
root       566  0.1  1.9  40740 18116 ?        Ssl  13:25   0:01 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signa
mdns       929  0.2  1.8  44244 17784 ?        Ssl  13:25   0:02 python3 /usr/bin/yunomdns
root       519  0.1  1.7  63232 16928 ?        Ssl  13:25   0:01 /usr/sbin/NetworkManager --no-daemon
ntpsec     696  0.1  1.7  17596 16460 ?        SLs  13:25   0:01 /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec
root      1043  0.0  1.6  46024 15316 ?        Sl   13:25   0:00 python3 /usr/bin/yunohost-api
www-data  1269  0.0  1.5 278800 14948 ?        S    13:25   0:00 nginx: worker process
www-data  1270  0.0  1.5 278800 14904 ?        S    13:25   0:00 nginx: worker process

It se

It seems there are not many ways to free up resources:

  • SOGo is my webmail app
  • other services should be kept also i think

This problem reminds me that i had several problems when Yunohost team released the >10 versions of Yunohost.

As a matter of fact, i installed Yunohost on this Rapsberry Pi 2 , maybe in 2017. I had RAM problems with recent Yunohot versions: i noticed new debian versions use more and more RAM

When i reinstalled the whole server last july, after my SDCard crash, i could not event find the RPI2 Yunohost OS on the web! I had to find a workaround to reinstall it.

As a conclusion, i tried to resist to this Planned obsolescence of my raspberry PI2, but i go through many problems now. This is the signal: i probably have to buy another more recent RPI i guess

6

I tried to stop some services (Sogo, Posgresql, Mariadb).

I get this ram consumption:

           total        used        free      shared  buff/cache   available

Mem: 921Mi 303Mi 373Mi 19Mi 321Mi 617Mi
Swap: 511Mi 0B 511Mi

Free RAM is now 373 Mi instead of 53Mi

But sending email still fails. Is RAM really the issue?

Moreover, because of these RAM problems, i installed a cron task to log memory usage.

Here is the log information before SMTP issue, 2 weeks ago:

cron décenché à 20260107-07:40
           total        used        free      shared  buff/cache   available

Mem: 921Mi 489Mi 86Mi 11Mi 427Mi 432Mi
Swap: 511Mi 497Mi 14Mi

With only 86Mi left, it worked…That’a mystery then

7

Hi @marc
Can you try setting timelimit to 0 (indefinitely) in /etc/nslcd.conf for testing purpose ?

8

For this limited hardware specs, you should use a desktop/mobile email client and avoid making pressure on the machine. It can work but don’t expect it to do more than it can.

So remove “unnecessary” apps to allow it to breath.

(heavy load on sdcard will break it)

9

Hi @otm33

I tried timelimit=0 : same result

10

Hi @jarod5001

Thanks for the advice, i have very few apps working: SOGo, Jirafeau, Phpmyadmin, PhpLdapAdmin.

It worked fine until beginning of january. SD Card is recent (summer 2025).

So i wonder why it does not work anymore, since i removed Lufi.

I will try and reinstall Lufi , and also enter debug mode of Dovecot and nslcd if possible.

11

Autre possibilité à explorer: augmenter le timeout côté dovecot.
A tester :
ajout de auth_policy_server_timeout_msecs = 6000 (la valeur par défaut est 2000 ms) à la fin de /etc/dovecot/dovecot.conf et redémarrage de dovecot.
Même si cela change quelque chose, ce sera écrasé par regenconf… (à moins qu’un fichier d’override existe qq part ?)

12

test effectué. Sans résultat.