MailPlus Erfahrungen mit Upgrde MAilPlus und MailPlus Server auf 3.4.0

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

FR_NAS

Benutzer
Registriert
02. Jan. 2021
Beiträge
88
Reaktionspunkte
12
Punkte
8
Hallo,

ich habe bisher noch ncith auf Version 3.4.0 upgegradet, weil ich erst mal abwarten wollte, was hinsichtlich Funktionen, Stabilität und Updateprozess berichtet wird. Allerdings sehe ich hier bisher kaum Berichte. Wenn Jemand, der das Produktiv einsetzt mal berichten könnte, ob das Update zu Problemen geführt hat.
 
Hi, läuft seit der Veröffentlichung problemlos
 
Was ist mit dem tcp6 listener? Startet er jetzt von alleine oder muss man wieder die Datei /volumex/@appstore/MailPlus-Server/etc/template/10-master.template anpassen?

Man kann ja mit: netstat -an | grep 993 feststellen, ob der tcp6 listener läuft.

tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN
tcp6 0 0 :::993 :::* LISTEN
 
Was ist mit dem tcp6 listener? Startet er jetzt von alleine oder muss man wieder die Datei /volumex/@appstore/MailPlus-Server/etc/template/10-master.template anpassen?

Man kann ja mit: netstat -an | grep 993 feststellen, ob der tcp6 listener läuft.

tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN
tcp6 0 0 :::993 :::* LISTEN
Habe es natürlich selbst getestet. Zwar wurde die Datei /volumex/@appstore/MailPlus-Server/etc/template/10-master.template verändert (eine andere Konstante wird nun zugewiesen). Aber der listener startet immer noch nicht.

Das ist schon arm, wenn man bedenkt, dass IPv6 seit über 10 Jahren existiert. Es kann doch nicht so schwer sein, die richtige Adresse in der config zuzuweisen. Der listener existiert ja und funktioniert!
 
Per Ticket an Synology gemeldet?
 
Ja, im Dezember 2024 unter der Ticketnummer #3714541 mit folgender Antwort:

Code:
"Jerry H. 2024-11-29 11:20:39
Hi Ralf,
Thank you for contacting Synology Support. Bitte erlauben Sie uns Ihnen in Englisch sowie mit einer mehrsprachige Google Übersetzung zu antworten, da unser Support aktuell ausgelastet ist. Wie bereits erwähnt, handelt es sich in der Tat um eine derzeitige Einschränkung des MailPlus Servers, der IPv6 nach Bestätigung durch die Entwicklungsingenieure nicht unterstützt.
Sie können trotzdem versuchen, die von Ihnen erwähnte Änderung vorzunehmen, aber wir können nicht garantieren, dass sie wie erwartet funktioniert und keine unerwarteten Probleme verursacht. Wenn es Ihnen nicht möglich ist, eine IPv4-WAN-Verbindung zu aktivieren, dann müssen Sie in diesem Fall leider den Mail Server anstelle des MailPlus Servers verwenden.
== Please allow us to reply in English along with Google Translation as multilingual support is limited at this time. ==
As mentioned previously, it is indeed a current limitation of MailPlus Server not supporting IPv6 after confirmation from development engineers.
You can still try to perform the modification mentioned in your previously, but we cannot guarantee it will work as expected and will not cause any unexpected issues. If it is not possible for you to activate IPv4 WAN connection, then I am afraid you will need to use Mail Server instead of MailPlus Server in this case. Sorry for the inconvenience caused. Hope this helps and please let us know if further assistance is needed.
Best Regards, Technical Support Jerry Hsu"
Seither ist natürlich nichts passiert, außer dass der Mail Server jetzt eingestellt wird :)
 
  • Like
Reaktionen: maxblank
Das ist natürlich bitter…
 
Die Antwort des Supporters ist natürlich Unsinn. Denn, wie oben erwähnt, läuft der listener ja, wenn man ihn in der config aktiviert.
 
Hallo Zusammen,
ich ärgere mich schon, dass ich auf die neueste Version upgedatet habe. Jetzt habe ich wieder einen (alten, schon mal behobenen) Fehler im MailPlus (nicht Server): nach einer nicht nachvollziehbaren Zeit ruft MailPlus keine externen Mails mehr per POP3 ab. So ein Ärger! Damals bin ich zurück auf Synology Mail Server und Mail Station (beide funktionieren auch mit IPv6!). Das ist aber sinnlos geworden, da ja beide nicht weiter entwickelt und abgekündigt sind.

