Montag, 14. April 2014
[*]

Hey web.de, was ist mit Eurem SMTP los?

, 23:17

Gestern Abend erreichte mich ein Hilferuf: Mail könne nicht mehr an meinen Server geschickt werden, ob ich was geändert hätte?

Nach einigem Hin und Her (es ist schließlich nicht so einfach, mir die komplette Bounce-Nachricht weiterzuleiten, wenn genau der Mailversand gerade das Problem ist) hatte ich schließlich dieses Bild der Fehlermeldung vorliegen:

Permanent Transient Error.

Screenshot: kischtrine

Ääähm, web.de, was war nochmal Eure Hauptdienstleistung? Mail? Dann müsstet Ihr das ja eigentlich können. Auf meiner Seite des Logfiles sieht die Verbindung nämlich so aus:

Apr 13 22:01:58 nyx postfix/smtpd[19335]: connect from mout-xforward.web.de[82.165.159.34]
Apr 13 22:01:58 nyx postgrey[23219]: action=greylist, reason=new, client_name=mout-xforward.web.de, client_address=82.165.159.34, sender=*******@web.de, recipient=dentaku@wazong.de
Apr 13 22:01:58 nyx postfix/smtpd[19335]: NOQUEUE: reject: RCPT from mout-xforward.web.de[82.165.159.34]: 450 4.2.0 <dentaku@wazong.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/wazong.de.html; from=<*******@web.de> to=<dentaku@wazong.de> proto=ESMTP helo=<mout-xforward.web.de>
Apr 13 22:01:58 nyx postfix/smtpd[19335]: disconnect from mout-xforward.web.de[82.165.159.34]

Das ist Greylisting, eine durchaus übliche Anti-Spam-Maßnahme, und Ihr schickt der armen Absenderin „This is a permanent error.“ zurück? Das ist doch Quatsch. Ich habe Euch da mal den passenden RFC rausgesucht:

4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not occur. However, the error condition is temporary, and the action may be requested again. The sender should return to the beginning of the command sequence (if any). It is difficult to assign a meaning to „transient“ when two different sites (receiver- and sender-SMTP agents) must agree on the interpretation. Each reply in this category might have a different time value, but the SMTP client SHOULD try again. […]

