IIRC haben web.de und GMX das später wieder etwas entschärft. Auf
Kleiner Nachtrag. Wenn der Sender für seine Domain einen unglücklichen SPF eingetragen hat und der Empfänger-MTA die EMail an web.de/GMX weiterleitet, wird diese abgelehnt. Die geben als Antwort:
550-Requested action not taken: mailbox unavailable
550-Reject due to policy restrictions.
550 For explanation visit http://postmaster.web.de/error-messages...
einem meiner MTAs habe ich eine Weiterleitung auf eine web.de-Adresse
für einen Freund. Einige Mails lehnt web.de ab. Mal schauen,
vielleicht schreibe ich mir dafür einen speziellen web.de-Filter, der
mit der web.de-Methode die Sender vorprüft. Dann fliegt der Mist
gleich komplett raus und dümpelt nicht unnötig in der Queue herum. Es
ist effizienter um die Deppen herum zu arbeiten, als sich den ganzen
Tag lang darüber aufzuregen.
Der Filter funkt prima und ist ganz einfach. Er überprüft bei Domains mit Weiterleitung den Sender per Rückruf. Damit wird sicher gestellt, daß eine spätere Fehlermeldung an den Sender zugestellt werden kann. Gibt es den Sender nicht -> Tonne. Wenn der Sender einen unglücklichen SPF hat und web.de/GMX die EMail ablehnen, geht die Fehlermeldung an den Sender. Der hat dann eine faire Chance das Problem im SPF zu lösen oder den Empfänger aus seiner SPAM-Liste zu löschen.
Just die bisher untersuchten Mails vom "Papierkorb" sind
ausschließlich Mails die über web an gmx oder umgekehrt
weitergeleitet werden, was ich so nachvollziehen konnte.
Du hast einen Volltreffer gelandet ;) Das Problem ist, daß beide folgendes für's SPF eingetragen haben:
web.de descriptive text "v=spf1 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.248/29 ip4:82.165.159.0/26 ip4:217.72.207.0/27 ip4:217.72.192.64/26 -all"
gmx.de descriptive text "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all"
"-all" bedeutet, daß nur die davor gelisteten Netze EMail senden. Wenn Dein MTA nun EMail mit einer web.de/GMX-Absenderadresse bei dem jeweils anderen abliefern will, wird das von web.de/GMX abgelehnt. Die EMail kommt nicht von einem MTA in der SPF-Liste, sondern von Deinem MTA. Somit wird Dein MTA zwischen beiden aufgerieben. Bedanken kannst Du Dich bei 1&1 (denen web-de und GMX gehören) für deren durchdachtes Anti-SPAM-Konzept.
Bleibt die Frage nach einer Lösung. Du könntest einen Filter für das web.de-GMX Hin und Her schreiben, der dem Sender einen Fehler mit entsprechender Erklärung liefert. Die andere Möglichkeit erspare ich Dir, weil diese ziemlich aufwendig ist und neue Probleme verursacht. Ich bin mehr für das Motto "name & shame".
Angenommen; Binkd Connects würden auch herunterprevelgiert/priorisiert werden, worin würde denn die Alternative liegen?Grübel.... Lach, wäre ja witzig, wenn gerade dadurch das FidoNachdem es dafür inwzischen auch eine App gibt...
wieder etwas mehr zulauf haben sollte :-) In Zeiten von Flatrates
is es ja egal, wenn man mit nem Modem wieder Mails versendet, und
solange binkd funktioniert, dann isses ja auch so im Netz
möglich.
cu,Bye/2 Torsten
Markus
Grübel.... Lach, wäre ja witzig, wenn gerade dadurch das Fido
wieder etwas mehr zulauf haben sollte :-) In Zeiten von Flatrates
is es ja egal, wenn man mit nem Modem wieder Mails versendet, und
solange binkd funktioniert, dann isses ja auch so im Netz
möglich.
Nachdem es dafür inwzischen auch eine App gibt...
Angenommen; Binkd Connects würden auch herunterprevelgiert/priorisiert werden, worin würde denn die Alternative liegen?
Apropos, weil es gerade dazu passt:
Kunde hat SBS 2003 und 1&1 als Smarthost. Das ist ja schon schlimm genug. Dienstag war ich da vor Ort um ein Update in einer Datenbank einzuspielen. (Daten, nicht Programm) Dabei wurde so beiläufig erwähnt, dass 'so eine komische Fehlermeldung' in den Mails wäre. Verzögerte Zustellung, Blahblah...
Seit dem 29.06. kurz vor 17:00 Uhr werden keine Nachrichten mehr übertragen. Ich 'durfte' dann mit dem Support bei 1&1 sprechen. Wirklich Ahnung hatte der wohl nicht, aber 'zugegeben', dass sie einen Bug eingespielt hätten. Nunja...
Natürlich konnte der Kunde gar nicht verstehen, dass das so lange andauert. Kurzer Test mit einem Linux-Mailserver, der wegen 'gravierender Mängel' nicht abgenommen wurde - Nachrichten werden (natürlich) beim Smarthost abgeliefert.
Ironie ist auch nicht seins, meinen Kommentar, dass SBS 2k3 mit 'nem Smarthost unter Exchange 2003 im Jahre 2017 wohl eine sehr verbreitete Konstellation sein dürfte und es daher wohl etwas länger dauern könnte, bis da etwas passiert (falls überhaupt), hat er jedenfalls nicht geschnallt.
Achja, der gravierende Mangel ist, dass er nicht mit 5 Identitäten aus einem Webmail-Account schreiben könnte. 5 Inbounds zu durchsuchen dauert ja viiiiel zu lange. Wenn er mit 180 auf der Autobahn seine Anfragen abarbeitet...
Hoffentlich trifft er einen Brückenpfeiler und keinen unbeteiligten Autofahrer!
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,019 |
Nodes: | 17 (0 / 17) |
Uptime: | 09:18:42 |
Calls: | 503,178 |
Calls today: | 2 |
Files: | 219,643 |
D/L today: |
614 files (36,051K bytes) |
Messages: | 441,000 |
Posted today: | 1 |