Mailempfang nur noch lokal nach Update auf 8.1.1

[TauTau]

Hallo,

nachdem ein Update per Oberfläche in die Hose gegangen ist, habe ich per rpm alle Pakete von Plesk (bis auf autoinstaller) entfernt, und dann per autoinstaller sukzesive wieder auf 8.1.1 hochgezogen (hat auch problemlos funktioniert). Allerdings ist mir aufgefallen, dass ich in einem Mailaccount praktisch keine Mails mehr empfange. Getestet von einem web.de account -> kommt nichts an. Lokale Mails über eine php Seite kommen an. Irgendwas scheint also hier zu blocken. Mir ist auch aufgefallen, dass spamd die Mails überprüft, obwohl nichts dergleichen in Plesk konfiguriert ist.
Wenn ich versuche eine Mail von extern an den Server zu schicken, sehe ich auch nichts in den logs, deshalb bin ich hier etwas ratlos...

 

[enjoylife]

wart .. ich hole mal meine Glaskugel... ach Mist.. die funktioniert zur Zeit nicht...

deshalb bin ich hier etwas ratlos...

Wir wohl genau so.
Schau mal in deine Logs, findest du dort etwas interessantes?

 

[TauTau]

Wir wohl genau so.
Schau mal in deine Logs, findest du dort etwas interessantes?

hättest du noch ein paar Worte mehr zitiert, wäre dir aufgefallen, dass ich in den Logs *nichts* interessantes sehe. Es wird nichts abgelehnt o.ä.
Mir ging es auch darum, ob es evtl. eine Plesk Einstellung gibt, die Mailannahme von extern verhindert, und die ich überprüfen kann.

wart .. ich hole mal meine Glaskugel... ach Mist.. die funktioniert zur Zeit nicht...

Irgendwie scheint mir das der Lieblingssatz dieses Forums zu sein...

 

[Thorsten]

Hallo!

Irgendwie scheint mir das der Lieblingssatz dieses Forums zu sein...

Bei wenig Informationen zum eigentlichen Problem kann das vorkommen.

Zum Problem:
- MX Record korrekt?
- Welchen MTA setzt du ein?
- In welches Logfile siehst du?

mfG
Thorsten

 

[enjoylife]

du könntest sie ja trotzdem mal Posten? Nur weil du nichts interessantes findest, heisst es ja nicht das da nichts interessantes ist? Nix für ungut...

Das Problem ist halt, wir können so auch einfach nur raten...
Hast du auch mit andere Accounts als Web.de geprüft? Kommen denn die Mails gar nicht an deinem Server an? oder werden die irgendwo in deinem Servr vernichtet? etc.

 

[TauTau]

- MX Record korrekt?

1. zeigt auf meinen Server
2. zeigt auf mx01 bei 1und1

- Welchen MTA setzt du ein?

qmail, ist imho durch Plesk vorgegeben

- In welches Logfile siehst du?

/var/log/mail mail.err mail.info messages

Wenn ich von extern eine Mail schicke, greppe ich anschliessend nach dem Absender, bzw. ich lasse einfach einen tail -f auf mail.info mitlaufen, schicke aus dem Webinterface von web.de eine mail, sehe aber im log keine abgewiesenen connects. Ein telnet aus der DOS-Box auf den Server port 25 bringt einen connect mit Fehlermeldung HTTPD_IRGENDWAS (kann grade von hier nicht kucken, gerne testen unter Perforations Tattoo Ingolstadt) mit sofortigem Verbindungsabbruch.
Andere Mailaccounts auf dem Server haben das gleiche Problem, deshalb liegts wohl nicht an web.de

Gruss, Lars

 

[LinuxAdmin]

$ telnet 87.106.77.231 smtp
[COLOR="RoyalBlue"]Trying 87.106.77.231...
Connected to s15228129.onlinehome-server.info (87.106.77.231).
Escape character is '^]'.
relaylock: Error: HTTPD_SERVICE not defined
relaylock: Error: HTTPD_SERVICE not defined
Connection closed by foreign host.[/COLOR]

und wenn man relaylock in Google eingibt, erhält man als ersten Link folgende schöne Erklärung:

A package to allow only users who have authenticated via the POP3/IMAP server to relay mail using qmail-smtpd

Das ist zwar nicht genau das Paket, was dafür sorgt, dass es bei Dir nicht funktioniert, aber sollte Dich beim Suchen in die richtige Richtung weisen...

Viele Grüße,
LinuxAdmin

 

[TauTau]