Dieser Abruf wird ja von jedem Benutzer im MailPlus Client eingerichtet. Wenn der Abruf unterbrochen wurde, dann hilft nur: MailPlus Client öffnen, POP3-Abruf öffnen. Jeden Eintrag zur Bearbeitung aufrufen und wieder speichern. Danach startet der POP3 Abruf wieder.

Weiß jemand, welcher Prozess sich dahinter verbirgt und wie man diesen vielleicht per Shell restarten könnte? Dann könnte ich zumindest per Aufgabenplaner diesen Prozess regelmäßig neu starten. MaiPlus neu zu starten ist leider keine Lösung.

VG
 
Das Kommando:

führt zu folgender Ausgabe:
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN
tcp6 0 0 :::993 :::* LISTEN
tcp6 0 0 2a00:6xxx:xxxx:xxxx:993 2a00:6xxx:xxxx:49:63123 ESTABLISHED
tcp6 0 0 2a00:6xxx:xxxx:xxxx:993 2a00:6xxx:xxxx:xx49:63122 ESTABLISHED
tcp6 0 0 2a00:6xxx:xxxx:xxxx:993 2a00:6xxx:xxxx:xx:49:63149 ESTABLISHED

Die Ausgabe mit "ESTABLISHED" habe ich noch nie gesehen. Ist das gut oder schlecht?

VG
 
Was ich beobachten konnte:

im Ordner /volume1/MailPlus/@local/<userid>/<userid>/.SYNOMC liegen folgende Dateien:

mailclient_fetchmail.pid
mailclient_pop3_fetch
proc.xxx.xxx.gmail.com (und weitere mit der abzufragenden Mailadresse)

In mailclient_fetchmail.pid steht die pid des Prozesse fetchmail und die gruppenid (??).

Wenn dieser Prozess beendet wurde (abgebrochen ist), dann werden keine Mails mehr per pop3 geholt.

Leider konnte ich nicht herausfinden, wie ich fetchmail (mit den passenden Parametern) starte. Hat hier jemand Erfahrung?
 
Ist das gut oder schlecht?
Ein Client hat sich per IPv6 verbinden können. Du müsstest anhand der IPv6-Adresse doch herausfinden können, ob das eines von deinen Geräten ist.

Ich setze weder Mail Server noch MailPlus Server ein, da kann ich dir also - wenn überhaupt - nur sehr allgemein helfen.
Ich würde mal auf dem NAS nach Log-Dateien suchen (etwa mit sudo find /volume1 -type f -name "*.log") und diese dann nach Meldungen von fetchmail durchsuchen. Vielleicht findest Du so die Ursache für den Abbruch von fetchmail.
Vielleicht findest Du auch heraus, wenn Du .sh-Skripte nach Aufrufen von fetchmail durchsuchst, wie man fetchmail starten muss.
 
  • Like
Reaktionen: RalfPeter
Ich habe mit
ps aux | grep fetchmail

folgendes gefunden:
Ralf 21244 0.0 0.0 6576 5468 ? Ss 15:19 0:00 /var/packages/MailClient/target/bin/fetchmail -f /var/spool/mail/@local/1029/1029/.SYNOMC/mailclient_pop3_fetch --pidfile /var/spool/mail/@local/1029/1029/.SYNOMC/mailclient_fetchmail.pid --idfile /var/spool/mail/@local/1029/1029/.SYNOMC/mailclient_fetchmail.id

