DMARC policy Error beim Empfänger

[Jan Novak]

Hallo,

habe gerade diese Fehlermeldung beim Versand einer Mail bekommen:

host
smail-swn-mta1.dts-security.de[212.101.206.83] said: 554 5.7.5
Permanent
error evaluating DMARC policy (in reply to end of DATA command)


Was genau heisst das?
Der DMARC policy Error stammt von meinem Mailserver (und dem dortigen
DMARC Eintrag) oder von der Empfängerseite?
Und was kann ich dagegen tun?

Jan

[Marco Moock]

Am 24.10.2023 um 08:09:11 Uhr schrieb Jan Novak:

> Was genau heisst das?
> Der DMARC policy Error stammt von meinem Mailserver (und dem dortigen
> DMARC Eintrag) oder von der Empfängerseite?
> Und was kann ich dagegen tun?

Mit welcher Domain schickst du weg?

Ist da DMARC eingerichtet?
Setzt der Empfänger ggf. DMARC voraus?

[Jan Novak]

Am 24.10.23 um 09:48 schrieb Marco Moock:

Hallo Marco,

ich sende eine Mail für meine Domain, für welche auch DMARC gesetzt ist.

Auf den Empfänger (großes Unternehmen) habe ich natürlich keinen
Einfluss, bzw. weiss nicht, was er vorraus setzt.

Der dmarc checker bei https://mxtoolbox.com/ gibt für meine Domäne
korrekte Daten aus. Der Mailserver selbst ist eine andere Domain und
besitzt keinen dmarc Eintrag (weil in dessen Namen keine Mails gesendet
werden).

Jan

[Jan Novak]

Am 24.10.23 um 13:05 schrieb Jan Novak:

Muss wohl an meinem Mailserver liegen. Hab die gleiche Mail (aus dem
gleichen Thunderbird) über mein google gesendet, die kam an und wurde
sofort bestätigt.


Jan

[Arno Welzel]

Jan Novak, 2023-10-24 13:05:

> Am 24.10.23 um 09:48 schrieb Marco Moock:
>> Am 24.10.2023 um 08:09:11 Uhr schrieb Jan Novak:
>>
>>> Was genau heisst das?
>>> Der DMARC policy Error stammt von meinem Mailserver (und dem dortigen
>>> DMARC Eintrag) oder von der Empfängerseite?
>>> Und was kann ich dagegen tun?
>>
>> Mit welcher Domain schickst du weg?
>>
>> Ist da DMARC eingerichtet?
>> Setzt der Empfänger ggf. DMARC voraus?
>>
>
> Hallo Marco,
>
> ich sende eine Mail für meine Domain, für welche auch DMARC gesetzt ist.

Was alleine noch nicht viel bedeutet.

> Auf den Empfänger (großes Unternehmen) habe ich natürlich keinen
> Einfluss, bzw. weiss nicht, was er vorraus setzt.
>
> Der dmarc checker bei https://mxtoolbox.com/ gibt für meine Domäne
> korrekte Daten aus. Der Mailserver selbst ist eine andere Domain und
> besitzt keinen dmarc Eintrag (weil in dessen Namen keine Mails gesendet
> werden).

Und ist der laut SPF-Record zulässig für die Domain, die in der E-Mail
benutzt wurde?

Zum Testen kannst Du auch <https://www.mail-tester.com> verwenden. Da
wird recht detailliert angezeigt, wenn etwas nicht passt.

--
Arno Welzel
https://arnowelzel.de

[Jan Novak]

Am 24.10.23 um 14:37 schrieb Arno Welzel:

>> ich sende eine Mail für meine Domain, für welche auch DMARC gesetzt ist.
>
> Was alleine noch nicht viel bedeutet.
>
>> Auf den Empfänger (großes Unternehmen) habe ich natürlich keinen
>> Einfluss, bzw. weiss nicht, was er vorraus setzt.
>>
>> Der dmarc checker bei https://mxtoolbox.com/ gibt für meine Domäne
>> korrekte Daten aus. Der Mailserver selbst ist eine andere Domain und
>> besitzt keinen dmarc Eintrag (weil in dessen Namen keine Mails gesendet
>> werden).
>
> Und ist der laut SPF-Record zulässig für die Domain, die in der E-Mail
> benutzt wurde?

Ja (siehe unten).

