Fehlersuche in der Mailstation

Aus
Die druckbare Version wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

Allgemein

Die "Mailstation" ist ein Verbund von mehreren eigenständigen Programmen, die sauber zusammenarbeiten müssen damit die Post ankommt und korrekt rausgeht. Meist hat man bei der "Mailstation" mit Problemen beim Postfix (smtp) zu kämpfen.Alleine Postfix besteht aus weiss-ich-wievielen einzelnen Prozessen, die wiederum sauber miteinander arbeiten müssen. Es bestehen also etliche Möglichkeiten für Fehlerquellen. Oft ist es bei Posts hier dann schwierig zu sagen wo denn aufgrund der Beschreibung der Fehler liegen könnte.Dabei kann man durch das Logfile unter /var/log/messages bereits die gröbsten Probleme finden. Dabei kann es sehr hilfreich sein einige Kommandos auf der Konsole miteinander zu verknüpfen z.B.

cat /var/log/messages | grep smtpd

Ihr könnt auch mehrere grep's kombinieren wenn ihr genauer einschränken wollt

cat /var/log/messages | grep imap | grep 'login failed'

Wenn man aber ganz genau wissen will was auf der Mailstation läuft (und damit auch ein viel grösseres Log File in Kauf nimmt Datei:Wink.gif ), dann könnt ihr euch auch einen alternativen syslog Daemon wie z.B. syslog-ng installieren. Damit wird wirklich jeder Schritt geloggt, was bei der Fehlersuche enorm hilfreich sein kann. So wird es möglich, dass man eine E-Mail anhand der Message ID durch die Logs hindurch verfolgen kann.Dazu öffnet man am besten das Logfile mittels tail -f und einem grep nach "message-id"

tail -f /opt/var/log/mail.log | grep 'message-id'

danach schickt man eine Testmail und schaut sich die Message ID von cleanup (einem Postfix Prozess) an z.B.

Apr 12 22:49:37 mailserver postfix/cleanup[8934]: E6469408A: message-id=<4BC3876C.6060303@EURE_DOMAIN>

die beiden fetten Werte sind die eindeutigen IDs dieser Verbindung resp E-Mail. Anhand dieser beiden Werte kann man dann eine E-Mail durch's Log hindurch zu "tracen"

cat /opt/var/log/mail.log | grep "E6469408A"
Apr 12 22:49:37 mailserver postfix/smtpd[8931]: E6469408A: client=unknown[192.168.100.11], sasl_method=PLAIN, sasl_username=ME@DOMAIN
Apr 12 22:49:37 mailserver postfix/cleanup[8934]: E6469408A: message-id=<4BC3876C.6060303@DOMAIN>
Apr 12 22:49:37 mailserver postfix/qmgr[14437]: E6469408A: from=<ME>, size=380, nrcpt=1 (queue active)
Apr 12 22:49:40 mailserver postfix/smtp[8935]: E6469408A: to=<MYGMAIL>, relay=gmail-smtp-in.l.google.com[209.85.229.27]:25, delay=2.3, 
delays=0.27/0.2/1.5/0.4, dsn=2.0.0, status=sent (250 2.0.0 OK 1271105379 a10si11125116bkc.53)
Apr 12 22:49:40 mailserver postfix/qmgr[14437]: E6469408A: removed

Dies zeigt die Logs einer Verbindung über die eine Email nach extern verschickt wurde.Solche Logs sind enorm hilfreich den Fehler einzugrenzen. Postfix ist im Fehlerfall meist auch sehr eindeutig in den Logs.Wenn ihr aber den syslog-ng wirklich installieren wollt, dann solltet ihr auch daran denken, dass die Logs sehr gross werden können. Die Logs von syslog-ng liegen zwar unter /opt und damit auf /volume1, aber auch dort ist der verfügbare Platz nicht unbegrenzt. Um das Vollaufen zu verhindern kann logrotate (via ipkg) installiert werden.

ipkg install logrotate

und eine Beispielkonf unter /opt/etc/logrotate.conf kann so ausschauen

/var/log/messages {
 daily
 missingok
 compress
 delaycompress
 create 600 root root 
 rotate 21
}

nach 21 Generationen von messages wird die älteste automatisch gelöscht.Um logrotate aufzurufen kann man einen cronjob anlegen der einmal täglich (am besten kurz vor Mitternacht) logrotate -f /opt/etc/logrotate.conf aufruft.

Loging Verhalten der Prozesse beinflussen

Postfix