hilft mir das weiter? Ich weiß zumindest, dass fetchmail in /var/packages/MailClient/target/bin/fetchmail installiert ist. Nach einem Neustart der Synology startet fetchmail nicht von alleine, wenn es zuvor beendet war. :-(
 
Du könntest noch mit ps auxe ... prüfen, ob der Prozess ein spezielles Environment hat und ansonsten einfach den Prozess neu starten unter dem Benutzer "Ralf" mit der gefundenen Zeile aus #14.
Wenn er nicht läuft, ist dann das .pid-File leer oder nicht-existent? Dann hättest Du eine einfache Erkennung, ob er noch läuft. Ansonsten die Ausgabe von ps parsen.
 
Also mit dem Kommando (von oben) startet fetchmail wieder und legt eine Datei mailclient_fetchmail.pid an. Diese enthält die pid des Prozesses.
 
Jetzt muss ich noch suchen, wo fetchmail Fehlermeldungen ablegt. Aber für den Übergang kann ich fetchmail per Aufgabenplaner starten, wenn die Datei mailclient_fetchmail.pid fehlt.
 
Ich habe jetzt ein Skript, dass fetchmail überwacht, ggfls alte Prozesse killed und einen neuen Prozess je User aufsetzt. Als Übergang, bis ich die Ursache gefunden habe, scheint es zu helfen.

Wer das gleiche Problem hat, mag es für sich anpassen:


Code:
#!/bin/sh

###############################################################################
# Fetchmail Watchdog – Multi UID mit Username-Ermittlung (Synology DSM 7.3)
# Mit Debug, hängende Prozesse killen, maximal 1 Prozess pro User,
# und Mail-Benachrichtigung bei Neustart
###############################################################################

FETCHMAIL_BIN="/var/packages/MailClient/target/bin/fetchmail"
# /volume1/MailPlus ist verlinkt zu /var/spool/mail
BASE_DIR="/var/spool/mail/@local"

###############################################################################
# Customizing
###############################################################################
# Debug: 1 = ja, 0 = nein
DEBUG=1
# Neustart-Schutz in Sekunden
RESTART_GAP=0
# Zu überwachende User-IDs
USER_IDS="1020 1021"
# Mail-Empfänger für Benachrichtigung
MAIL_TO="ich.meinname@mailprovider.de"
# Logdir und Logfile
LOGDIR="/volume1/sonstiges/protokolle"
LOGFILE="${LOGDIR}/fetchmail-watchdog-multi-$(date '+%Y').log"


###############################################################################
# Logging
###############################################################################

log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S')  $1" >> "$LOGFILE"
}

[ -d "$LOGDIR" ] || mkdir -p "$LOGDIR"

###############################################################################
# Funktion: Username aus UID ermitteln (DSM 7.3)
###############################################################################

get_username() {
    local uid="$1"
    synouser --getuid "$uid" 2>/dev/null | awk -F'[][]' '/User Name/{print $2}'
}

###############################################################################
# Funktion: Debug-Ausgabe aller laufenden fetchmail-PIDs eines Users
###############################################################################

debug_fetchmail_pids() {
    local username="$1"
    local pids
    # ps zeigt alle Prozesse des Users, grep filtert fetchmail, awk extrahiert die PID
    pids=$(ps -u "$username" -o pid,cmd | grep '[f]etchmail' | awk '{print $1}')
    if [ -n "$pids" ]; then
        log "DEBUG: Laufende fetchmail-PIDs für $username: $pids"
    else
        log "DEBUG: Keine laufenden fetchmail-PIDs für $username"
    fi
}

###############################################################################
# Funktion: hängende fetchmail-Prozesse beenden
###############################################################################

kill_hanging_fetchmail() {
    local username="$1"
    local pid
    for pid in $(ps -u "$username" -o pid,cmd | grep '[f]etchmail' | awk '{print $1}'); do
        if kill -0 "$pid" 2>/dev/null; then
            log "INFO: Beende hängenden fetchmail-Prozess $pid für $username"
            kill "$pid" 2>/dev/null
            sleep 1
            if kill -0 "$pid" 2>/dev/null; then
                log "WARN: Prozess $pid reagiert nicht – zwingend kill -9"
                kill -9 "$pid" 2>/dev/null
            fi
        fi
    done
}

###############################################################################
# Funktion: Mail senden bei Neustart
###############################################################################

send_restart_mail() {
    local user_id="$1"
    local username="$2"
    local pid="$3"
    local subject="DS1621plus: fetchmail Watchdog: Neustart für $username"
    local body="fetchmail wurde für User $username neugestartet. Neue PID: $pid"
    echo "$body" | mail -s "$subject" "$MAIL_TO"
    log "UID ${user_id} (${username}): Benachrichtigung gesendet an $MAIL_TO"
}

###############################################################################
# Hauptschleife
###############################################################################

log "--------------------------------------------------"