>
> Zum Testen kannst Du auch <https://www.mail-tester.com> verwenden. Da
> wird recht detailliert angezeigt, wenn etwas nicht passt.

Guter Tipp:
Allerdings meldet mir die Seite, dass alles bestens sei (Auszug):

-0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
Diese Regel wird angewendet, wenn die E-Mail eine DKIM Signatur
aufweist, aber weitere positive Regeln werden bei einer gültigen DKIM
Signatur ebenfalls angewendet. Bitte beachten Sie den folgenden Absatz.
0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
Wunderbar! Ihre Signatur ist gültig.
0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
Großartig! Ihre Signatur ist gültig und sie kommt von der ausgewiesenen
Domain
0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from
envelope-from domain
0.001 SPF_HELO_PASS SPF: HELO matches SPF record
0.001 SPF_PASS SPF: sender matches SPF record
Wunderbar! Ihr SPF-Eintrag ist gültig.


Lediglich

"Klicken Sie hier, um Ihre Nachricht anzuzeigen
SpamAssassin mag Ihre E-Mail
Sie sind vollständig berechtigt
Ihre Nachricht könnte verbessert werden
Sie werden in keiner Blacklist geführt."

Die "verbessert" liegt am Inhalt der Testmail (keine Signatur, kein
Name, nur das Wort "test")

Von daher scheint das alles OK zu sein.

Jan

[Arno Welzel]

Jan Novak, 2023-10-24 15:39:

> Am 24.10.23 um 14:37 schrieb Arno Welzel:

[...]

>> Zum Testen kannst Du auch <https://www.mail-tester.com> verwenden. Da
>> wird recht detailliert angezeigt, wenn etwas nicht passt.
>
> Guter Tipp:
> Allerdings meldet mir die Seite, dass alles bestens sei (Auszug):

[...]

> Die "verbessert" liegt am Inhalt der Testmail (keine Signatur, kein
> Name, nur das Wort "test")
>
> Von daher scheint das alles OK zu sein.

Ja, sehe ich auch so. Ich würde genau *das* dem Empfänger mitteilen und
darum bitten, den Bug in deren System zu beheben.

[Jan Novak]

Am 25.10.23 um 18:15 schrieb Arno Welzel:

Wenn das mal ginge... habe gestern eine interessanten Beitrag dazu auf
Heise gelesen. Das ist von den "großen" durchaus so gewollt...

https://www.heise.de/ratgeber/Mailserver-in-Eigenregie-Was-Sie-heute-brauchen-9329490.html

Jan

[Arno Welzel]

Jan Novak, 2023-10-26 07:11:

Der ist leider hinter eine Bezahlschranke.

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 :-(.

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.

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.

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.

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>). Dafür kostet er
halt auch ein paar EUR mehr als ein billiger virtuelle Server bei einem
der großen Hoster. Bisher bin ich bereit, den Preis für die eigene
Unabhängigkeit zu bezahlen. Ob das auch in 5 oder 10 Jahren noch so ist,
weiß ich aber nicht.

[Marco Moock]

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.

[Arno Welzel]

Marco Moock, 2023-10-26 17:17:

> Am 26.10.2023 um 16:02:47 Uhr schrieb Arno Welzel:

[...]

>> 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?

Gar nicht. Das wird manuell geprüft, weil man mit einem Support-Menschen
den Prozess durchkaspern darf. Und erst wenn der zufrieden ist, wird der
eigene Server freigegeben.

[...]

>> ö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.

Das hilft aber nicht, wenn man einen Server in einem Netz hat, wo
*andere* Server Probleme machen und Empfänger Level 3 blocken.

Die Lösung ist dann nur noch den Hoster zu wechseln und zu hoffen, dass
dessen Adressbereiche nicht gelistet sind. Ob man selbst völlig sauber
arbeitet ist dann völlig egal.

> Wer Level 3 einsetzt, tut das in vollem Bewusstsein, dass legitime
> Kunden blockiert werden.

Ja - hilft mir aber nicht. Meine User meckern dann, dass ihre E-Mail
nicht ankommt.

> Wenn du mal die AS-Nummer von Hetzner eingibst, siehst du, dass da halt
> einige Netze gelistet sind, weil da viele Spammer unterwegs waren.

Deswegen ist der Server, über den ich Mail sende, auch nicht bei Hetzner
(und auch nicht bei Ionos etc.).

