SPF Eintrag für selbstgehosteten Server

[Jan Novak]

Moin,

ich habe für mich und Familie einen Postfix Mailserver seit rund 10
Jahren im Betrieb. Ein wichtiger Empfänger nimmt seit kurzem keine Mails
mehr von mir an wegen fehlendem SPF Eintrag.
Nun habe ich mich im Netz dazu durch diverse Infos gelesen, aber nicht
verstanden, wie ich das für meinen privaten Server nutzen kann.

Meine Mail Domain habe ich bei Hetzner in deren DNS Robot konnektiert.

Kann mir jemand einen einfachen Einstieg nennen, wie ich das umsetzen
kann (also kein stundenlanges Gewäsch wofür und was das ist)?


Jan

[Marco Moock]

Am 15.02.2023 um 14:09:50 Uhr schrieb Jan Novak:

> Nun habe ich mich im Netz dazu durch diverse Infos gelesen, aber
> nicht verstanden, wie ich das für meinen privaten Server nutzen kann.

Du brauchst für deine Absenderdomain einen TXT-Record.

Hier als Beispiel von heise:

heise.de. 86400 IN TXT "v=spf1
ip4:193.99.144.0/24 ip4:193.99.145.0/24 ip6:2a02:2e0:3fe:1001::/64
?all"

Da trägst du deine IPv4- und IPv6-Netze/Adressen ein, von denen per
SMTP die Mails an externe Server gehen.

[Jan Novak]

Am 15.02.23 um 14:22 schrieb Marco Moock:

Das ist alles?
Ich habe was von Zertifikaten gelesen und weiss nicht noch was alles.
Das wäre ja einfach. Versuche ich mal. Mein Server hat leider keine ipv6
(weil mir mein Provider (noch) keine gibt), deswegen kann (und muss) ich
das ja weg lassen, oder?

Jan

[Markus Schaaf]

Am 15.02.23 um 14:09 schrieb Jan Novak:

> Kann mir jemand einen einfachen Einstieg nennen, wie ich das umsetzen
> kann (also kein stundenlanges Gewäsch wofür und was das ist)?

Angenommen Du versendest für Absender xyz@domain von den
IP-Adressen a.a.a.a und b.b.b.b E-Mails, dann musst Du für
"domain" einen TXT-Record eintragen mit diesem Inhalt:

"v=spf1 ip4:a.a.a.a ip4:b.b.b.b -all"

Danach sind E-Mails von @domain nur noch von diesen IP-Adressen
versendbar. Empfänger, die SPF prüfen, werden E-Mails von anderen
IPs als Spam markieren oder, wie ich, gar nicht erst annehmen.
Laxere Einstellungen wären möglich, verschlechtern dann jedoch
wahrscheinlich das Ranking bei Empfängern, die darauf achten. SPF
"neutral" wandert bei mir z.B. zum Spam.

Zu beachten: die TTL dieses Eintrags, z.B. 1d. Dann musst Du
mindestens 1d vor Wechsel der IP des Mailservers die neue IP
zusätzlich dort eintragen, und die alte später nach
Außerbetriebnahme löschen.

Wie Du das genau klicken musst bei Hetzner, kann ich Dir mangels
gehosteter Domain dort nicht sagen.

MfG

[Markus Schaaf]

Am 15.02.23 um 14:26 schrieb Jan Novak:

> Das ist alles?
> Ich habe was von Zertifikaten gelesen und weiss nicht noch was alles.

Dann verwechselst Du das mit DKIM, was wesentlich aufwendiger
ist. Oder gar DMARC, einer Kombination aus SPF und DKIM, die von
Leuten entworfen wurde, die keine Ahnung von E-Mail haben.
Letzteres will man auf keinen Fall für die eigene Domain
implementieren.

MfG

[Jan Novak]

Am 15.02.23 um 14:40 schrieb Markus Schaaf:

> Am 15.02.23 um 14:09 schrieb Jan Novak:
>

> Angenommen Du versendest für Absender xyz@domain von den IP-Adressen
> a.a.a.a und b.b.b.b E-Mails, dann musst Du für "domain" einen TXT-Record
> eintragen mit diesem Inhalt:
>
> "v=spf1 ip4:a.a.a.a ip4:b.b.b.b -all"

Da ich nur eine IP Adresse habe, ist das dann ja wohl klar. Aber z.B.
beim heise spf steht am Ende "?all" und nicht "-all" !?

> Danach sind E-Mails von @domain nur noch von diesen IP-Adressen
> versendbar. Empfänger, die SPF prüfen, werden E-Mails von anderen IPs
> als Spam markieren oder, wie ich, gar nicht erst annehmen.

Soweit so klar und bekannt.

Laxere
> Einstellungen wären möglich, verschlechtern dann jedoch wahrscheinlich
> das Ranking bei Empfängern, die darauf achten. SPF "neutral" wandert bei
> mir z.B. zum Spam.

Das ist besonders wichtig - das Ranking!

> Zu beachten: die TTL dieses Eintrags, z.B. 1d. Dann musst Du mindestens
> 1d vor Wechsel der IP des Mailservers die neue IP zusätzlich dort
> eintragen, und die alte später nach Außerbetriebnahme löschen.

Klar. TTL halt.

> Wie Du das genau klicken musst bei Hetzner, kann ich Dir mangels
> gehosteter Domain dort nicht sagen.

das ist ganz einfach.

Ich hatte einen solchen Eintrag schon mal drin gehabt, aber wieder
verworfen, weil's nichts brachte. Der Fehler war, dass ich den SPF
Eintrag nicht für meinedomain.de sondern für mail.meinedomain.de
angelegt hatte, wobe mail.meinedomain.de der smtp Server ist.

Danke für die Tipps.

Jan

[Jan Novak]

Am 15.02.23 um 14:45 schrieb Markus Schaaf:

Ja, dem ist genau so.
Danke für die Klarstellung.

Jan

[Markus Schaaf]

Am 15.02.23 um 14:48 schrieb Jan Novak:

>> "v=spf1 ip4:a.a.a.a ip4:b.b.b.b -all"
>
> Da ich nur eine IP Adresse habe, ist das dann ja wohl klar. Aber z.B.
> beim heise spf steht am Ende "?all" und nicht "-all" !?

?all ist eben laxer und heißt, nimm's trotzdem an. Das kann man
zum Testen benutzen, sonst ist es eher sinnlos.

>> Einstellungen wären möglich, verschlechtern dann jedoch wahrscheinlich
>> das Ranking bei Empfängern, die darauf achten. SPF "neutral" wandert bei
>> mir z.B. zum Spam.
>
> Das ist besonders wichtig - das Ranking!

Dann leg auch Records für den HELO-Namen Deines Mailservers an.
Das ist optional, wird aber manchmal zum Scoring benutzt:

Für z.B. den Server mailer.domain:
"v=spf1 a -all"

MfG

[Marco Moock]

Am 15.02.2023 um 14:26:21 Uhr schrieb Jan Novak:

> Am 15.02.23 um 14:22 schrieb Marco Moock:
> > Am 15.02.2023 um 14:09:50 Uhr schrieb Jan Novak:
> >
> >> Nun habe ich mich im Netz dazu durch diverse Infos gelesen, aber
> >> nicht verstanden, wie ich das für meinen privaten Server nutzen
> >> kann.
> >
> > Du brauchst für deine Absenderdomain einen TXT-Record.
> >
> > Hier als Beispiel von heise:
> >
> > heise.de. 86400 IN TXT "v=spf1
> > ip4:193.99.144.0/24 ip4:193.99.145.0/24 ip6:2a02:2e0:3fe:1001::/64
> > ?all"
> >
> > Da trägst du deine IPv4- und IPv6-Netze/Adressen ein, von denen per
> > SMTP die Mails an externe Server gehen.
> >
>
> Das ist alles?

Für spf ja.
Dann können anderen den lesen und unpassende Mails ablehnen.

> Ich habe was von Zertifikaten gelesen und weiss nicht noch was alles.

Hat aber mit SPF doch nix zu tun.

> Das wäre ja einfach. Versuche ich mal. Mein Server hat leider keine
> ipv6 (weil mir mein Provider (noch) keine gibt), deswegen kann (und
> muss) ich das ja weg lassen, oder?

Dann eben kein ip6, das ist ja schnell hinzugefügt, wenn der Provider
dann in die Pötte gekommen ist.

[Marco Moock]

Am 15.02.2023 um 14:48:03 Uhr schrieb Jan Novak:

> Da ich nur eine IP Adresse habe, ist das dann ja wohl klar. Aber z.B.
> beim heise spf steht am Ende "?all" und nicht "-all" !?

Hier steht alles kurz zusammengefasst:
https://de.wikipedia.org/wiki/Sender_Policy_Framework#Aufbau_eines_SPF-Records

[Tim Ritberg]

Am 15.02.23 um 14:09 schrieb Jan Novak:

Hatte ich neulich auch.
Scheinbar gibt es einen neuen SPF-Standard.
Einige Parameter sind weggefallen und ganz lange TXT werden auch nicht
mehr gemocht.

Einfach mit einem Onlinetool neu anlegen oder checken:
https://www.spf-record.de/generator

Tim

[Andreas M. Kirchwitz]

Jan Novak <rep...@gmail.com> wrote:

> ich habe für mich und Familie einen Postfix Mailserver seit rund 10
> Jahren im Betrieb. Ein wichtiger Empfänger nimmt seit kurzem keine Mails
> mehr von mir an wegen fehlendem SPF Eintrag.