for USER_ID in $USER_IDS; do
    USERNAME=$(get_username "$USER_ID")

    if [ -z "$USERNAME" ]; then
        log "UID ${USER_ID}: FEHLER – kein Benutzer gefunden"
        continue
    fi

    USER_DIR="${BASE_DIR}/${USER_ID}/${USER_ID}/.SYNOMC"

    CONFIG_FILE="${USER_DIR}/mailclient_pop3_fetch"
    PIDFILE="${USER_DIR}/mailclient_fetchmail.pid"
    IDFILE="${USER_DIR}/mailclient_fetchmail.id"
    LAST_START_FILE="${USER_DIR}/.fetchmail_last_start"

    if [ ! -f "$CONFIG_FILE" ]; then
        log "UID ${USER_ID} (${USERNAME}): keine Config-Datei – übersprungen"
        continue
    fi

    RUNNING=0

    ###########################################################################
    # 1. PID-Datei prüfen
    ###########################################################################

    if [ -f "$PIDFILE" ]; then
        PID=$(head -n1 "$PIDFILE" | tr -d '[:space:]')
        if [ -n "$PID" ] && kill -0 "$PID" 2>/dev/null; then
            log "UID ${USER_ID} (${USERNAME}): fetchmail läuft (PID $PID)"
            RUNNING=1
        else
            log "UID ${USER_ID} (${USERNAME}): ungültige PID-Datei (PID $PID) – wird entfernt"
            rm -f "$PIDFILE"
        fi
    fi

    ###########################################################################
    # 2. Prozessprüfung als Fallback
    ###########################################################################

    if [ $RUNNING -eq 0 ]; then
        PID=$(ps -u "$USERNAME" -o pid,cmd | grep "[f]etchmail.*$(basename "$CONFIG_FILE")" | awk '{print $1}' | head -n1)
        if [ -n "$PID" ]; then
            log "UID ${USER_ID} (${USERNAME}): fetchmail läuft ohne PID-Datei (PID $PID)"
            RUNNING=1
        fi
    fi

    ###########################################################################
    # Debug-Ausgabe
    ###########################################################################

    if [ "$DEBUG" -eq 1 ]; then
        debug_fetchmail_pids "$USERNAME"
    fi

    ###########################################################################
    # Neustart-Schutz
    ###########################################################################

    if [ $RUNNING -eq 0 ] && [ "$RESTART_GAP" -gt 0 ]; then
        NOW=$(date +%s)
        if [ -f "$LAST_START_FILE" ]; then
            LAST_START=$(cat "$LAST_START_FILE" 2>/dev/null || echo 0)
            ELAPSED=$((NOW - LAST_START))
            if [ $ELAPSED -lt $RESTART_GAP ]; then
                REMAIN=$((RESTART_GAP - ELAPSED))
                log "UID ${USER_ID} (${USERNAME}): Neustart-Schutz – übersprungen (noch $REMAIN s)"
                continue
            fi
        fi
    fi

    ###########################################################################
    # Hängende fetchmail-Prozesse beenden (max 1 Prozess pro User)
    ###########################################################################

    if [ $RUNNING -eq 0 ]; then
        kill_hanging_fetchmail "$USERNAME"
    fi

    ###########################################################################
    # fetchmail starten
    ###########################################################################

    if [ $RUNNING -eq 0 ]; then
        log "UID ${USER_ID} (${USERNAME}): fetchmail läuft nicht – starte neu"

        su -s /bin/sh -c "
            \"$FETCHMAIL_BIN\" \
                -f \"$CONFIG_FILE\" \
                --pidfile \"$PIDFILE\" \
                --idfile \"$IDFILE\"
        " "$USERNAME" >> "$LOGFILE" 2>&1

        if [ -f "$PIDFILE" ]; then
            NEWPID=$(head -n1 "$PIDFILE" | tr -d '[:space:]')
            log "UID ${USER_ID} (${USERNAME}): fetchmail gestartet (PID $NEWPID)"
            send_restart_mail "$USER_ID" "$USERNAME" "$NEWPID"
        else
            log "UID ${USER_ID} (${USERNAME}): FEHLER – keine PID-Datei nach Start"
        fi

        echo "$(date +%s)" > "$LAST_START_FILE"
    fi
done

exit 0
 
Mir ist im MailServer Log folgendes aufgefallen:

Wenn ich am PC Thunderbird starte, dann stehen im Log Verbindungen zum PC (imap), aber ohne Username. Im Detail steht im Ereignis (die IP-Adressen sind IPv6-GUA-Temporary):

Connect end: Connection closed (disconnected before auth was ready, waited 0 secs).

Hat das noch jemand? Was kann das bedeuten Screenshot 2025-12-19 100000.png
 
Skript, das fetchmail überwacht

Das schaut gut aus. Ich erinnere mich, dass unter CentOS 6 seinerzeit ähnliche Probleme auftraten und es darauf hinauslief, fetchmail jeden Morgen zwangsweise neu zu starten. Das war damals fetchmail 6.3.17. Mit CentOS 7 und neuer trat/tritt das Problem nicht mehr auf.

Was kann das bedeuten
Schaut für mich so aus, als ob der Client keine Zugangsdaten hat. Wenn's dein eigener PC ist, müsste Thunderbird ja eigentlich Fehler rauswerfen. Ich würde mal alle Kontoeinstellungen prüfen.
 

Additional post fields

 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat