Mails an Freemailer werden nicht zugestellt

K

kgkoop

New Member
Servus zusammen,

mein Problem:

Mails an web.de, gmx.de, gmx.net, hotmail.com ...
werden von meinem Server bei 1blu nicht zugestellt.
Sie bleiben in der Queue und als einzige Fehlermeldung erhalte ich
Code: 
Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
Und zwar nur Mails an Freemailer - 'normale' Mails werden einwandfrei zugestellt!

Die Basics:
Server bei 1blu
3 IP Adressen - zwei dediziert, eine 'Sammel'-IP für mehrere 'kleine'.
Debian 7.11
Plesk 12.5.30
Qmail


Meine bisherigen Ansätze zur Behebung:

Die meisten Hinweise bei Tante Google deuten in die Richtung Blacklist und PTR.
Beides habe ich erledigt, es gibt keine Blacklist-Einträge, die PTR passen auch, nach Aussage von Hotmail und web.de gibt es aus deren Sicht keinen Grund, warum die Mails nicht zugestellt werden sollten.

Tja ... Theorie und Praxis ... die Mails werden nach wie vor nicht zugestellt.

Laut web.de liefert deren Server
aussagekräftige Multi-Line Responses zurück, wenn eine Ablehnung durch uns erfolgt.
Click to expand...
Also habe ich versucht herauszufinden, wie ich das Loglevel von qmail detaillierter gestalte, hab' nix gefunden.

Also meinen 'Fall-Back-Server' bei 1blu platt gemacht. Mit frischer Domain getestet und tadaa: gleiches Ergebnis, die Mails an web.de werden nicht zugestellt.
Der Support von 1blu ist nebenbei bemerkt nicht existent, keine Kommunikation, lediglich Textbaustein-Bla-bla.

Test per Telnet:
Auch hier verhält sich qmail nicht wie erwartet.
Statt
Code: 
250 2.0.0 Ok: queued as 83398728027
gibt es
Code: 
451 qq trouble in home directory (#4.3.0)

Bin jetzt irgendwie am Ende meiner Weisheit und für jeden Tip dankbar.
Ein Weg qmail zu mehr Info zu überreden wäre schon ein guter Start ...

Hoffnungsvolle Grüße

Klaus
 
Versuch mal händisch (per Telnet) eine Email an die MX-Adresse der Freemailer zu zu stellen. Falls du auch da ein connection timeout oder eine frühe Verbindungsschliessung kriegst ist die Wahrscheinlichkeit von Blacklisting sehr hoch
 
Joe User said:
Richt nach einem Rechteproblem, wobei qmüll generell stinkt...
Click to expand...
Und wie differenziert das Rechteproblem zwischen Freemail und normaler Mailadresse? Wäre es ein Problem mit den Rechten, dürfte doch gar keine Mail zugestellt werden, oder?
 
Ich gehe davon aus dass du zwei Probleme hast
a) freemailer haben dich eventuell blacklisted (telnet test)
b) dein Email-Empfang (nicht Versand) funktioniert nicht weil die lokale Email-Konten fehlerhaft sind.
 
Update

Zum Telnet Test:

Für den Test habe ich einen neuen User angelegt und mit diesem getestet.

Erfolgreich bei 'normalen' und web.de Adresse.
Code: 
250 ok 1499414089 qp 13054

Die normale Mail ging durch
Code: 
xx_accepted_message./Remote_host_said:_250_2.0.0_2bhhxvbkcr-1_Message_accepted_for_delivery/

web.de - wie immer
Code: 
Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/I'm_not_going_to_try_again;_this_message_has_been_in_the_queue_too_long./


@Joe User
Code: 
451 qq trouble in home directory (#4.3.0)
Die Meldung kam, weil der Greylisting-Schutz aktiviert war.

@d4f
ad 1: Ich stehe mit Admins von web.de und Outlook.de in Verbindung. Beide bestätigen, dass kein Blacklisting vorliegt.
ad 2: Mailempfang funktioniert auf allen Adressen einwandfrei.
 
Die Software QMail ist veraltet und wird nicht mehr gepflegt.

Letztes Stable Release von Qmail: 1.0.3 (anno Domini 1998)
Letztes Preview Release von Qmail: netqmail 1.0.6 (anno Domini 2007)

Persönlich kann mich zwar wenig zu qmail sagen, da ich mich von der Software weitesgehend fern gehalten habe. Ich vermute nur, aufgrund nur kurzer Auseinandersetzungen damit, aufgrund von Beiträgen anderer, das z. B. Postfix auch aufgrund der kontinuierlichen Weiterentwicklung QMail haushoch überlegen ist(Funktionen, Einfachheit in der Benutzbarkeit, Robustheit der Software, Möglichkeit zur Fehlersuche,...)

Die letzte Aktion, die ich diesbezüglich durchgeführt habe, ist, dass ich Qmail auf einem Plesk System durch Postfix ersetzt habe. Das ging bei mir reibungslos.

---

Im übrigen war hier meine ich auch kürzlich ein Thread mit einem 1blu-Server. Dort war die Rede davon, dass die automatisch generierten RDNS-Einträge jetzt von den grossen Mailhostern geblockt werden. Nur so als mögliche Fehlerquelle, auch wenn sich obige Fehlermeldung nicht danach anhört.
 
Last edited by a moderator:
Danke greystone, an die Möglichkeit habe ich auch schon gedacht.
Du schreibst, es ging reibungslos - was ist mit den Mails auf dem Server?
Wurden die übernommen?
 
Du schreibst, es ging reibungslos - was ist mit den Mails auf dem Server? Wurden die übernommen?
Click to expand...

Grundsätzlich ist das lange her. D. h. ich kann mich nicht mehr erinnern.

Ansonsten werden im MTA(Mail Transport Agent, also z. B. Postfix/QMail/Exim...) keine Mails gespeichert, deren Verarbeitung abgeschlossen ist(Was da sein könnte sind nicht ausgelieferte Mails. Das würde ich vorher auf jeden Fall prüfen); Die Speicherung von Mails, das macht der POP3- bzw. IMAP-Server(Courier/Dovecot...).
 
Last edited by a moderator:
Der Umzug auf Postfix ging tatsächlich reibungslos!
Emails wurden übernommen, lediglich die Passwörter für die Nutzer müssen erneut vergeben werden. Ergibt ja auch irgendwie Sinn ;-)

Bin schon von der Queue beeindruckt, denn die gibt jetzt auch gescheite Fehlermeldungen aus!
Schuldig im Sinne der Anklage: 1blu
Die PTR Records haben sich von Zauberhand wieder umgeschrieben und sind jetzt nicht mehr korrekt ... aber die machen ja keine Fehler.
Andererseits hätte ich mich ja nicht auf die Angaben verlassen brauchen und hätte überprüfen können ...
Man lernt eben nie aus.

Vielen Dank für eure Hilfe/Denkanstöße/Impulse in die richtige Richtung!!
 
Warum sollte 1blue schuldig sein? 1Blue stellt Dir die Hard/Software zur Verfügung, mehr nicht.
Der Wechsel von QMail zu Postfix geht in Plesk schon sehr lange oder gar immer schon(?)
Was mich jetzt wundert, warum musstest Du nach den Wechsel die Kennwörter ändern?
 
catwiesel, 1blu hat die PTR records nicht gesetzt, deswegen der Fehler, deswegen Schuld.
Die Passwörter mussten im Plesk bei den Emailadressen wieder vergeben werden, die alten wurden nicht übernommenen.
 
Solange du nicht die korrekten Daten in deinem Plesk-DNS einträgst und dann per DNS-Master an den DNS-Slave deines Domainanbieters weiter gibst, müssen die IPs auch nicht stimmen.
Entweder dein Plesk-DNS macht den Domain-Datentransfer oder du trägst diese selbst per Hand bei 1blue (wo die Domain sonst registriert wurde) in der Domainverwaltung ein.
 
You must log in or register to reply here.
Back
Top