Man kann den Postfix Prozessen auch sagen wieviel Logmeldungen sie produzieren sollen. Das kann helfen wenn man eine nichtssagende Meldung in den Logs finden und mehr dazu wissen will. Das Logverhalten für Postfix kann in /usr/syno/mailstation/etc/master.cf beeinflusst werden. Dabei kann man mit dem -v Parameter hinter dem Kommando den Loglevel erhöhen (z.B. -v oder -vv oder -vvv)

smtp       inet    n       -       n       -       -       smtpd -v

aktiviert das erhöhte Loging für den smtpd Prozess (der Daemon Prozess, der Mails entgegennimmt)

Wenn man jedoch nach Fehlern sucht, die Postfix beim Versenden "produziert", dann muss man den smtp (SMTP Client Prozess) anpassen

smtp       inet    n       -       n       -       -       smtp -v

Wichtig: Wenn ihr das Problem gelöst habt, dann solltet ihr die -v Parameter wieder entfernen und Postfix neustarten. Sonst fliegen Euch irgendwann die Logs um die Ohren

Konkrete Fehler

getmail

Filter error argument required for option X

Filter error (filter Filter_external spamc (allow_root_commands="True", 
arguments="('-s 250000', '-p 783', '-u USER')", command="spamc",
exitcodes_drop="('99', '100')", exitcodes_keep="('0',)", group="None", 
ignore_stderr="False", path="/usr/syno/mailstation/bin/spamc", unixfrom="False", 
user="None") returned 64 (Error in argument 1, char 2: argument required for option s)

dann solltet ihr versuchen die Argumente für spamassassin im rc File des externen Mailaccounts so

arguments = ("-s","250000","-p","783","-u","USER",)

anzugeben

Postfix

postfix/postdrop "Unable to lookup"

xxx postfix/postdrop[31817]: warning: unable to look up public/pickup: Permission denied

In diesem Fall kann der postfix Prozess postrop nicht auf public zugreifen. Das Problem sind nicht die Rechte der Datei pickup, sondern des Elternverzeichnisses public. postfix hat nicht das Recht sich den Inhalt des Verzeichnisses public aufzulisten. Auf die Datei selber darf der Prozess zugreifen!

Zur Lösung muss man dem Verzeichnis public Lese- und Ausführrechte für Gruppe und Others zu geben.

chmod 0755 /var/spool/postfix/public

Auf keinen Fall darf man diesen Befehl rekursiv auf public, und damit alle Dateien und Verzeichnisse darunter, anwenden.

postfix start/stop/realod keinerlei Reaktion

Ich habe folgendes Symptom jetzt schon bei einigen Usern gesehen. Postfix scheint einfach nicht auf das postfix Kommando zu reagieren. Nichts. Keine Ausgabe auf der Konsole und keinerlei Meldung im Log. Bei all diesen Usern war das postfix Kommando unerklärlicherweise eine leere Datei. Es scheint oft im Zusammenhang mit Stromverlusten aufzutreten. In diesem Fall muss man die postfix Datei wieder auch einem Backup herstellen. Oder sich die Firmware auf die DS runterladen, entpacken und das Postfix File wieder zu kopieren

cd /volume1/public
mkdir tmp && cd tmp
wget http://synology.com/DOWNLOAD_EUERER_FIRMWARE_VERSION
mv FILENAME_DER_FIRMWARE.pat firmware.tar
tar -xvf ./firmware.tar
tar -xvzf hda1.tgz
cp -f ./usr/syno/mailstation/sbin/postfix /usr/syno/mailstation/sbin/

postfix no transport available

Diese Meldung in den Logs kommt oft wenn ihr sowohl den Spamassassin im DSM aktiviert habt und gleichzeitig noch den ipkg Spamassassin installiert und aktiviert habt. Dies führt dazu, dass beide Versionen an denselben Port binden wollen. Der einfachste Weg ist das Startscript des ipkg-SA mittels chmod -x auf nicht ausführbar zu setzen. Wenn ihr aber den ipkg-SA verwenden wollt, dann müsst ihr in master.cf den entsprechenden Filter Service für ipkg-SA anpassen

spamfilter unix  -      n       n       -       -       pipe
 user=spamfilter argv=/opt/bin/spamc -f -e /usr/syno/mailstation/sbin/sendmail -oi -f ${sender} ${recipient}

und zusätzlich den Default SA-Filter von Synology mittels # auskommentieren. Desweiteren müsst ihr sicherstellen, dass der Default-SA nicht mehr läuft wenn das Startscript den ipkg-SA anwerfen will. Also das Startscript von ipkg-SA öffnen und als zweite Zeile

killall spamd
sleep 2

einfügen (Rest des Codes so belassen wie er im Startscript bereits ist)