Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comm.software.mailserver > #6896
| From | Marco Moock <mm+usenet-es@dorfdsl.de> |
|---|---|
| Newsgroups | de.comm.software.mailserver |
| Subject | Re: DMARC policy Error beim Empfänger |
| Date | 2023-10-26 17:17 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <uhdvul$1lu4s$1@dont-email.me> (permalink) |
| References | (3 earlier) <kpps4lFr54tU16@mid.individual.net> <uh8hfb$2lj8c$1@gwaiyur.mb-net.net> <kpst8lFgm74U6@mid.individual.net> <uhcseb$2c91j$1@news.nnpt4.net> <kpv9s7F7mjgU1@mid.individual.net> |
Am 26.10.2023 um 16:02:47 Uhr schrieb Arno Welzel: > E-Mail-Empfang ist in der Regel absolut problemlos - denn das > produziert ja keinen Spam. Aber das *senden* von E-Mail ist > mittlerweile ein echter Spießrutenlauf :-(. Habe ich oft gehört, aber ich konnte das mit meinem Server bisher nicht erfahren (IPv4/IPv6 bei TAL AS 8820). Mails an GMail gingen per IPv6 problemlos raus und kamen beim Empfänger an. Auch bei GMX gab es keine Probleme. Wundert mich zwar, aber besser so als anders. > Was ich auch kenne, ist Blacklisting weil der Server beim großen > Anbieter nicht bekannt ist. So landen E-Mails bei Microsoft gerne mal > in einem schwarzen Loch, ohne dass man es merkt oder man bekommt die > beliebte Meldung S3150, weil gleich ganze Adressblöcke des Hosters bei > Microsoft gesperrt sind. Das gelöst zu bekommen, ohne den Hoster zu > wechseln, ist nahezu unmöglich, weil in solchen Adressblöcken halt > auch oft Server von Hobby-Admins stehen, die nicht immer zuverlässig > Missbrauch ihrer Server für Spam verhindern. Noch schlimmer: Server von Spammern. Oft kümmern sich die ISPs gar nicht oder viel zu langsam darum. Aber auch spammende normale Nutzer sollte man als ISP schnellstmöglich blockieren. > Und die Telekom hat besonders lustige Anforderungen, dass man nicht > nur den sendenden Mail-Server explizit dort anmelden muss mit Angabe > von IP-Adresse und Hostname (der natürlich auch bei rDNS aus der > Adresse auflösbar sein muss) sondern man will unter dem Namen auch > eine Website erreichar haben, auf der ein Impressum des > Serverbetreibers angegeben ist. Telekom kann ich nicht testen, da ich da ohne Handynummer kein Konto erstellen kann und bisher musste ich noch nicht mit einer T-Online-Adresse schreiben. > Leider kann ich meinen Nutzern auch nur schwer vermitteln kann, dass > Telekom-Adressen halt einfach nicht gehen, weil die Telekom blöd ist. > Also gibt es jetzt eben auch eine Website unter dem Namen des > Mail-Relay, damit die Telekom glücklich ist. Wie prüfen die das denn automatisch? > Trotz dieser Reifen, durch die man springen muss, weigere ich mich > bisher standhaft, einen Anbieter wie Mailjet, Sendinblue, GMail (was > mit eigener Domain ginge) oder mailbox.org für ausgehende E-Mail zu > nutzen. Der Server steht bei keinem Massenhoster und wird auch > anstandslos selbst bei schwierigen Kandidaten akzeptiert, die sonst > gerne kleine Server per se ablehnen, wie Microsoft, Google oder > öffentliche Institutionen, die so lustige Dinge wie UCEPROTECT nutzen > (siehe auch <https://arnowelzel.de/erfahrungen-mit-uceprotect>). uceprotect hat aber klare Policies, die nachvollziehbar sind, im Gegensatz zu MS und Google. Wer Level 3 einsetzt, tut das in vollem Bewusstsein, dass legitime Kunden blockiert werden. Wenn du mal die AS-Nummer von Hetzner eingibst, siehst du, dass da halt einige Netze gelistet sind, weil da viele Spammer unterwegs waren. Maßnahmen dagegen gibt es viele, z.B. den SMTP-Port defaultmäßig zu entsperren und z.B. fürs erste halbe Jahr ne Kaution verlangen wäre ne Option. Bei massivem Spamversand wird die einbehalten. Dürfte Spammer von solchen Provider fernhalten, bleiben noch die Leute, die ihre Systeme nicht im Griff haben.
Back to de.comm.software.mailserver | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-24 08:09 +0200
Re: DMARC policy Error beim Empfänger Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-10-24 09:48 +0200
Re: DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-24 13:05 +0200
Re: DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-24 13:09 +0200
Re: DMARC policy Error beim Empfänger Arno Welzel <usenet@arnowelzel.de> - 2023-10-24 14:37 +0200
Re: DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-24 15:39 +0200
Re: DMARC policy Error beim Empfänger Arno Welzel <usenet@arnowelzel.de> - 2023-10-25 18:15 +0200
Re: DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-26 07:11 +0200
Re: DMARC policy Error beim Empfänger Arno Welzel <usenet@arnowelzel.de> - 2023-10-26 16:02 +0200
Re: DMARC policy Error beim Empfänger Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-10-26 17:17 +0200
Re: DMARC policy Error beim Empfänger Arno Welzel <usenet@arnowelzel.de> - 2023-10-26 19:30 +0200
Re: DMARC policy Error beim Empfänger Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-10-26 20:39 +0000
Re: DMARC policy Error beim Empfänger Marcus Jodorf <m@bogomips.de> - 2023-11-07 02:33 +0100
Re: DMARC policy Error beim Empfänger Arno Welzel <usenet@arnowelzel.de> - 2023-11-07 14:55 +0100
Re: DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-27 11:14 +0200
csiph-web