Mein Fehlercode war 450 — also die Aufforderung, es später noch einmal zu probieren, und Ihr gebt auf. :-( Damit web.de-Kunden meine Benutzer wieder erreichen können, musste ich jetzt ein Loch in meine Spamabwehr reißen und für web.de Sonderregeln eintragen. So kann das nicht bleiben. Also bitte, liebes web.de, repariet Euren SMTP-Server.

Mittwoch, 30. Oktober 2013
[*]
[*]
Freitag, 17. Mai 2013
[*]
[*]
Freitag, 29. März 2013
[*]
[*]
Sonntag, 15. Juli 2012
[*]
[*]
Dienstag, 24. April 2012
[*]

Das Sicherheitszertifikat der Seite verwendet einen schwachen Signaturalgorithmus

, 21:02

Meine Suchanfragen sagen mir, dass ich nicht der einzige bin, der ein Problem mit dieser Fehlermeldung hat. Zu der verstieg sich nämlich Google Chrome nach einem der letzten Updates, wenn ich per https auf meine eigene Seite zugriff.

Das Zertifikat meiner Seite ist von CAcert (dazu später nochmal mehr) und im August 2010 erstellt, es hätte also durchaus sein können, dass ich da eine technische Entwicklung verschlafen hätte. Ein generelles CAcert-Problem konnte ich mir nicht vorstellen, denn dann hätte man schnell auch woanders von der Sache gelesen.

Etwas googlen führte mich zu folgendem Bugreport gegen Chrome: Issue 108948: Chrome shouldn’t warn about insecure signatures algorithms of root certificates the user explicitly trusts. Daraus konnte ich für mich folgende Lösung erarbeiten:

Die Problembeschreibung in Chrome ist nicht ganz korrekt; mein eigenes Zertifikat ist mit einer SHA-1-Signatur unterzeichnet, die im Moment als sicher genug angesehen wird. Die Warnung wird aber auch ausgegeben, wenn eins der weiter oben in der Zertifizierungskette liegenden Zertifikate ein Sicherheitsproblem hat. Genau das war hier der Fall, es handelte sich aber um ein lokales Problem. Damit CAcert-Zertifikate überhaupt anerkannt werden können, hatte ich schon vor längerer Zeit deren Root-Zertifikate in meinen lokalen Schlüsselspeicher als vertrauenswürdige Zertifizierungsstelle importiert (wenn man sich mal ansieht, wer da alles sowieso schon vom Browser- und Betriebssystemhersteller eingetragen ist, dann ist das locker vertretbar). Zu der Zeit war das sogenannte „class-3 Intermediate Certificate“ mit einer MD5-Signatur versehen. MD5 sollte aber aus gutem Grund nicht mehr für diese Zwecke eingesetzt werden. Die aktuelle Version desselben Zertifikats trägt deshalb auch eine SHA-1-Signatur.

Eine Neuinstallation des class-3-Zertifikats hat das Problem daher behoben.

Dienstag, 15. November 2011
[*]
[*]
Dienstag, 8. November 2011
[*]
[*]
Mittwoch, 5. Mai 2010
[*]
[*]
Dienstag, 5. Januar 2010
[*]
[*]
Donnerstag, 26. November 2009
[*]
[*]
Donnerstag, 22. Oktober 2009
[*]
[*]
Freitag, 17. Juli 2009
[*]

421 invalid sender domain, possibly misconfigured

, 13:39

Vom 6. Juli an erhielt unser Mailserver in der Arbeit für alle Mails, deren Mail Exchanger mx*.schlund.de oder mx*.kundenserver.de ist, die Fehlermeldung „421 unable to verify sender domain“. Diese Mailserver gehören alle zu 1&1.

Ein Wenig Suche im Web brachte mich auf diese Hilfseite:

  • E-Mails müssen den in RFC 2822 definierten Standards genügen. >> http://www.rfc-editor.org/rfc/rfc2822.txt
  • Die E-Mail darf nicht direkt an unsere MX-Server aus Dialup-Netzen heraus zugestellt werden.
  • Ein Reverse DNS-Eintrag (FQDN) des einliefernden Servers muss vorhanden sein. >> http://de.wikipedia.org/wiki/Reverse_DNS
  • Ein sinnvolles und plausibles HELO/EHLO (Format des Anfangs einer E-Mail im Versandprotokoll) im Sinne von RFC 2821 muss gesendet werden. >> http://www.rfc-editor.org/rfc/rfc2821.txt
  • Wir prüfen auf Wunsch des Kunden die >>  SPF Records. Die Absenderadressen von weitergeleiteten E-Mails müssen daher mittels >>  SRS umgeschrieben werden.
  • Der einliefernde Server darf kein Open Proxy sein, das heisst, er muss gegen unberechtigten Zugriff geschützt sein.
  • Im Fehlerfall geben wir immer eine aussagekräftige Fehlermeldung im SMTP-Dialog zurück. Bitte verfolgen Sie im Zweifelsfall Ihr Log zurück bis zum ersten Auftreten eines Fehlers.
  • Wir prüfen verschiedene etablierte RBLs (Blacklistdatenbanken). Sollte eine davon einen Treffer enthalten, gibt der SMTP-Dialog weitere Auskunft.

Nach meinem Dafürhalten sollte die Domain soweit in Ordnung sein:

desenberg:~# host 217.110.66.114
 Name: desenberg.advanced-solutions.de
 Address: 217.110.66.114
desenberg:~# host desenberg.advanced-solutions.de
 desenberg.advanced-solutions.de A       217.110.66.114
desenberg:~# host -t mx as-gmbh.com
 as-gmbh.com             MX      0 desenberg.advanced-solutions.de

SPF kommt für die Domain nicht zum Einsatz, und alle anderen Sachen (RFC-Formate, kein offenes Relay, keine Einwahlsadresse,…) sind natürlich auch erfüllt. Ich konnte mir die Ablehnung also nicht erklären.

Nach Frage auf twitter sprang mir @Miss_1and1 (die hat sich inzwischen umbenannt) zur Seite, verriet mir eine Support-eMail-Adresse, an die ich schrieb, und das Problem verschwand (wörtlich! Im Moment des Abschickens der Mail an den Support gingen andere Mails auch raus).

Seit vorgestern ist das Problem wieder da (wenn auch diesmal mit einer leicht anderen Fehlermeldung):

"421 invalid sender domain, possibly misconfigured"

Hat irgendjemand einen Tipp, was an den DNS-Einträgen zu beachten ist, damit 1&1 die für „gültig“ hält? Oder spielt 1&1 da nur an seiner Konfiguration rum? Hier stehen inzwischen über 70 Mails an Kunden und Geschäftspartner in 31 verschiedenen Domains in der Warteschlange.

Sonntag, 30. November 2008
[*]

Anfall von Technikfeindlichkeit

, 22:44

Nix gefunden

„Es wurden keine Suchergebnisse gefunden. Haben Sie gefunden, wonach Sie gesucht haben?“

#*()=§!“/&!%/!!!! Nein! Natürlich nicht!

A rose by any other name...

„Type mismatch: Cannot convert from ArrayOfCameraJC to ArrayOfCameraJC“

Ääääh, wie jetzt? — Eigentlich mag ich Computer manchmal garnicht.

Dienstag, 18. November 2008
[*]

Software vielleicht installiert

, 10:04

 Oder auch nicht (?) :

nicht ganz richtig

(Wie soll denn ein Computerlaie jemals mit Vista zurechtkommen?)

Freitag, 7. November 2008
[*]

M.C. Escher arbeitet für Google Maps | Spreeblick
Mir ist schlecht…
aus Delicious/steinhobelgruen

Tags , , ,   Kommentare  Kommentare deaktiviert für M.C. Escher arbeitet für Google Maps | Spreeblick
Dienstag, 4. November 2008
[*]

Alles wird gut

, 16:52

MS Exchange hat großes Vertrauen in die Zukunft:

...wird schon wieder...

Vorübergehender Fehler. Das Problem löst sich möglicherweise später von selbst…

😀

Freitag, 13. Juni 2008
[*]

Windows – Kein Datenträger

, 15:25

Exception Processing Message c0000013 Parameters 75b0bf9c 4 75b0bf9c 75b0bf9c

Was willst Du mit dem nicht vorhandenen Datenträger tun?

Donnerstag, 28. Februar 2008
[*]

Rechnergestützte Amnesie

, 08:55

…und ich habe mich immer schon gefragt, wohin eigentlich die fehlenden Erinnerungen gehen:
Amnesie

Donnerstag, 31. Januar 2008
[*]

Die dämlichste Webanwendung der Welt

, 09:19

SharePoint Grrrr!

Wirklich. Dreckstool!

 1 2 »