Re: Bind9
Markus Kolb <debian@tower-net.de> schrieb:
> Es gibt aber nun mal SMTP-Server die per DNS-Lookup checken, ob der
> andere Server der ist, der er vorgibt zu sein.
Checken darf das jeder. Nur ablehnen darf man Mail nicht, falls sich ein
Name nicht auflösen lässt. Daß sich auch solche nicht auflösbare Systeme
am Mailverkehr beteiligen, wird in den maßgeblichen RFCs explizit mit
eingeschlossen.
RFC 2821 ist in dem Punkt nebenbei absolut eindeutig:
"[...]An SMTP server MAY verify that the domain name parameter in the
EHLO command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.[...]"
D.h. ein Server, der das macht, was Du behauptest, ist einfach ein
defekter Netzschädling und gehört schnellstmöglich abgeklemmt. Mir
ist übrigens noch kein System begegnet, daß tatsächlich derart
fehlkonfiguriert war. Bist Du sicher, daß Du da nicht die Gründe
einer Mailablehnung vielleicht mißgedeutet hast?
DULs sind was anderes, weil sie nicht aufgrund der korrekten Auflösbarkeit
sondern einfach anhand der IP entscheiden. Daß DULs auch schädlich und eine
ganz schlechte Idee® sind, steht dann wiederum auf einem anderen Blatt.
> Also smarthost verwenden und alle sind glücklich.
Wenn die Serverseite nicht vorsätzlich gegen geltende technische Normen
verstößt oder einer unsinnigen Antispampolicy per DUL folgt, ist das
völlig überflüssig.
> Ausserdem kannst mir mal den Part in einem zugehörigen RFC zeigen, der
> sagt, dass eine ID mit nicht registrierter Domain keine konforme ID
> ist...
Warum soll ich Dir was zeigen, was ich nie behauptet habe und was auch
gar nicht für Mail verlangt ist? Liest Du eigentlich, was ich schreibe?
In RFC 2822 ist die Verwendung eines Domainparts in Message-IDs eine
recommendation. Wie das zu verstehen ist, erfährst Du in RFC 2119.
> Es ist nur die Rede von einer einzigartigen ID. Wenn man eine
> registrierte Domain verwendet, ist das aber auch kein technisches
> Gewähr für Einzigartigkeit.
Nein. Aber so ziemlich die sicherste Methode, dem nahezukommen.
> [...]
>
>> Um Deiner Forderung nachkommen zu können, müsste man wieder die
>> Message-IDs vor Einlieferung beim Provider löschen. Solche dämlichen
>> Ideen haben tatsächlich schon einige Leute in der Praxis angewand -
>> und nicht selten nette Dupeschwemmen damit produziert. Neue
>> Message-Ids zu generieren und bereits vorhandene zu verwerfen, ist
>> schlicht unverantwortlich.
>
> Was machen dann die Newsserver wie news.cis.dfn.de?
> Die generieren die oder wie sonst komme ich z.B. an Message-ID:
> <akql70$1klis4$1@ID-12889.news.dfncis.de> ?
Die generieren die genau dann, wenn Dein Posting noch keine Message-ID
hat, wenn sie am Server ankommt. Ist eine vorhanden, wird die
selbstverständlich nicht angetastet.
Falls Deine dabei bereits vorhandene ID nicht dem empfohlenen Schema
nach obigen Muster entspricht, bekommst Du nur als Warnhinweis eine
Message-ID nach obigen Muster als "recommended" empfohlen.
Warum Deine Postings noch keine Message-IDs haben, wenn sie beim
Newsserver ankommen, solltest Du anhand Deiner lokalen Konfiguration
nachvollziehen können. Solltest Du sie tatsächlich auf dem Weg von
einem lokalen zum öffentlichen Newsserver löschen, dann solltest Du
das schnellstens korrigieren, weil das ein grober Fehler ist.
Ein kleiner Fehler in der Newsserverkonfiguration und die Katastrophe
könnte dann schon perfekt sein.
Gruß,
Marcus
--
Actually, Microsoft is sort of a mixture between the Borg and the Ferengi.
eMail: m@followup-to.de
Reply to:
- Follow-Ups:
- Re: Bind9
- From: Peter Palmreuther <lists@pitpalme.de>