Ich habe mir natürlich die auth settings angesehen, aber bei den (Anhang) eingestellten, scheint mir alles richtig, authorisierung über SMTP (was hat HTTPD_SERVICE damit zu tun?)
Edit: Was mir grade noch einfällt: Das Problem tritt ja nicht bei relaying auf (will ich eh nicht), sondern bei Mails die lokal zugestellt werden sollen. Der MTA nimmt ja den connect schon gar nicht an, d.h. er betrachtet scheinbar *jeden* externen connect als relaying Versuch...

 

[LinuxAdmin]

Ich würde mal "relaying" auf "closed" stellen, da Du es ohnehin nicht brauchst, und dann die ganze Authentifizierungs-Geschichte flach fallen kann.

 

[Thorsten]

Hallo!
Also einen relaylock beim connect finde ich ungewöhnlich. Dürfen wir bitte mal den Inhalt der Datei /etc/xinetd.d/smtp_psa sehen?

mfG
Thorsten

 

[TauTau]

Also einen relaylock beim connect finde ich ungewöhnlich. Dürfen wir bitte mal den Inhalt der Datei /etc/xinetd.d/smtp_psa sehen?

mfG
Thorsten

eben... finde ich auch seltsam, dass schon der connect derart geblockt wird. Wenn ich das so richtig sehe, hat der psa nen eigenen SMTP über den xinetd? Der qmail läuft ja über /etc/init.d/qmail...
Inhalt des files gibts, sobald ich hinter dieser firewall (@work) weg bin und ssh kann. (Beim 8.1.er Plesk war irgenwas von Java-ssh shell dabei, aber das habe ich noch nicht gefunden)

 

[TauTau]

Ich würde mal "relaying" auf "closed" stellen, da Du es ohnehin nicht brauchst, und dann die ganze Authentifizierungs-Geschichte flach fallen kann.

ich konnte diesen Satz aus der Hilfe

With closed relay the mail server will accept only e-mail addressed to the users who have mailboxes on this server. Your customers will not be able to send any mail through your outgoing SMTP server, therefore, we do not recommend closing mail relay.

nicht so ganz interpretieren, vor allem der Teil

Your customers will not be able to send any mail through your outgoing SMTP server

hat mich doch irritiert, weshalb ich das erstmal auf default gelassen habe (abgesehen davon habe ich nen Test gemacht mit "closed", kein Unterschied)

 

[TauTau]

Dürfen wir bitte mal den Inhalt der Datei /etc/xinetd.d/smtp_psa sehen?

mfG
Thorsten

here we go...

service smtp
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        disable         = no
        user            = root
        instances       = UNLIMITED
        server          = /var/qmail/bin/tcp-env
        server_args     = /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
}

 

[TauTau]

was mir jetzt gerade noch auffällt: Wenn smtp über xinetd gestartet wird, sollte doch eigentlich kein prozess sichtbar sein ausser xinetd. Ich habe aber definitiv qmail prozesse laufen:

29956 	0.0 	0.0 	qmail-send 	0 	21 	380 	S 	00:00:00 	2522 	
29958 	0.0 	0.0 	splogger qmail 	0 	23 	440 	S 	00:00:00 	2022 	
29959 	0.0 	0.0 	qmail-lspawn ./Maildir/ 	0 	21 	332 	S 	00:00:00 	0
29960 	0.0 	0.0 	qmail-rspawn 	0 	17 	328 	S 	00:00:00 	2521 	
29961 	0.0 	0.0 	qmail-clean 	0 	19 	308 	S 	00:00:00 	2520

Ist hier vielleicht das Problem zu suchen? konkurierende Mail Prozesse?

 

[LinuxAdmin]

Wenn smtp über xinetd gestartet wird, sollte doch eigentlich kein prozess sichtbar sein ausser xinetd.

Wenn gerade Mail empfangen wird, siehst Du schon die weiteren Prozesse...

Mach mal ein

ps -ef

In der zweiten Spalte siehst Du die ID des Prozesses und in der dritten Spalte die ID des Vater-Prozesses. Bei den qmail-Prozessen solltest Du bei einem der Prozesse die ID des xinetd als Vater-ID sehen. Die weiteren qmail-Prozesse sollten dann (direkt oder indirekt) von dem Prozess, der xinetd als Vater hat, abstammen. Das ganze lässt sich etwas komfortabler auch mit dem Befehl 'pstree' darstellen, der aber u.U. ein ziemlich großes Fenster für die Ausgabe braucht....

Falls die Prozesse nicht vom xinetd abstammen, stimmt was nicht so ganz -- insbesondere wenn einer der qmail-Prozesse als Vater-ID 1 hat... Dann solltest Du raus finden, warum qmail beim Booten gestartet wird und das dann abstellen.

Viele Grüße,
LinuxAdmin

 

[TauTau]

hm, das Problem wird wohl in der Twilight Zone bleiben... ich hab' jetzt das Update auf 8.2.0 eingespielt, und jetzt geht wieder alles...