Tja, das Frühlings-Hähnchen des ehemaligen Vogels baut Scheiße. Damit ist dann wohl der Freifunk-Bielefeld-Twitter-Account (auch) hinfällig.
Unsere Mailserver verlangen bei eingehenden Mails, daß die die Mailserver der (angeblich) einliefernden Domain Mail für den angeblichen Absender annehmen — das ist relevant für den Fall, daß wir später feststellen sollten, daß die Mailauslieferung doch nicht möglich war und unser Mailsystem einen sog. »Bounce« senden muß. Diesem Erfordernis entsprechen die Mailserver vom Ex-Twitter nicht (mehr):
Oct 6 02:42:13 mail postfix/smtpd[5409]: NOQUEUE: reject: RCPT from spring-chicken-bh.twitter.com[199.16.156.173]: 550 5.1.7 <n0636023ba8-ddca6b3cb0674f8e-info===freifunk-bielefeld.de@bounce.x.com>: Sender address rejected: undeliverable address: EN: Sender would reject replies, thus we reject incoming / DE: Absender verweigerte Antwortmails, somit keine Mailannahme; from=<n0636023ba8-ddca6b3cb0674f8e-info===freifunk-bielefeld.de@bounce.x.com> to=<info@freifunk-bielefeld.de> proto=ESMTP helo=<spring-chicken-bh.x.com>
Heißt: es ist, wie es ist — die von Ex-Twitter geforderte Kontoüberprüfung funktioniert nicht, weil die Ex-Twitter-Mailserver inkompetent konfiguriert wurden. Mit anderen Worten: Time to say goodbye …
Woran genau scheitert es? Kannst du keine SMTP-Connection zu mx[34].x.com herstellen, weil deine IP, von der du das machst, beispielsweise auf öffentlichen Blacklists steht? Oder kein korrektes Reverse-DNS-und-matching-Forward-DNS hat?
Ich sehe erstmal keinen offensichtlichen Fehler seitens X/Twitter, ohne mehr Details zu kennen.
Es scheitert daran, daß die MXe für x.com keine Mail für @bounce.x.com annehmen wollen:
Oct 6 05:07:30 mail postfix/smtp[24093]: 69840140382: to=<n0636eb7195-6a850d07b0a448c7-info===freifunk-bielefeld.de@bounce.x.com>, relay=mx3.x.com[199.59.148.207]:25, delay=1.4, delays=0.01/0.02/1.2/0.16, dsn=5.7.1, status=undeliverable (host mx3.x.com[199.59.148.207] said: 550 5.7.1 relaying denied (in reply to RCPT TO command))
Grundprinzip von SMTP ist, daß ein MX Mails für die Domain, für die er Mailexchanger ist, annehmen muß. In postfix stellt der reject_unverified_sender-Check bei Einlieferung dies sicher, und der schlägt hier fehl (und ja, wir haben da divergierende Ansichten, ob dieser Check für einen MX legitim ist ). Vermutung: die reduzierte Admin-Crew hat bei der Umbenennung von twiier.com zu x.com vergessen, bei den MXen x.com zu den lokalen Domains hinzuzufügen …
Vielleicht/Vermutlich hast du recht. Vielleicht aber auch nicht.
michael@michael01:~$ telnet mx3.x.com 25
Trying 199.59.148.207...
Connected to mx3.x.com.
Escape character is '^]'.
220 ham-cannon.twitter.com ESMTP
ehlo huhu.de
250-ham-cannon.twitter.com says EHLO to 31.214.144.173:35268
250-PIPELINING
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 STARTTLS
MAIL FROM:<mail@michaelXXXX.de>
250 2.0.0 MAIL FROM accepted
RCPT TO:<n0636023ba8-ddca6b3cb0674f8e-info===freifunk-bielefeld.de@bounce.x.com>
550 5.7.1 relaying denied
Der Mailserver von X mag also diese Zieladresse nicht. Ob es an der Domain oder an dem localpart liegt wissen wir nicht. Vielleicht lehnt er den Empfänger ab weil es den localpart noch nicht gibt. Erst wenn X die E-Mail erfolgreich an dich übergeben hätte (du sie also mit einem »250 OK« quittiert hättest), danach hätte X diese Bounce-Zieladresse zugelassen (sprich in die »local recipients« eingetragen). Da die Mail aber noch »in Transit« war, brauchte X zu diesem Zeitpunkt noch keine Bounces für diese Zieladresse annehmen, da es keine Bounces geben konnte zu dem Zeitpunkt. Dein Check ist zeitlich gesehen eigentlich zu früh…
Ich mag das »reject_unverified_sender« nicht aus mehreren Gründen:
Es gibt Warnungen in der Postfix-Doku, dass das Feature auch Nachteile hat. Siehe Postfix Address Verification
– »Unfortunately, sender address verification cannot simply be turned on for all email - you are likely to lose legitimate mail from mis-configured systems. You almost certainly will have to set up allow lists for specific addresses, or even for entire domains.«
– »# Don’t do this when you handle lots of email«
Du machst damit dein System zu einem »Bumerang«, der auf beliebige Ziele (»unbeteiligte Dritte«) geworfen werden kann. Wenn ich beispielsweise E-Mails an dich sende mit den Absendern »known-spamtrap@web.de«, »known-spamtrap@gmx.de«, etc., dann landet deine IP ziemlich schnell auf deren Blacklists weil du Spamtraps versuchst zu kontaktieren. Das selbe gilt für »unknown user«: Wenn ich dir 200 Mails sende, alle von »unknown-address001@aol.com«, »unknown-address002@aol.com« usw, dann bringe ich dich dazu, 200 Adressen bei AOL durchzuprobieren. AOL mag dieses »Adress-Existance-Checks« überhaupt nicht und blockt dich. (AOL ist nur ein Beispiel)
Ich bin mit der Meinung übrigens nicht allein
Frage zu Sender address rejected: unverified address
Kann man machen, führt aber bekanntermaßen zu Problemen - wie du jetzt siehst.
Daher wird auch eigentlich davon abgeraten, »reject_unverified_sender« global aktiv zu haben und das, wenn man es überhaupt benutzen will, auf bestimmte Domains zu beschränken. [1]
Ich persönlich würde da komplett drauf verzichten - denn andere Mailserver könnten deine ständigen Adress-Verifikationen, speziell bei gespoofeten Adressen, leicht als Harvesting-Versuche einordnen und deinen Mailserver aussperren.
Online | IT-Administrator Magazin
Generell ist aber »reject_unverified_sender« mit Vorsicht zu genießen: Wenn Mails mit gefälschtem Absender bis zur Anweisung »reject_unverified_sender« »durchkommen«, unternimmt Postfix zum Test Zustellversuche an diese gefälschten Adressen. Sperrt nun der Zielserver Clients (in diesem Fall also den eigenen Server), die zuviele Zustellversuche an falsche Emailadressen versuchen, so wird unterm Strich eine Denial-Of-Service-Attacke daraus, die einen selbst trifft. Daher kann es sinnvoll sein, »reject_unverified_sender« nur selektiv einzusetzen wie zum Beispiel auf [6] beschrieben.
Ich würde das Feature ausschalten, es macht dich anfällig für solche Angriffe, und du hast False-Positives (du blockst Mails, die du eigentlich haben willst). Die Warnung steht nicht umsonst in der Postfix-Doku, dass du es nicht einfach anschalten kannst, und mindestens Whitelists pflegen musst (auf die X anscheinend drauf gehört).
Wenn du es ausschaltest, wirst du sehr wahrscheinlich nicht mehr Spam erhalten als vorher. Der Anteil, den rspamd nicht erkennt, aber der reject_unverified_sender-Check erkannt hätte, ist vermutlich unmessbar gering, und die Nachteile nicht wert. Ist ja auch nicht das erste Mal dass dir dieses Setting Probleme bereitet
Das sehe ich nicht so; die Adresse muß zu dem Zeitpunkt existieren, wo sie extern verwendet wird, was mit dem Versuch der Einlieferung extern der Fall ist. Davon ab, die Fehlermeldung ist nicht »User unknown« sondern »Relaying denied«. Das sind normalerweise unterschiedliche Auslöser, und ich will die Mail auch nicht relayen, ich spreche den MX für den FQDN an.
Nein, Mails, deren Absender unzustellbar ist, will ich nicht haben. Das ist auch eine Frage der Systemhygiene. Aber da sind wir unterschiedlicher Ansicht
FTR: Die Probleme gab es auch vorher nicht, Mails von twitter.com fluppten — es ist eine Fehlkonfiguration nach der Umbenennung. »Relaying denied« ist ein klares Indiz dafür, daß die Mailserver von x.com fehlkonfiguriert sind — und am Mailverkehr nicht mehr teilnehmen dürften.
Ja, die Anfälligkeit für Mißbrauch sehe ich, mit Trennung von ein- und ausgehendem Server ist das aber Banane. Meine MX, die außer Bounces nichts verschicken, mögen geblacklistet werden bis der Arzt kommt, couldn’t care less …
Das ist mir zu riskant, rspamd läßt noch viel zuviel durch. Und über das Ticketsystem sind wir zu leicht scheinbar orginärer Spammer, daher wech’ mit sowas:
Oct 11 13:19:41 mail postfix/smtpd[1046]: NOQUEUE: reject: RCPT from unknown[95.215.108.112]: 450 4.1.7 <miCard1@hxcpjfs.cn>: Sender address rejected: unverified address: EN: Sender would reject replies, thus we reject incoming / DE: Absender verweigerte Antwortmails, somit keine Mailannahme; from=<miCard1@hxcpjfs.cn> to=<peering@4830.org> proto=ESMTP helo=<hxcpjfs.cn>
Daher nimmt der MTA des Ticketsystems auch keine als Spam getaggten Mails an, was nach Anpassung des Spammyness-Wertes für GMail nun leider auch vermutlich legitime Mails blockt:
Oct 11 13:02:44 mail postfix/smtp[600]: 6634B140416: to=<support@rt.4830.org>, orig_to=<support@guetersloh.freifunk.net>, relay=rt.4830.org[2a06:e881:1700:1:400:c0ff:fefb:e269]:25, delay=6.4, delays=1.9/0.02/1.4/3.1, dsn=5.7.1, status=bounced (host rt.4830.org[2a06:e881:1700:1:400:c0ff:fefb:e269] said: 550 5.7.1 Message tagged as SPAM and rejected. (in reply to end of DATA command))
(Wieso »Alternative Hardware« zu R_MIXED_CHARSET (2.5) [subject] führt: keine Ahnung; ohne den Malus hätte es wohl keinen Header gegeben, so waren’s 7,45 von 9 Punkten.)
EDIT: wenn es ginge, würde ich reject_unverified_sender auch gerne nachrspamds milter laufen haben — oder aber jenen den Check ausführen lassen. Hmm, ginge das ggf. mit lua?
). Vermutung: die reduzierte Admin-Crew hat bei der Umbenennung von 