> 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.

Aber Geldgier siegt halt - und dann will man lieber viele Kunden, die
Mist bauen als wenige Kunden, die Kaution zahlen wollen.

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:
> Marco Moock, 2023-10-26 17:17:
>
>> Am 26.10.2023 um 16:02:47 Uhr schrieb Arno Welzel:
> [...]
>>> 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?
>
> Gar nicht. Das wird manuell geprüft, weil man mit einem Support-Menschen
> den Prozess durchkaspern darf. Und erst wenn der zufrieden ist, wird der
> eigene Server freigegeben.

Hab ich auch schon machen muessen.
Das ist laestig und muehsam, funktioniert aber.


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/

[Jan Novak]

Am 26.10.23 um 16:02 schrieb Arno Welzel:

> <https://arnowelzel.de/erfahrungen-mit-uceprotect>). Dafür kostet er
> halt auch ein paar EUR mehr als ein billiger virtuelle Server bei einem
> der großen Hoster. Bisher bin ich bereit, den Preis für die eigene
> Unabhängigkeit zu bezahlen. Ob das auch in 5 oder 10 Jahren noch so ist,
> weiß ich aber nicht.

Dem kann ich mich bedingungslos anschliessen.
Aber es wird immer mehr ein Kampf gegen Windmühlen.

Jan

[Marcus Jodorf]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> schrieb:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Marco Moock, 2023-10-26 17:17:
>>
>>> Am 26.10.2023 um 16:02:47 Uhr schrieb Arno Welzel:
>> [...]
>>>> 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?
>>
>> Gar nicht. Das wird manuell geprüft, weil man mit einem
>> Support-Menschen den Prozess durchkaspern darf. Und erst wenn der
>> zufrieden ist, wird der eigene Server freigegeben.
>
> Hab ich auch schon machen muessen.
> Das ist laestig und muehsam, funktioniert aber.

Interessant. Die müssen aber auch noch andere Kriterien haben.
Weil, ich habe kein Problem, von meinen eigenen kleinen V-Servern an
t-online.de Adressen Mails zu schicken - und ich habe niemals irgendwas
dafür machen müssen. Die haben auch keine Webseiten oder sonst was. Und
mehr als spf hab ich auch nicht konfiguriert.

Oder die haben irgendwann vielleicht mal Regeln gebaut mit Listen von
Servern, die sie bis zu einem Stichtag noch nicht kannten und alles
andere bis dahin freigeschaltet?
(Meine Server sind steinalt.)

Aber stimmt schon, die ganze Intransparenz ist zum Kotzen und vestümmelt
email immer mehr.



Gruß,

Marcus
⚂⚃

[Arno Welzel]

Marcus Jodorf, 2023-11-07 02:33:

> Ulli Horlacher <fram...@rus.uni-stuttgart.de> schrieb:
>
>> Arno Welzel <use...@arnowelzel.de> wrote:
>>> Marco Moock, 2023-10-26 17:17:
>>>
>>>> Am 26.10.2023 um 16:02:47 Uhr schrieb Arno Welzel:
>>> [...]
>>>>> 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?
>>>
>>> Gar nicht. Das wird manuell geprüft, weil man mit einem
>>> Support-Menschen den Prozess durchkaspern darf. Und erst wenn der
>>> zufrieden ist, wird der eigene Server freigegeben.
>>
>> Hab ich auch schon machen muessen.
>> Das ist laestig und muehsam, funktioniert aber.
>
> Interessant. Die müssen aber auch noch andere Kriterien haben.
> Weil, ich habe kein Problem, von meinen eigenen kleinen V-Servern an
> t-online.de Adressen Mails zu schicken - und ich habe niemals irgendwas
> dafür machen müssen. Die haben auch keine Webseiten oder sonst was. Und
> mehr als spf hab ich auch nicht konfiguriert.

Wenn die Server schon länger in Betrieb sind, war das vielleicht, bevor
sie diese Regeln eingeführt haben. Mein alter Server für den
Mailversand, den ich bis zum Spätsommer 2022 in Betrieb hatte, konnte
auch mit T-Online kommunizieren - aber der war bis dahin auch schon
locker 6 Jahre in Verwendung. Erst beim Wechsel zu einem anderen
Anbieter kam das auf.