Die allermeisten Server mit obskurem Antispam-Voodoo sind zufrieden,
wenn man irgendeinen SPF-Eintrag hat (der praktisch alles erlaubt),
man muss nicht notwendigerweise nähere Angaben machen.

Nur so als Erfahrung aus dem Alltag. Natürlich kann sich das alles
jederzeit ändern. Wer seinen eigenen Mailserver betreibt, wird meist
über manches Stöckchen springen müssen, was ihm die "Großen" hinhalten.

Grüße, Andreas

[Jan Novak]

Am 15.02.23 um 15:01 schrieb Markus Schaaf:

>> Das ist besonders wichtig - das Ranking!
>
> Dann leg auch Records für den HELO-Namen Deines Mailservers an. Das ist
> optional, wird aber manchmal zum Scoring benutzt:
>
> Für z.B. den Server mailer.domain:
> "v=spf1 a -all"

Kannst du das genauer erklären, was das genau bedeutet und in welchem
Zusammenhang die Domain mit diesem Eintrag steht?

Jan

[Jan Novak]

Am 15.02.23 um 15:14 schrieb Tim Ritberg:

Ohhh interessantes Tool. Wenn meine Domain xyz.de über meinen Mailserver
mit der Adresse mail.abc.de versendet, brauche ich dann einen "redirect"?
Der Server ist zwar der gleiche, aber der Mailserver heisst anders als
meine Domain.

Jan

[Jan Novak]

Am 16.02.23 um 02:22 schrieb Andreas M. Kirchwitz:

Das kann ich bestätigen. Und meistens sind es Baumstämme in 2 m Höhe.


Jan

[Paul Muster]

Am 16.02.2023 um 07:05 schrieb Jan Novak:
> Am 16.02.23 um 02:22 schrieb Andreas M. Kirchwitz:

>> Nur so als Erfahrung aus dem Alltag. Natürlich kann sich das alles
>> jederzeit ändern. Wer seinen eigenen Mailserver betreibt, wird meist
>> über manches Stöckchen springen müssen, was ihm die "Großen" hinhalten.
>
> Das kann ich bestätigen. Und meistens sind es Baumstämme in 2 m Höhe.

Tatsächlich? Was konkret musst oder musstest du denn tun?

Klar, es gibt Hürden, allerdings mMn keine übermäßig hohen Hürden.


mfG Paul

[Jan Novak]

Am 16.02.23 um 09:14 schrieb Paul Muster:

ach ... versuche mal *dauerhaft* ein google business oder MS 365 account
zum relayen zu benutzen. Schrecklich!

Jan

[Markus Schaaf]

Am 16.02.23 um 07:00 schrieb Jan Novak:

>> Dann leg auch Records für den HELO-Namen Deines Mailservers an. Das ist
>> optional, wird aber manchmal zum Scoring benutzt:
>>
>> Für z.B. den Server mailer.domain:
>> "v=spf1 a -all"
>
>
> Kannst du das genauer erklären, was das genau bedeutet und in welchem
> Zusammenhang die Domain mit diesem Eintrag steht?

Das ist ähnlich wie bei der Domain Deiner Absender. Nur wird
dieser TXT-Record beim Hostnamen des Mailservers angelegt, unter
dem er sich selbst meldet. Du zählst hier die IP-Adressen auf,
denen erlaubt ist, diesen Mailnamen zu verwenden:

$ netcat spica 25
220 spica.elaboris.de ESMTP Postfix
quit
221 2.0.0 Bye
$ dnstxt spica.elaboris.de
v=spf1 a -all

Das 'a' bedeutet 'gleiche IP wie der A-Record'. Der Sinn dahinter
ist einfach eine allgemeine Bestätigung, dass dieses System
E-Mail versenden darf, für die Fälle ohne Absenderdomain, wie
Status-Nachrichten, Bounces usw.

MfG

[Tim Ritberg]

Am 16.02.23 um 11:06 schrieb Markus Schaaf:
> ... Nur wird dieser

> TXT-Record beim Hostnamen des Mailservers angelegt, unter dem er sich
> selbst meldet.

Verwirrende Formulierung!
Der TXT-Record kommt direkt in die Domain, die Mail machen soll.

Tim

[Markus Schaaf]

Am 16.02.23 um 07:04 schrieb Jan Novak:

> Ohhh interessantes Tool. Wenn meine Domain xyz.de über meinen Mailserver
> mit der Adresse mail.abc.de versendet, brauche ich dann einen "redirect"?

Nein. Warum? Ich denke, dieses Tool macht es extra komplex, wegen
"Sicheren SPF-Record vom Experten erstellen lassen ab 199€". Die
ganzen Verweis- und Lookup-Methoden, die SPF theoretisch bietet,
soll man, wenn möglich, gar nicht benutzen, sondern einfach nur
IP-Adressen aufzählen. Da kommt der Name des Mailsystems
überhaupt nicht ins Spiel. Redirect benutzt Du nur, wenn die
Systeme nicht unter Deiner Kontrolle stehen, Du also nicht sicher
sagen kannst, welche IP-Adressen die (in Zukunft) haben (werden).
Das brauchst Du z.B., wenn Du Deine eigene Domain mit dem System
eines E-Mail-Dienstleisters verklöppeln willst. Aber das kriegst
Du dann von dem schon erklärt.

MfG

[Markus Schaaf]

Am 16.02.23 um 11:14 schrieb Tim Ritberg:

Meine Formulierung ist richtig. Es geht um den Eintrag fürs HELO,
nicht den Absender. Ist was anderes.

MfG

[Marco Moock]

Beides kann notwendig sein.
Hat man z.B. als Adresse i...@example.org, muss der TXT für example.org
existieren.
Der Mailserver hat aber ggf. selbst den Hostnamen srv1.example.org.
Dann muss man für den auch einen TXT anlegen, damit von dem gesendete
Mails (z.B. automatische Logs, generierte Mails usw.) angenommen werden.

[Markus Schaaf]

Am 16.02.23 um 09:14 schrieb Paul Muster:

> Tatsächlich? Was konkret musst oder musstest du denn tun?

GMail nimmt zwar an, sortiert dann aber in den Spam-Ordner. Um
das erfolgreich zu verhindern, musste ich SPF + DKIM machen, und
meine Domain in irgendsoeiner "Postmaster"-Oberfläche
registrieren (die eigentlich für GMail-Kunden gedacht ist, die
eigene Domains für GMail benutzen), um deren Reputation wieder
über Spam-Level zu bekommen.

Bei Hotmail kenne ich keinen Weg, da landet das meiste im
Spamordner. GMX/Web.de sind auch schwierig, aber das nehme ich
nicht persönlich. Ich bin vor vielen Jahren dort weg und habe
einen eigenen Server aufgesetzt, weil die alle möglichen E-Mails
unterschlagen haben.

MfG

[Jan Novak]

Am 16.02.23 um 21:55 schrieb Markus Schaaf:

1und1 / ionos geht noch recht simpel. Das benutzen wir als relay (bei Not).


Jan

[Arno Welzel]

Jan Novak, 2023-02-15 14:09:

> ich habe für mich und Familie einen Postfix Mailserver seit rund 10
> Jahren im Betrieb. Ein wichtiger Empfänger nimmt seit kurzem keine Mails
> mehr von mir an wegen fehlendem SPF Eintrag.
> Nun habe ich mich im Netz dazu durch diverse Infos gelesen, aber nicht
> verstanden, wie ich das für meinen privaten Server nutzen kann.
>
> Meine Mail Domain habe ich bei Hetzner in deren DNS Robot konnektiert.

SPF definiert, welche Server berechtigt sind, für eine Domain E-Mail zu
senden.

> Kann mir jemand einen einfachen Einstieg nennen, wie ich das umsetzen
> kann (also kein stundenlanges Gewäsch wofür und was das ist)?

<https://de.wikipedia.org/wiki/Sender_Policy_Framework>

Und noch kürzer:

TXT-Record mit folgenden Einträgen für die Domain anlegen

v=spf1 ip4:127.0.0.1 ~all

Und statt 127.0.0.1 natürlich die IP-Adresse des Servers, der den
Versand macht. Und ja, die IP-Adresse sollte natürlich auch statisch
sein. Ein Server an einem Internetzugang mit regelmäßig wechselnder
Adresse und R-DNS-Eintrag, der auf "Dial-Up" hinweist, wird generell
Probleme machen.

Wenn Du IPv6 nutzt, wäre zusätzlich die Angabe "ip6:" nötig.

--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Jan Novak, 2023-02-15 14:26:

> Am 15.02.23 um 14:22 schrieb Marco Moock:
>> Am 15.02.2023 um 14:09:50 Uhr schrieb Jan Novak:
>>
>>> Nun habe ich mich im Netz dazu durch diverse Infos gelesen, aber
>>> nicht verstanden, wie ich das für meinen privaten Server nutzen kann.
>>
>> Du brauchst für deine Absenderdomain einen TXT-Record.
>>
>> Hier als Beispiel von heise:
>>
>> heise.de. 86400 IN TXT "v=spf1
>> ip4:193.99.144.0/24 ip4:193.99.145.0/24 ip6:2a02:2e0:3fe:1001::/64
>> ?all"
>>
>> Da trägst du deine IPv4- und IPv6-Netze/Adressen ein, von denen per
>> SMTP die Mails an externe Server gehen.
>>
>
> Das ist alles?
> Ich habe was von Zertifikaten gelesen und weiss nicht noch was alles.

Zertifikate braucht man für DKIM (Domain Keys Identified Mail), nicht
SPF (Sender Policy Framework).

DKIM bedeutet, dass der Server für den Inhalt bestimmter Header der
E-Mail eine Signatur erzeugt und der Public Key (Domain Key) zur Prüfung
der Signatur als DNS-Record veröffentlicht wird.

> Das wäre ja einfach. Versuche ich mal. Mein Server hat leider keine ipv6
> (weil mir mein Provider (noch) keine gibt), deswegen kann (und muss) ich
> das ja weg lassen, oder?

Korrekt. Und "leider" eher nicht - mit IPv4 kommt man mit korrektem
SPF-Eintrag bei GMail in der Regel eher durch als mit IPv6.

Generell ist E-Mail-Versand etwas, was man nicht mehr ohne entsprechende
Erfahrung damit machen sollte. Wenn Du nicht weißt, wofür DKIM, SPF,
DMARC dienen und welche Eigenheiten Provider wie GMail, Microsoft etc.
haben, solltest Du Dich entweder damit befassen oder lieber einen
Provider wie Posteo oder Mailbox.org nutzen statt eines eigenen Servers.

[Arno Welzel]

Markus Schaaf, 2023-02-15 14:45:

Ob man das will, ist aber irrelevant, wenn man auch E-Mails an große
Provider schicken können will. Da wird das schlicht erwartet.

[Arno Welzel]

Jan Novak, 2023-02-15 14:48:

> Am 15.02.23 um 14:40 schrieb Markus Schaaf:
>> Am 15.02.23 um 14:09 schrieb Jan Novak:
>>
>> Angenommen Du versendest für Absender xyz@domain von den IP-Adressen
>> a.a.a.a und b.b.b.b E-Mails, dann musst Du für "domain" einen TXT-Record
>> eintragen mit diesem Inhalt:
>>
>> "v=spf1 ip4:a.a.a.a ip4:b.b.b.b -all"
>
> Da ich nur eine IP Adresse habe, ist das dann ja wohl klar. Aber z.B.
> beim heise spf steht am Ende "?all" und nicht "-all" !?

Heise hat sich halt entschlossen, SPF zu nutzen, aber nicht vorzugeben,
dass andere Server abgelehnt werden sollen. Das ist durchaus erlaubt.

Entscheidend ist, dass mit SPF signalisiert wird, dass es überhaupt eine
Richtlinie gibt und nicht einfach nur Spammer über irgendwelche Server
etwas einkippen.

[Arno Welzel]

Markus Schaaf, 2023-02-16 11:27:

Was bei HELO gemeldet wird, ist für SPF komplett irrelevant!

[Arno Welzel]

Marco Moock, 2023-02-16 11:37:

Ähm - nein.

Der Record muss nur für example.org existieren. Denn das ist die Domain,
für die die E-Mail-Adresse i...@example.org relevant ist. Wie der Server
sich selber nennt, der die E-Mail sendet, ist völlig egal. Seine
IP-Adresse oder der FQDN müssen nur im SPF-Record vorhanden sein.

[Arno Welzel]

Tim Ritberg, 2023-02-15 15:14:

> Am 15.02.23 um 14:09 schrieb Jan Novak:
>> Moin,
>>
>> ich habe für mich und Familie einen Postfix Mailserver seit rund 10
>> Jahren im Betrieb. Ein wichtiger Empfänger nimmt seit kurzem keine Mails
>> mehr von mir an wegen fehlendem SPF Eintrag.
>> Nun habe ich mich im Netz dazu durch diverse Infos gelesen, aber nicht
>> verstanden, wie ich das für meinen privaten Server nutzen kann.
>>
>> Meine Mail Domain habe ich bei Hetzner in deren DNS Robot konnektiert.
>>
>> Kann mir jemand einen einfachen Einstieg nennen, wie ich das umsetzen
>> kann (also kein stundenlanges Gewäsch wofür und was das ist)?
>>
>>
>> Jan
>
> Hatte ich neulich auch.
> Scheinbar gibt es einen neuen SPF-Standard.

Welcher soll das sein?

> Einige Parameter sind weggefallen und ganz lange TXT werden auch nicht
> mehr gemocht.

Quelle? Und was sollen "ganz lange TXT" sein?

[Arno Welzel]

Markus Schaaf, 2023-02-16 11:25:

ACK.

Aber zur Sinnhaftigkeit der Möglichkeiten: in meinem Fall habe ich ca.
40 Domains und mehrere Server, die für E-Mail-Versand relevant sind.

Klar kann ich bei jeder Domain manuell den SPF-Record anpassen, wenn
sich beim E-Mail-Versand etwas ändert. Es ist aber deutlich einfacher,
per "include:" eine Domain anzugeben, wo die IP-Adressen genannt werden.
Dann kann man sie viel leichter an *einer* Stelle ändern.

[Arno Welzel]

Markus Schaaf, 2023-02-16 21:55:

[...]

> Bei Hotmail kenne ich keinen Weg, da landet das meiste im
> Spamordner. GMX/Web.de sind auch schwierig, aber das nehme ich

[...]

Der Weg heißt: "keinen (virtuellen) Server bei einem Billighoster
mieten". Die sind nämlich fast immer auch direkt oder indirekt in der
Blacklist von Microsoft.

[Marcus Jodorf]

Arno Welzel <use...@arnowelzel.de> schrieb:

> Ob man das will, ist aber irrelevant, wenn man auch E-Mails an große
> Provider schicken können will. Da wird das schlicht erwartet.

Für spf würde ich das halb unterschreiben (macht bei meinen Servern
allerdings auch keinen feststellbaren Unterschied).
DKIM und DMARC braucht man nicht wirklich. Das ist so schrottig und
bekommen selbst die Großen oft nicht fehlerfrei auf die Reihe, daß
niemand das als entscheidendes Kriterium verwendet - höchstes fliest es
zum kleinen Teil ins Scoring ein. Meine Server verwenden es nicht,
meine Firmenserver verwenden es nicht. Keine Probleme.



Gruß,

Marcus
⚂⚃

[Marcus Jodorf]

Arno Welzel <use...@arnowelzel.de> schrieb:

> Und noch kürzer:
>
> TXT-Record mit folgenden Einträgen für die Domain anlegen
>
> v=spf1 ip4:127.0.0.1 ~all

Für die meisten Fälle noch viel einfacher:

v=spf1 mx ~all


Gruß,

Marcus
⚂⚃

[Tim Ritberg]

Am 19.02.23 um 01:11 schrieb Arno Welzel:

>> Hatte ich neulich auch.
>> Scheinbar gibt es einen neuen SPF-Standard.
>
> Welcher soll das sein?

https://www.rfc-editor.org/rfc/rfc7208#section-3.1
Von 2014. Meine Einträge waren älter.

>> Einige Parameter sind weggefallen und ganz lange TXT werden auch nicht
>> mehr gemocht.
>
> Quelle? Und was sollen "ganz lange TXT" sein?

"According to RFC 7208 Section 3.3, a single SPF record can exceed 255
characters, but a single string cannot."
Das hatte dann bei mir geknallt. Ich hatte dann ein Problem mit einem
Reputation Checker (Talos).
"ptr" soll man wohl auch nicht mehr benutzen.

Tim

[Tim Ritberg]

Am 19.02.23 um 01:19 schrieb Arno Welzel:

> Markus Schaaf, 2023-02-16 21:55:
>
> [...]
>> Bei Hotmail kenne ich keinen Weg, da landet das meiste im
>> Spamordner. GMX/Web.de sind auch schwierig, aber das nehme ich
> [...]
>
> Der Weg heißt: "keinen (virtuellen) Server bei einem Billighoster
> mieten". Die sind nämlich fast immer auch direkt oder indirekt in der
> Blacklist von Microsoft.
>

Kannst du aber Entfernen lassen. Ist halt Arbeit.

Tim

[Markus Schaaf]

Am 19.02.23 um 01:04 schrieb Arno Welzel:

>> Dann verwechselst Du das mit DKIM, was wesentlich aufwendiger
>> ist. Oder gar DMARC, einer Kombination aus SPF und DKIM, die von
>> Leuten entworfen wurde, die keine Ahnung von E-Mail haben.
>> Letzteres will man auf keinen Fall für die eigene Domain
>> implementieren.
>
> Ob man das will, ist aber irrelevant, wenn man auch E-Mails an große
> Provider schicken können will. Da wird das schlicht erwartet.

Wie ich schrieb: DKIM kann man machen, DMARC will man nicht. Ich
kenne auch keinen Empfänger, der DMARC verlangt. Aber selbst
wenn, wäre es mir egal. Die Abwägung ist ganz einfach: Will ich
auf den Mailinglisten gelesen werden, an denen ich mich aus
eigenem Antrieb beteilige, oder ist mir der gelegentliche
Hinterwäldler wichtig, der sich keine ordentliche E-Mail-Adresse
leisten will?

MfG

[Markus Schaaf]

Am 19.02.23 um 01:07 schrieb Arno Welzel:

> Was bei HELO gemeldet wird, ist für SPF komplett irrelevant!

Du irrst. EOD

[Tim Ritberg]

Am 19.02.23 um 00:58 schrieb Arno Welzel:

>
> TXT-Record mit folgenden Einträgen für die Domain anlegen
>
> v=spf1 ip4:127.0.0.1 ~all
>
> Und statt 127.0.0.1 natürlich die IP-Adresse des Servers, der den
> Versand macht. Und ja, die IP-Adresse sollte natürlich auch statisch
> sein. Ein Server an einem Internetzugang mit regelmäßig wechselnder
> Adresse und R-DNS-Eintrag, der auf "Dial-Up" hinweist, wird generell
> Probleme machen.

Meist pass der Parameter "mx" und "a". Es sei denn, man hat (noch mehr)
Webserver mit Formularen anders wo...

Tim

[Peter J. Holzer]

On 2023-02-19 10:09, Tim Ritberg <t...@server.invalid> wrote:
> Am 19.02.23 um 01:11 schrieb Arno Welzel:

>>> Scheinbar gibt es einen neuen SPF-Standard.
>>
>> Welcher soll das sein?
> https://www.rfc-editor.org/rfc/rfc7208#section-3.1
> Von 2014. Meine Einträge waren älter.
>
>>> Einige Parameter sind weggefallen und ganz lange TXT werden auch nicht
>>> mehr gemocht.
>>
>> Quelle? Und was sollen "ganz lange TXT" sein?
> "According to RFC 7208 Section 3.3, a single SPF record can exceed 255
> characters, but a single string cannot."

Wer auch immer das geschrieben hat, hat RFC 7208 Section 3.3 sehr
unaufmerksam gelesen. Da steht nämlich:

| If a published record contains multiple character-strings, then the
| record MUST be treated as if those strings are concatenated together
| without adding spaces.

Wenn jemand also nur den ersten String in einem Multi-String TXT Record
auswertet, verletzt er eine MUST-Bestimmung.

Allerdings warnt Section 3.4:

| Records that are too long to fit in a single UDP packet could be
| silently ignored by SPF verifiers due to firewall and other issues
| that interfere with the operation of DNS over TCP or using ENDS0.

Allzu lange TXT Records können also in der Praxis Probleme machen.
Oder auch allzu viele. Wenn man außer dem SPF Record noch diverse
site-verification Tokens hat, könnte das knapp werden.

> Das hatte dann bei mir geknallt. Ich hatte dann ein Problem mit einem
> Reputation Checker (Talos).

Reputation Checkern steht es natürlich frei, beliebige statistische
Zusammenhänge zu verwenden.

hp

[Peter J. Holzer]

On 2023-02-19 10:59, Peter J. Holzer <hjp-u...@hjp.at> wrote:
> On 2023-02-19 10:09, Tim Ritberg <t...@server.invalid> wrote:
>> Am 19.02.23 um 01:11 schrieb Arno Welzel:

>>>> Einige Parameter sind weggefallen und ganz lange TXT werden auch nicht
>>>> mehr gemocht.
>>>
>>> Quelle? Und was sollen "ganz lange TXT" sein?
>> "According to RFC 7208 Section 3.3, a single SPF record can exceed 255
>> characters, but a single string cannot."
>
> Wer auch immer das geschrieben hat, hat RFC 7208 Section 3.3 sehr
> unaufmerksam gelesen.

Oder Tim hat den Satz aus dem Zusammenhang gerissen. Falls er den Satz
von
https://mxtoolbox.com/problem/spf/spf-exceeds-maximum-character-limit
hat, geht der Text nämlich weiter mit:

| If more than 255 characters are needed, separate into multiple strings
| (e.g. "v=spf1 .... first" "second string...").

hp

[Tim Ritberg]

Am 19.02.23 um 11:59 schrieb Peter J. Holzer:

>> Das hatte dann bei mir geknallt. Ich hatte dann ein Problem mit einem
>> Reputation Checker (Talos).
>
> Reputation Checkern steht es natürlich frei, beliebige statistische
> Zusammenhänge zu verwenden.

Es sah den SPF als invalid an.
Nach einer Kürzung gings dann.

Tim

[Arno Welzel]

Markus Schaaf, 2023-02-19 11:14:

> Am 19.02.23 um 01:07 schrieb Arno Welzel:
>
>> Was bei HELO gemeldet wird, ist für SPF komplett irrelevant!
>
> Du irrst. EOD

Dann erkläre mal, was der Hostname im HELO mit SPF zu tun hat.

[Arno Welzel]

Tim Ritberg, 2023-02-19 11:09:

> Am 19.02.23 um 01:11 schrieb Arno Welzel:
>>> Hatte ich neulich auch.
>>> Scheinbar gibt es einen neuen SPF-Standard.
>>
>> Welcher soll das sein?
> https://www.rfc-editor.org/rfc/rfc7208#section-3.1
> Von 2014. Meine Einträge waren älter.

Was älteres als spf1 gibt es meines Wissens nach nicht.

>>> Einige Parameter sind weggefallen und ganz lange TXT werden auch nicht
>>> mehr gemocht.
>>
>> Quelle? Und was sollen "ganz lange TXT" sein?
> "According to RFC 7208 Section 3.3, a single SPF record can exceed 255
> characters, but a single string cannot."
> Das hatte dann bei mir geknallt. Ich hatte dann ein Problem mit einem
> Reputation Checker (Talos).
> "ptr" soll man wohl auch nicht mehr benutzen.

Danke für die Info.

[Arno Welzel]

Tim Ritberg, 2023-02-19 11:11:

Und nicht von Dauer. BTDT, mehrfach.

[Arno Welzel]

Marcus Jodorf, 2023-02-19 05:19:

Nur, wenn der MX auch gleichzeitig sendet. Bei mir tut er das nicht.

[Tim Ritberg]

Am 21.02.23 um 20:31 schrieb Arno Welzel:

> Tim Ritberg, 2023-02-19 11:09:
>
>> Am 19.02.23 um 01:11 schrieb Arno Welzel:
>>>> Hatte ich neulich auch.
>>>> Scheinbar gibt es einen neuen SPF-Standard.
>>>
>>> Welcher soll das sein?
>> https://www.rfc-editor.org/rfc/rfc7208#section-3.1
>> Von 2014. Meine Einträge waren älter.
>
> Was älteres als spf1 gibt es meines Wissens nach nicht.

Doch von 2006:
https://www.rfc-editor.org/rfc/rfc4408

Tim

[Peter J. Holzer]

On 2023-02-21 19:29, Arno Welzel <use...@arnowelzel.de> wrote:
> Markus Schaaf, 2023-02-19 11:14:
>
>> Am 19.02.23 um 01:07 schrieb Arno Welzel:
>>
>>> Was bei HELO gemeldet wird, ist für SPF komplett irrelevant!
>>
>> Du irrst. EOD
>
> Dann erkläre mal, was der Hostname im HELO mit SPF zu tun hat.

https://www.rfc-editor.org/rfc/rfc7208#section-2.3

| It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
| identity but also separately check the "HELO" identity by applying
| the check_host() function (Section 4) to the "HELO" identity as the
| <sender>.

https://www.rfc-editor.org/rfc/rfc7208#section-10.1.2

| Publishing SPF records for individual hosts is also best practice.
| The host name is generally the identity used in the 5321.HELO/.EHLO
| command. In the case of messages with a null 5321.MailFrom, this is
| used as the domain for 5321.MailFrom SPF checks, in addition to being
| used in 5321.HELO/.EHLO-based SPF checks.

[Peter J. Holzer]

SPF ist noch ein paar Jahre älter:

<https://en.wikipedia.org/wiki/Sender_Policy_Framework#History>:
| In June 2003, Meng Weng Wong merged the RMX and DMP specifications[9]
| and solicited suggestions from others. Over the next six months, a
| large number of changes were made and a large community had started
| working on SPF.[10] Originally SPF stood for Sender Permitted From and
| was sometimes also called SMTP+SPF; but its name was changed to Sender
| Policy Framework in February 2004.

An die Umbenennung kann ich mich noch erinnern, also habe ich mir das
offensichtlich 2003 das erste mal angeschaut.

hp

[Marco Moock]

Was ist mit bounces?
Die kommen normalerweise von MAILER...@srv1.example.org

[Marcus Jodorf]

Arno Welzel <use...@arnowelzel.de> schrieb:

>> Für die meisten Fälle noch viel einfacher:
>>
>> v=spf1 mx ~all
>
> Nur, wenn der MX auch gleichzeitig sendet. Bei mir tut er das nicht.

Ja natürlich. Deshalb „die meisten Fälle“ - dürfte bei selbstgehosteten Servern
vorherrschend sein.
Ich hätte es aber unmißverständlicher ausdrücken sollen.


Gruß,

Marcus
⚂⚃

[Peter J. Holzer]

On 2023-02-21 21:10, Marco Moock <mo...@posteo.de> wrote:
> Am 19.02.2023 um 01:09:33 Uhr schrieb Arno Welzel:
>> Der Record muss nur für example.org existieren. Denn das ist die
>> Domain, für die die E-Mail-Adresse i...@example.org relevant ist. Wie
>> der Server sich selber nennt, der die E-Mail sendet, ist völlig egal.

Nein.

>> Seine IP-Adresse oder der FQDN müssen nur im SPF-Record vorhanden
>> sein.
>
> Was ist mit bounces?
> Die kommen normalerweise von MAILER...@srv1.example.org

Nein, die kommen von <>.
Was genau der Grund ist, warum in SPF in diesem Fall der HELO/EHLO-Name
des MTAs geprüft werden soll.

hp

[Arno Welzel]

Peter J. Holzer, 2023-02-21 21:40:

> On 2023-02-21 19:29, Arno Welzel <use...@arnowelzel.de> wrote:
>> Markus Schaaf, 2023-02-19 11:14:
>>
>>> Am 19.02.23 um 01:07 schrieb Arno Welzel:
>>>
>>>> Was bei HELO gemeldet wird, ist für SPF komplett irrelevant!
>>>
>>> Du irrst. EOD
>>
>> Dann erkläre mal, was der Hostname im HELO mit SPF zu tun hat.
>
>
> https://www.rfc-editor.org/rfc/rfc7208#section-2.3
>
> | It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
> | identity but also separately check the "HELO" identity by applying
> | the check_host() function (Section 4) to the "HELO" identity as the
> | <sender>.

Und weiter:

| Note that requirements for the domain presented in the EHLO or HELO
| command are not always clear to the sending party, and SPF verifiers
| have to be prepared for the identity to be an IP address literal (see
| [RFC5321], Section 4.1.3) or simply be malformed. This SPF check can
| only be performed when the "HELO" string is a valid, multi-label
| domain name.

Es ist also keineswegs so, dass die Angabe in HELO immer exakt so wie
sie ist, für SPF relevant wäre.

> https://www.rfc-editor.org/rfc/rfc7208#section-10.1.2
>
> | Publishing SPF records for individual hosts is also best practice.
> | The host name is generally the identity used in the 5321.HELO/.EHLO
> | command. In the case of messages with a null 5321.MailFrom, this is
> | used as the domain for 5321.MailFrom SPF checks, in addition to being
> | used in 5321.HELO/.EHLO-based SPF checks.

Ja - "generally generally the identity used in the 5321.HELO/.EHLO
command" - aber eben nicht zwingend.

[Arno Welzel]

Marco Moock, 2023-02-21 22:10:

> Am 19.02.2023 um 01:09:33 Uhr schrieb Arno Welzel:

[...]

>> Der Record muss nur für example.org existieren. Denn das ist die
>> Domain, für die die E-Mail-Adresse i...@example.org relevant ist. Wie
>> der Server sich selber nennt, der die E-Mail sendet, ist völlig egal.
>> Seine IP-Adresse oder der FQDN müssen nur im SPF-Record vorhanden
>> sein.
>
> Was ist mit bounces?
> Die kommen normalerweise von MAILER...@srv1.example.org

Bounces sollten gar nicht von einem Server zum anderen geschickt werden,
sondern nur direkt als Nachricht an den einliefernden Absender auf dem
Server generiert werden, der die Nachricht vom MUA bekommen hat.

Konkretes Beispiel:

Du schickst z.B. über deinen Smarthost eine E-Mail, die an einen anderen
Server, der als MX fungiert, ausgeliefert wird.

Der MX antwortet beim Zustellversuch via SMTP damit, dass die Mail
dauerhaft nicht angenommen werden kann.

Dieser Fehler führt dann beim Smarthost dazu, dass er eine Mail mit
Absender MAILER...@srv1.example.org an den Envelope-From mit edr
Fehlermeldung des MX generiert.

Wenn ein MX die Mail aber ohne Fehlermeldung annimmt, wird er nicht
nachträglich eine Antwort an den vermeintlichen Absender zurücksenden,
dass es bei der weiteren Verarbeitung einen Fehler gab - denn das wäre
Backscatter, den Spammer missbrauchen könnten und der meist dazu führt,
dass solche Server auf Blacklists landen.

[Arno Welzel]

Peter J. Holzer, 2023-02-21 23:28:

> On 2023-02-21 21:10, Marco Moock <mo...@posteo.de> wrote:
>> Am 19.02.2023 um 01:09:33 Uhr schrieb Arno Welzel:
>>> Der Record muss nur für example.org existieren. Denn das ist die
>>> Domain, für die die E-Mail-Adresse i...@example.org relevant ist. Wie
>>> der Server sich selber nennt, der die E-Mail sendet, ist völlig egal.
>
> Nein.

Der SPF-Record muss logischerweise bei der Domain eingetragen werden,
von der aus E-Mails versendet werden und nicht bei der die Domain, in
der der Server steht, über den versendet wird.

Natürlich muss *im* SPF-Record angegeben sein, welche Server berechtigt
sind, E-Mails für eine Domain zu senden. Aber das müssen nicht Hostnamen
sein, sondern können IP-Adressen sein.

Konkret:

Wenn ich E-Mails mit der Absenderdomain "arnowelzel.de" sende, muss
logischerweise auch *da* ein SPF-Record existieren, welche Server das
tun dürfen.

>>> Seine IP-Adresse oder der FQDN müssen nur im SPF-Record vorhanden
>>> sein.
>>
>> Was ist mit bounces?
>> Die kommen normalerweise von MAILER...@srv1.example.org
>
> Nein, die kommen von <>.
> Was genau der Grund ist, warum in SPF in diesem Fall der HELO/EHLO-Name
> des MTAs geprüft werden soll.

Ja, wenn man Backscatter durchlassen will.

[Arno Welzel]

Tim Ritberg, 2023-02-21 21:19:

Das ist auch SPF Version 1 - also nicht älter. Nur das RFC ist älter.

Vergleiche:

<https://www.rfc-editor.org/rfc/rfc4408>

"Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail, Version 1"

<https://www.rfc-editor.org/rfc/rfc7208>

"Sender Policy Framework (SPF)
for Authorizing Use of Domains in Email, Version 1"

In der neueren RFC ist nur erläutert, das man "ptr" nicht mehr verwenden
soll:

<https://www.rfc-editor.org/rfc/rfc4408#section-5>
<https://www.rfc-editor.org/rfc/rfc7208#section-5>

Man hätte auch einfach eine neuere SPF-Version definieren können, bei
der "ptr" explizit entfällt. Aber die zu erwartenden Probleme, wenn
Systeme nichts mit "v=spf2.0" anzufangen wissen, hat man damit gelöst,
dass "v=spf1" als weiterhin zulässige Angabe erlaubt ist, auch wenn man
sich nach RFC7208 richtet.

[Arno Welzel]

Peter J. Holzer, 2023-02-21 21:43:

Und auch da war es schon SPF Version 1 und nichts älteres.

[Marco Moock]

Gegen Backscatter kannst du dich eigentlich nur sinnvoll wehren, indem
nur Empfänger-Adressen zulässt, die auch zugestellt werden können.

[Marco Moock]

Am 24.02.2023 um 09:03:42 Uhr schrieb Arno Welzel:

> Wenn ein MX die Mail aber ohne Fehlermeldung annimmt, wird er nicht
> nachträglich eine Antwort an den vermeintlichen Absender zurücksenden,
> dass es bei der weiteren Verarbeitung einen Fehler gab - denn das wäre
> Backscatter, den Spammer missbrauchen könnten und der meist dazu
> führt, dass solche Server auf Blacklists landen.

Das ist aber der Normalzustand - denn sonst würde die Leute keine Info
bekommen, wenn die Adresse nicht mehr existiert, Tippfehler passierten
etc.

Daher ist es eine sinnvolle Idee, auf dem eigenen MX nur die
Ziel-Adressen zuzulassen, die man auch zustellen kann. Ich kenne aber
Umgebungen, in denen das nicht praktiziert wird. Da gibt es dann ab und
zu Backscatter-Attacken und die MX-Server landen auf ner Blacklist.

[Arno Welzel]

Marco Moock, 2023-02-24 10:15:

> Am 24.02.2023 um 09:03:42 Uhr schrieb Arno Welzel:
>
>> Wenn ein MX die Mail aber ohne Fehlermeldung annimmt, wird er nicht
>> nachträglich eine Antwort an den vermeintlichen Absender zurücksenden,
>> dass es bei der weiteren Verarbeitung einen Fehler gab - denn das wäre
>> Backscatter, den Spammer missbrauchen könnten und der meist dazu
>> führt, dass solche Server auf Blacklists landen.
>
> Das ist aber der Normalzustand - denn sonst würde die Leute keine Info
> bekommen, wenn die Adresse nicht mehr existiert, Tippfehler passierten
> etc.

Fehler wie "Adresse existiert nicht" meldet der MX aber *sofort* im
SMTP-Dialog und *nicht* *nach* der Annahme der E-Mail mit einer
separaten E-Mail an den Absender.

> Daher ist es eine sinnvolle Idee, auf dem eigenen MX nur die
> Ziel-Adressen zuzulassen, die man auch zustellen kann. Ich kenne aber
> Umgebungen, in denen das nicht praktiziert wird. Da gibt es dann ab und
> zu Backscatter-Attacken und die MX-Server landen auf ner Blacklist.

Nicht nur sinnvoll - das ist der Normalzustand. Ein MX wird generell
nichts annehmen, was er nicht zustellen kann.

[Tim Ritberg]

Am 24.02.23 um 16:42 schrieb Arno Welzel:

> Fehler wie "Adresse existiert nicht" meldet der MX aber *sofort* im
> SMTP-Dialog und *nicht* *nach* der Annahme der E-Mail mit einer
> separaten E-Mail an den Absender.

Kann man bei Postfix umstellen. Das ist aber eine dumme Idee :-D

> Nicht nur sinnvoll - das ist der Normalzustand. Ein MX wird generell
> nichts annehmen, was er nicht zustellen kann.

Kommt drauf an. MXer, die nur Relay sind/Smarthost haben einen verify
cache. Es ist ja auch nicht so unüblich, seinen internen Mailserver
hinter öffentlichen Servern zu verstecken.

Tim

[Marco Moock]

Am 24.02.2023 um 16:42:51 Uhr schrieb Arno Welzel:

> Fehler wie "Adresse existiert nicht" meldet der MX aber *sofort* im
> SMTP-Dialog und *nicht* *nach* der Annahme der E-Mail mit einer
> separaten E-Mail an den Absender.

Das kommt drauf an. sendmail kann sowas (kann man glaub durch ein Flag
im local-Mailer ändern). Das kann aber nur funktionieren, wenn der
Abfragen kann, welche User es gibt. Nimmt man den Cyrus-Mailer ist das
deaktiviert und der nimmt alles an, was für die Domains in cw ist.
Ist das Ziel ein anderer Server gibt es wieder diese Problematik.

Man kann aber eine User-Whitelist einrichten, die man aber irgendwie
aktuell halten muss.
Ich kenne Umgebungen, in denen sowas nicht passiert. Da wird alles für
eine Domain angenommen und dann gibts nen Bounce.

> > Daher ist es eine sinnvolle Idee, auf dem eigenen MX nur die
> > Ziel-Adressen zuzulassen, die man auch zustellen kann. Ich kenne
> > aber Umgebungen, in denen das nicht praktiziert wird. Da gibt es
> > dann ab und zu Backscatter-Attacken und die MX-Server landen auf
> > ner Blacklist.
>
> Nicht nur sinnvoll - das ist der Normalzustand. Ein MX wird generell
> nichts annehmen, was er nicht zustellen kann.

Wie gesagt, er muss das vorher wissen, gerade in komplexen Umgebungen
ist sowas schwer umsetzbar.

[Peter J. Holzer]

On 2023-02-24 08:22, Arno Welzel <use...@arnowelzel.de> wrote:
> Peter J. Holzer, 2023-02-21 23:28:
>> On 2023-02-21 21:10, Marco Moock <mo...@posteo.de> wrote:
>>> Am 19.02.2023 um 01:09:33 Uhr schrieb Arno Welzel:
>>>> Der Record muss nur für example.org existieren. Denn das ist die
>>>> Domain, für die die E-Mail-Adresse i...@example.org relevant ist. Wie
>>>> der Server sich selber nennt, der die E-Mail sendet, ist völlig egal.
>>
>> Nein.
>
> Der SPF-Record muss logischerweise bei der Domain eingetragen werden,

Ja. Aber nur weil due es dort eintragen musst, heißt nicht, dass ein
Eintrag an anderer Stelle (nämlich beim HELO-Name) "völlig egal" wäre.
Der hat sehr wohl auch eine Bedeutung.

hp

[Arno Welzel]

Peter J. Holzer, 2023-02-24 20:34:

Nur dann, wenn die Domain im SPF-Record als Kriterium genannt ist.

[Arno Welzel]

Tim Ritberg, 2023-02-24 17:20:

> Am 24.02.23 um 16:42 schrieb Arno Welzel:
>> Fehler wie "Adresse existiert nicht" meldet der MX aber *sofort* im
>> SMTP-Dialog und *nicht* *nach* der Annahme der E-Mail mit einer
>> separaten E-Mail an den Absender.
> Kann man bei Postfix umstellen. Das ist aber eine dumme Idee :-D
>
>> Nicht nur sinnvoll - das ist der Normalzustand. Ein MX wird generell
>> nichts annehmen, was er nicht zustellen kann.
> Kommt drauf an. MXer, die nur Relay sind/Smarthost haben einen verify

[...]

Ein Relay oder Smarthost ist kein MX.

Ein MX ist per Definition *immer* der Server, der Mails für eine Domain
annimmt. Deswegen gibt es auch einen entsprechenden DNS-Record dafür.

[Arno Welzel]

Marco Moock, 2023-02-24 18:23:

> Am 24.02.2023 um 16:42:51 Uhr schrieb Arno Welzel:
>
>> Fehler wie "Adresse existiert nicht" meldet der MX aber *sofort* im
>> SMTP-Dialog und *nicht* *nach* der Annahme der E-Mail mit einer
>> separaten E-Mail an den Absender.
>
> Das kommt drauf an. sendmail kann sowas (kann man glaub durch ein Flag
> im local-Mailer ändern). Das kann aber nur funktionieren, wenn der
> Abfragen kann, welche User es gibt. Nimmt man den Cyrus-Mailer ist das
> deaktiviert und der nimmt alles an, was für die Domains in cw ist.
> Ist das Ziel ein anderer Server gibt es wieder diese Problematik.

Genau deshalb ist sowas nicht sinnvoll.

[...]

>> Nicht nur sinnvoll - das ist der Normalzustand. Ein MX wird generell
>> nichts annehmen, was er nicht zustellen kann.
>
> Wie gesagt, er muss das vorher wissen, gerade in komplexen Umgebungen
> ist sowas schwer umsetzbar.

Auch in "komplexen" Umgebungen ist bekannt, welche E-Mail-Adressen es
gibt - sonst könnte man E-Mail nämlich gar nicht zustellen. Und genau
diese Information muss der MX haben. Mail erst anzunehmen und danach mit
einer separaten E-Mail an den vermeintlichen Absender zu antworten, ist
maximaler Mist und wird fast immer als unerwünschter Spam eingestuft.

[Marco Moock]

Am 25.02.2023 um 17:11:55 Uhr schrieb Arno Welzel:

> Auch in "komplexen" Umgebungen ist bekannt, welche E-Mail-Adressen es
> gibt - sonst könnte man E-Mail nämlich gar nicht zustellen.

Das stimmt so nicht - vor allem dann nicht, wenn unterschiedliche Leute
die Server administrieren und es keine zentrale Benutzerverwaltung/DB
mit Adressen gibt.

> Und genau diese Information muss der MX haben. Mail erst anzunehmen und danach
> mit einer separaten E-Mail an den vermeintlichen Absender zu
> antworten, ist maximaler Mist und wird fast immer als unerwünschter
> Spam eingestuft.

Das stimmt, wird aber in manchem Umgebungen so praktiziert. Kenne ich
aus dem Alltag.

[Tim Ritberg]

Am 25.02.23 um 17:09 schrieb Arno Welzel:

>> Kommt drauf an. MXer, die nur Relay sind/Smarthost haben einen verify
> [...]
>
> Ein Relay oder Smarthost ist kein MX.
>
> Ein MX ist per Definition *immer* der Server, der Mails für eine Domain
> annimmt. Deswegen gibt es auch einen entsprechenden DNS-Record dafür.

Er entscheidet aber nicht immer wirklich selbst über den Bounce.
Das tut ein nachgelagertes System, daher passt die Bezeichnung Relay.

Tim

[Heiko Schlichting]

Marco Moock <mo...@posteo.de> wrote:
> Am 25.02.2023 um 17:11:55 Uhr schrieb Arno Welzel:
>
>> Auch in "komplexen" Umgebungen ist bekannt, welche E-Mail-Adressen es
>> gibt - sonst könnte man E-Mail nämlich gar nicht zustellen.
>
> Das stimmt so nicht - vor allem dann nicht, wenn unterschiedliche Leute
> die Server administrieren und es keine zentrale Benutzerverwaltung/DB
> mit Adressen gibt.

Dann kann man callouts nutzen, um den nachgelagerten Server vorher zu
fragen - falls nötig über mehrere Server hinweg. Alles besser als Mail erst
anzunehmen und später eine Fehlermeldung zu produzieren (--> backscatter
spam).

Heiko

[Tim Ritberg]

Am 25.02.23 um 22:53 schrieb Heiko Schlichting:

Postfix nutzt einen Cache und kann da auch mal "falsch" annehmen.

Tim

[Arno Welzel]

Tim Ritberg, 2023-02-25 19:13:

> Am 25.02.23 um 17:09 schrieb Arno Welzel:
>>> Kommt drauf an. MXer, die nur Relay sind/Smarthost haben einen verify
>> [...]
>>
>> Ein Relay oder Smarthost ist kein MX.
>>
>> Ein MX ist per Definition *immer* der Server, der Mails für eine Domain
>> annimmt. Deswegen gibt es auch einen entsprechenden DNS-Record dafür.
>
> Er entscheidet aber nicht immer wirklich selbst über den Bounce.

Sollte er aber.

> Das tut ein nachgelagertes System, daher passt die Bezeichnung Relay.

Das Problem ist halt, dass ein Bounce, der als separate E-Mail an einen
vermeintlichen Absender geht, sich nicht von Spam unterscheiden lässt.

[Arno Welzel]

Marco Moock, 2023-02-25 17:39:

> Am 25.02.2023 um 17:11:55 Uhr schrieb Arno Welzel:
>
>> Auch in "komplexen" Umgebungen ist bekannt, welche E-Mail-Adressen es
>> gibt - sonst könnte man E-Mail nämlich gar nicht zustellen.
>
> Das stimmt so nicht - vor allem dann nicht, wenn unterschiedliche Leute
> die Server administrieren und es keine zentrale Benutzerverwaltung/DB
> mit Adressen gibt.

Du meinst, dass es dem MX nicht bekannt ist und er einfach alles
annimmt. Ich meinte aber, dass es generell so sein *muss*, dass man
entscheiden kann, on eine E-Mail zustellbar ist oder nicht - egal wie
man das herausfindet. Wenn der MX das selber nicht kann, ist es halt
maximal unschön.

>> Und genau diese Information muss der MX haben. Mail erst anzunehmen und danach
>> mit einer separaten E-Mail an den vermeintlichen Absender zu
>> antworten, ist maximaler Mist und wird fast immer als unerwünschter
>> Spam eingestuft.
>
> Das stimmt, wird aber in manchem Umgebungen so praktiziert. Kenne ich
> aus dem Alltag.

Darf man erfahren, welche Institutionen das so handhaben oder ist das
eine vertrauliche Angabe?

[Tim Ritberg]

Am 26.02.23 um 02:22 schrieb Arno Welzel:

> Darf man erfahren, welche Institutionen das so handhaben oder ist das
> eine vertrauliche Angabe?

Ich habe solche Setups auch schon gesehen.

Ich ein Praxisbericht:
https://www.parallel42.ca/2021/03/10/Postfix-Recipient-Verification.html

Tim

[Tim Ritberg]

Am 26.02.23 um 02:18 schrieb Arno Welzel:

>> Er entscheidet aber nicht immer wirklich selbst über den Bounce.
>
> Sollte er aber.
>
>> Das tut ein nachgelagertes System, daher passt die Bezeichnung Relay.
>
> Das Problem ist halt, dass ein Bounce, der als separate E-Mail an einen
> vermeintlichen Absender geht, sich nicht von Spam unterscheiden lässt.

Du verstehst das falsch.
Es gibt keine Bouncemail vom nachgelagerten System, nur eine falsche
Entscheidung vom Relay.

Tim

[Peter J. Holzer]

On 2023-02-26 09:54, Tim Ritberg <t...@server.invalid> wrote:
> Am 26.02.23 um 02:18 schrieb Arno Welzel:
>>> Er entscheidet aber nicht immer wirklich selbst über den Bounce.
>>
>> Sollte er aber.
>>
>>> Das tut ein nachgelagertes System, daher passt die Bezeichnung Relay.
>>
>> Das Problem ist halt, dass ein Bounce, der als separate E-Mail an einen
>> vermeintlichen Absender geht, sich nicht von Spam unterscheiden lässt.

Zwar hindert nichts einen Spammer, fake Bounces zu erzeugen, da die aber
normalerweise nicht dafür geeignet sind, das Ziel das Spams (irgendwas
zu verkaufen oder zu phishen) zu erreichen, tun Spammer das nicht (mehr).
Joe-Jobs mögen noch gelegentlich vorkommen, habe ich aber auch schon
lange nicht mehr gesehen (vermutlich wegen SPF).

> Du verstehst das falsch.
> Es gibt keine Bouncemail vom nachgelagerten System, nur eine falsche
> Entscheidung vom Relay.

Diese falsche Entscheidung sollte bei einem standardkonform
konfigurierten nachgelagerten System aber zu einer Bouncemail führen.

hp

[Tim Ritberg]

Am 26.02.23 um 12:11 schrieb Peter J. Holzer:

>
>> Du verstehst das falsch.
>> Es gibt keine Bouncemail vom nachgelagerten System, nur eine falsche
>> Entscheidung vom Relay.
>
> Diese falsche Entscheidung sollte bei einem standardkonform
> konfigurierten nachgelagerten System aber zu einer Bouncemail führen.
>

Das Relay lehnt ab! Entweder zu früh (Cachetreffer) oder nach
Relayversuch (Ziel lehnt ab).

Tim

[Stefan Froehlich]

Zu dem Zeitpunkt, wo das Ziel ablehnt, ist es für das Relay idR zum
Ablehnen bereits zu spät (ansonsten ist es kaum mehr als
Port-Forwarding). Es bleibt dann nur noch die Wahl zwischen einer
Bounce-Mail oder dem kommentarlosen Entsorgen der bereits
angenommenen Mail.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Albern im grenzenlosen Sein - Stefan, so wundervoll wie der Bundestag!
(Sloganizer)

[Tim Ritberg]

Am 26.02.23 um 14:16 schrieb Stefan Froehlich:

>
> Zu dem Zeitpunkt, wo das Ziel ablehnt, ist es für das Relay idR zum
> Ablehnen bereits zu spät (ansonsten ist es kaum mehr als
> Port-Forwarding). Es bleibt dann nur noch die Wahl zwischen einer
> Bounce-Mail oder dem kommentarlosen Entsorgen der bereits
> angenommenen Mail.

Du benutzt kein Postfix oder?

Tim

[Arno Welzel]

Tim Ritberg, 2023-02-26 10:54:

Was auch Mist ist - dann verschwindet die E-Mail einfach, ohne dass
irgendjemand etwas davon merkt.

[Arno Welzel]

Tim Ritberg, 2023-02-26 14:34:

Wenn Postfix eingehende Mails per SMTP oder LMTP weitergibt, werden
Mails an nicht existierende Adressen in der Regel gleich abgelehnt und
nicht erst *nach* Annahme selbiger.

[Arno Welzel]

Tim Ritberg, 2023-02-26 10:50:

Ja, ein Cache kann veralten - sowohl bzgl. der Aussage "Adresse
unbekannt" wie auch "Adresse gültig". Deswegen ist es immer gut, *vor*
dem Einsatz solcher Mechanismen genau zu überlegen, welche Konsequenzen
das hat und wie man damit ungeht.

[Peter J. Holzer]

On 2023-02-26 11:47, Tim Ritberg <t...@server.invalid> wrote:
> Am 26.02.23 um 12:11 schrieb Peter J. Holzer:

>>> Es gibt keine Bouncemail vom nachgelagerten System, nur eine falsche

^^^^^^^
>>> Entscheidung vom Relay.
^^^^^^^^^^^^

>> Diese falsche Entscheidung sollte bei einem standardkonform
>> konfigurierten nachgelagerten System

oder Relay

>> aber zu einer Bouncemail führen.
>
> Das Relay lehnt ab! Entweder zu früh (Cachetreffer) oder nach
> Relayversuch (Ziel lehnt ab).

Dann ist die Entscheidung ja nicht falsch. Wenn die Entscheidung falsch
ist (d.h. das Relay nimmt die Mail an, obwohl es sie ablehnen hätte
müssen, denn nur dieser Fall ist hier relevant), dann MUSS das Relay
eine Bounce-Mail verschicken, wenn es bemerkt, dass es die Mail doch
nicht zustellen kann (oder eines der nachgelagerten Systeme muss das
tun, wenn es in der gleichen Situation ist).

hp

[Marco Moock]

Das kannst du selbst ausprobieren:
ungu...@uni-heidelberg.de.invalid (das invalid hinten weg) und
schaue, woher der Bounce kommt. :-)
Bitte aber nicht zu oft machen.

[Tim Ritberg]

Am 26.02.23 um 16:42 schrieb Peter J. Holzer:

>> Das Relay lehnt ab! Entweder zu früh (Cachetreffer) oder nach
>> Relayversuch (Ziel lehnt ab).
>
> Dann ist die Entscheidung ja nicht falsch. Wenn die Entscheidung falsch
> ist (d.h. das Relay nimmt die Mail an, obwohl es sie ablehnen hätte
> müssen, denn nur dieser Fall ist hier relevant), dann MUSS das Relay
> eine Bounce-Mail verschicken, wenn es bemerkt, dass es die Mail doch
> nicht zustellen kann (oder eines der nachgelagerten Systeme muss das
> tun, wenn es in der gleichen Situation ist).
>

Nein, er wird direkt ablehnen.
"Recipient address verification is relatively straightforward and there
are no surprises. If a recipient probe fails, then Postfix rejects mail
for the recipient address. If a recipient probe succeeds, then Postfix
accepts mail for the recipient address. However, recipient address
verification probes can increase the load on down-stream MTAs when
you're being flooded by backscatter bounces, or when some spammer is
mounting a dictionary attack.

By default, address verification results are saved in a persistent
database (Postfix version 2.7 and later; with earlier versions, specify
the database in main.cf as described later). The persistent database
helps to avoid probing the same address repeatedly."

https://www.postfix.org/ADDRESS_VERIFICATION_README.html

Tim

[Tim Ritberg]

Am 26.02.23 um 15:20 schrieb Arno Welzel:

> Ja, ein Cache kann veralten - sowohl bzgl. der Aussage "Adresse
> unbekannt" wie auch "Adresse gültig". Deswegen ist es immer gut, *vor*
> dem Einsatz solcher Mechanismen genau zu überlegen, welche Konsequenzen
> das hat und wie man damit ungeht.

Ich habe ein Setup, wo das gut klappt. Adressänderungen sind selten im Jahr.
Ausserdem kann man ja den Cache noch löschen.

Tim

[Peter J. Holzer]

On 2023-02-26 19:25, Tim Ritberg <t...@server.invalid> wrote:
> Am 26.02.23 um 16:42 schrieb Peter J. Holzer:
>>> Das Relay lehnt ab! Entweder zu früh (Cachetreffer) oder nach
>>> Relayversuch (Ziel lehnt ab).
>>
>> Dann ist die Entscheidung ja nicht falsch. Wenn die Entscheidung falsch
>> ist (d.h. das Relay nimmt die Mail an, obwohl es sie ablehnen hätte
>> müssen, denn nur dieser Fall ist hier relevant), dann MUSS das Relay
>> eine Bounce-Mail verschicken, wenn es bemerkt, dass es die Mail doch
>> nicht zustellen kann (oder eines der nachgelagerten Systeme muss das
>> tun, wenn es in der gleichen Situation ist).
>>
> Nein, er wird direkt ablehnen.

Ok, dann erkläre bitte, was Du mit "falsche Entscheidung" gemeint hast.

Eine Ablehnung, ist meiner meiner Meinung nach die *richtige*
Entscheidung, wenn der Empfänger nicht existiert.

hp

[Tim Ritberg]

Am 26.02.23 um 22:34 schrieb Peter J. Holzer:

> Eine Ablehnung, ist meiner meiner Meinung nach die *richtige*
> Entscheidung, wenn der Empfänger nicht existiert.

Auch andere (temp.) Zustellfehler werden gecacht.

Tim

[Paul Muster]

Auch Exim kann cutthrough-delivery, das ist also nicht Postfix vorbehalten.
Das ist - egal, mit welchem MTA - allerdings schon recht hohe Schule.
Daher kein großes Problem, dass Stefan es nicht kennt.


mfG Paul

[Peter J. Holzer]

Ich sehe, von Dir bekomme ich keine Antwort.

hp

[Heiko Schlichting]

Tim Ritberg <t...@server.invalid> wrote:
> Am 25.02.23 um 22:53 schrieb Heiko Schlichting:
>>

>> Dann kann man callouts nutzen, um den nachgelagerten Server vorher zu
>> fragen - falls nötig über mehrere Server hinweg. Alles besser als Mail erst
>> anzunehmen und später eine Fehlermeldung zu produzieren (--> backscatter
>> spam).
>>
>
> Postfix nutzt einen Cache und kann da auch mal "falsch" annehmen.

Ich benutze Exim und da gibt es auch die Möglichkeit, die Ergebnisse in
einem Cache zu speichern. Aber die Zeiten für positive oder negative
Treffer kann man konfigurieren und wenn man möchte, kann man den Cache
natürlich auch abschalten.

Heiko

[Heiko Schlichting]

Paul Muster <exp-3...@news.muster.net> wrote:
> On 26.02.23 14:34, Tim Ritberg wrote:
>> Am 26.02.23 um 14:16 schrieb Stefan Froehlich:
>
>>> Zu dem Zeitpunkt, wo das Ziel ablehnt, ist es für das Relay idR zum
>>> Ablehnen bereits zu spät (ansonsten ist es kaum mehr als
>>> Port-Forwarding). Es bleibt dann nur noch die Wahl zwischen einer
>>> Bounce-Mail oder dem kommentarlosen Entsorgen der bereits
>>> angenommenen Mail.
>
>> Du benutzt kein Postfix oder?
>
> Auch Exim kann cutthrough-delivery, das ist also nicht Postfix vorbehalten.
> Das ist - egal, mit welchem MTA - allerdings schon recht hohe Schule.

Man muss hier nicht mit Kanonen auf Spatzen schießen. Wenn man nur die
Adresse prüfen will, so reicht callout völlig aus. Das passiert
typischerweise bereits bei "RCPT TO:". Die Konfiguration von callouts ist
nicht so schwierig.

Erst wenn man inhaltsbasierte (also dem Teil nach DATA) Ergebnisse vom Ziel
benötigt, wäre cutthrough-Delivery nötig. Das ist dann wirklich etwas
tricky, weil man es nicht mit allen anderen Features kombinieren kann. Aber
falls nötig, kann man es auch verwenden. Habe ich hier auch für eine
spezielle Anwendung erfolgreich im Einsatz.

Heiko

[Tim Ritberg]

Am 27.02.23 um 14:14 schrieb Peter J. Holzer:

Du hattest also keine Lust den Postfix-Link zu lesen?

Tim

[Stefan Froehlich]

Nein, aber selbst wenn.

Ausser vielleicht für sehr große Installationen sehe ich wenig
Nutzen hinter so einem Setup: Wenn der nachgelagerte Mailserver
gerade aktiv ist, könnte er die Mail auch gleich selber annehmen,
ist er das aus irgendeinem Grund nicht, klappt der beschriebene
Mechanismus nicht. Das kann ich z.B. durch Vergabe niedrigerer
Priorität an den MX auch einfacher erreichen (bzw. mache ich genau
das).

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Der gehängte Freund verschenkt Stefan. Und Sie?
(Sloganizer)

[Tim Ritberg]

Am 27.02.23 um 17:54 schrieb Stefan Froehlich:

> On Sun, 26 Feb 2023 14:34:25 Tim Ritberg wrote:
>> Am 26.02.23 um 14:16 schrieb Stefan Froehlich:
>>> Zu dem Zeitpunkt, wo das Ziel ablehnt, ist es für das Relay idR
>>> zum Ablehnen bereits zu spät (ansonsten ist es kaum mehr als
>>> Port-Forwarding). Es bleibt dann nur noch die Wahl zwischen einer
>>> Bounce-Mail oder dem kommentarlosen Entsorgen der bereits
>>> angenommenen Mail.
>
>> Du benutzt kein Postfix oder?
>
> Nein, aber selbst wenn.
>
> Ausser vielleicht für sehr große Installationen sehe ich wenig
> Nutzen hinter so einem Setup: Wenn der nachgelagerte Mailserver
> gerade aktiv ist, könnte er die Mail auch gleich selber annehmen,
> ist er das aus irgendeinem Grund nicht, klappt der beschriebene
> Mechanismus nicht. Das kann ich z.B. durch Vergabe niedrigerer
> Priorität an den MX auch einfacher erreichen (bzw. mache ich genau
> das).

Natürlich klappt das und wird auch für das böse Exchange empfohlen,
welches man nicht so pur im Internet haben will.

Tim

[Paul Muster]

On 27.02.23 17:54, Stefan Froehlich wrote:
> On Sun, 26 Feb 2023 14:34:25 Tim Ritberg wrote:
>> Am 26.02.23 um 14:16 schrieb Stefan Froehlich:

>>> Zu dem Zeitpunkt, wo das Ziel ablehnt, ist es für das Relay idR
>>> zum Ablehnen bereits zu spät (ansonsten ist es kaum mehr als
>>> Port-Forwarding). Es bleibt dann nur noch die Wahl zwischen einer
>>> Bounce-Mail oder dem kommentarlosen Entsorgen der bereits
>>> angenommenen Mail.
>
>> Du benutzt kein Postfix oder?
>
> Nein, aber selbst wenn.
>
> Ausser vielleicht für sehr große Installationen sehe ich wenig
> Nutzen hinter so einem Setup: Wenn der nachgelagerte Mailserver
> gerade aktiv ist, könnte er die Mail auch gleich selber annehmen,
> ist er das aus irgendeinem Grund nicht, klappt der beschriebene
> Mechanismus nicht. Das kann ich z.B. durch Vergabe niedrigerer
> Priorität an den MX auch einfacher erreichen (bzw. mache ich genau
> das).

Mit lediglich mehreren parallelen MXen kannst du aber z.B. kein
DMZ-Konzept abbilden, bei dem Benutzerdaten ausschließlich in der
(inneren) DMZ 2 liegen und der MX in der äußeren DMZ 1 steht. Dies ist
mit recipient callout (Danke, Heiko, für die Erinnerung) oder eben
cuttrough-delivery möglich.

Also mal über den Tellerrand schauen, bitte.


mfG Paul

[Peter J. Holzer]

On 2023-02-27 14:09, Tim Ritberg <t...@server.invalid> wrote:
> Am 27.02.23 um 14:14 schrieb Peter J. Holzer:
>> On 2023-02-26 21:51, Tim Ritberg <t...@server.invalid> wrote:
>>> Am 26.02.23 um 22:34 schrieb Peter J. Holzer:
>>>> Eine Ablehnung, ist meiner meiner Meinung nach die *richtige*
>>>> Entscheidung, wenn der Empfänger nicht existiert.
>>>
>>> Auch andere (temp.) Zustellfehler werden gecacht.
>>
>> Ich sehe, von Dir bekomme ich keine Antwort.
>

> Du hattest also keine Lust den Postfix-Link zu lesen?

Nein, weil mir das nur sagt, was ich eh schon weiß (danke, die Konzepte
kenne ich alle seit langem und wie das ungefähr funktioniert auch), aber
nicht, an welchest Szenario du gerade denkst. Das kannst nur Du
beschreiben. Aber wenn eines Deinem Ego hilft, wenn Du hier "ich sehe
was, was du nicht siehst" spielst, meinetwegen. Ich muss ja nicht
mitspielen.

hp

[Arno Welzel]

Peter J. Holzer, 2023-02-26 16:42:

> On 2023-02-26 11:47, Tim Ritberg <t...@server.invalid> wrote:

[...]

>> Das Relay lehnt ab! Entweder zu früh (Cachetreffer) oder nach
>> Relayversuch (Ziel lehnt ab).
>
> Dann ist die Entscheidung ja nicht falsch. Wenn die Entscheidung falsch
> ist (d.h. das Relay nimmt die Mail an, obwohl es sie ablehnen hätte
> müssen, denn nur dieser Fall ist hier relevant), dann MUSS das Relay
> eine Bounce-Mail verschicken, wenn es bemerkt, dass es die Mail doch
> nicht zustellen kann (oder eines der nachgelagerten Systeme muss das
> tun, wenn es in der gleichen Situation ist).

Und genau dann gibt es das Problem, dass diese Bounce-Mail für Spam oder
DoS missbraucht werden kann.

[Arno Welzel]

Peter J. Holzer, 2023-02-26 22:34:

Und die falsche, wenn diese Information veraltet ist und nur aus einem
Cache kommt.

[Arno Welzel]

Peter J. Holzer, 2023-02-27 14:14:

Wieso? Das *ist* die Antwort.

Postfix cached die Empfängerinformation, wenn er so konfiguriert wurde.
Es kann aber passieren, dass eine ehemals gültige Adresse nicht mehr
existiert oder eine ehemels nicht existierende Adresse mittlerweile
angelegt wurde. Und dann ist die Reaktion einer Ablehnung oder Annahme
der Mail an diese Adresse eben falsch.