[Erledigt] Tele2UTA rDNS Problem

[al]

@wavenetuser:
reject_unknown_client darf man IMHO nicht machen, damit sperrt man viele Mailserver auf dieser Welt aus.

Ich empfehle check_helo_access mit eigener IP-Adresse, eigenem Hostnamen, eigener Domain, und
reject_non_fqdn_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_invalid_hostname
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_unauth_pipelining
(das wichtigste davon ist die unknown_sender_domain und vielleicht das pipelining)

Der HELO-Check kann 25-35% ausmachen, Spamhaus-ZEN ca 20-25%, das meiste machen sonst meine eigenen Blocks aus.

Und zu der Meldung mit dem PTR von TA-IPs... Die einzelne IP-Adresse ist reichlich irrelevant, wenn derjenige über einen Smarthost sendet... dessen (ggf. fehlender) PTR ist relevant... die einliefernde IP-Adresse...

/al

[wavenetuser]

reject_unknown_client macht aber genau die Telekom - obwohl sie nicht mal selbst fähig sind, rDNS beim Businesskunden zu setzen.
Ich wäre eben nur neugierig gewesen ob dies nun allgemein nicht gesetzt ist oder einfach nur ein Fehler von der Telekom ist.

Und zu der Meldung mit dem PTR von TA-IPs...

Nein ist nich wahr. Ich hatte ja vor ein paar Wochen das Problem und die Telekom hat mir bestätigt, es geht um den Absender - und nicht um den Mailserver des Absenders.
Und wenn der Mailserver am Mond steht, kommt die Mail nicht an wenn der Absender selbst kein PTR hat.

Dies haben wir damals sogar ausgetestet.
Gleicher Empfänger (Domain verwalter durch die TA), gleicher Absender nur verschiedene Internet-Leitungen.
Siehe da - einmal kam die Mail an (mit PTR) und einmal nicht (ohne PTR).

//edit: Aber eigentlich steht das ja genau so in der manual:

reject_unknown_client
Reject when the client hostname is unknown. The unknown_client_reject_code parameter specifies the response code to rejected requests (default: 450).

Demzufolge ist der ausliefernde Mailserver irrelevant.

[al]

reject_unknown_client macht aber genau die Telekom

Nein, macht sie nicht:

Received: from unknown (HELO lab.at) ([83.64.140.83])
(envelope-sender <*@*>)
by smarthub78.highway.telekom.at (qmail-ldap-1.03) with SMTP
for <*@*>; 1 Mar 2007 07:56:36 -0000

kam problemlos an.

- obwohl sie nicht mal selbst fähig sind, rDNS beim Businesskunden zu setzen.

Auch dem widerspreche ich, BTDT und es war problemlos und prompt erledigt.

Und client host == einliefernder host, falls Dir das entgangen sein sollte...

/al

[wavenetuser]

Nein, macht sie nicht:

Doch, bei Business-Accounts schon.

Sehr geehrte Kundin, sehr geehrter Kunde!

Vielen Dank, dass Sie sich mit Ihrer Anfrage direkt an uns gewandt
haben.
Die Telekom verwendet im Business Bereich zur Spam Unterbindung den
Reverse Eintrag ,wenn dieser Eintrag fehlt wird die Mail von unserer
Seite abgewiesen.

was bedeutet einliefernder host ?
Gehst Du davon aus, ich hoste 300 Domains über ne dynamische IP bei Inode ?
Der "einliefernder Host" stellt für mich den Absender dar.
Das ist der Mensch hinter der Windows-Kiste. Er schreibt eine Mail, schickt es über den Mailserver als authentifizierter Absender an den Zielserver (SMTPAuth).
Fehlt dem Absender (also der Mensch hinter der Maschine) der rDNS-Eintrag, wird die Email am Empfangsserver abgelehnt.
Egal. Lassen wir das.

[al]

//an die Moderation: kamma da bitte irgendein sinnvolleres Subject machen?

Doch, bei Business-Accounts schon.

Schmarrn:

Received: from [83.64.140.83] (helo=lab.at) by mx1.bon.at with smtp (Exim 4.63) (envelope-from
<*@*>) id 1HMyee-00035G-Es for *@*;
Fri, 02 Mar 2007 04:42:05 +0100

Die Telekom verwendet im Business Bereich zur Spam Unterbindung den
Reverse Eintrag ,wenn dieser Eintrag fehlt wird die Mail von unserer
Seite abgewiesen.

Es mag vielleicht sein, daß sie das zum Bewerten heranziehen (die Testmail hatte 6.0 Punkte), aber ablehnen tun sie's definitiv nicht.

was bedeutet einliefernder host ?

Fang bitte selber an zu denken...

/al

[jutta]

> //an die Moderation: kamma da bitte irgendein sinnvolleres Subject machen?

das subject kann der threadersteller aendern, aber du kannst gern einen vorschlag fuer eines machen.

zur sache: koennte es sein, dass ihr von voellig verschiedenen voraussetzungen ausgeht?

dein

> Received: from [83.64.140.83] (helo=lab.at)

ist ein mail-server, soweit ich das mitbekommen habe. sowas haben die wenigsten leute.

[wavenetuser]

Ich habs ehrlich gesagt aufgegeben, mich mit der Thematik auseinander zu setzen.
Fakt ist, reject_unknown_client hat nichts mit dem Mailserver an sich zu tun.
Dies bezieht sich auf den Client - also denjenigen der die Mail tatsächlich schreibt.
> Received: from [83.64.140.83] (helo=lab.at)
trifft nur zu falls die Mail wirklich von 83.64.140.83 verfasst wurde.
Durch wieviele Mailserver das ganze geht, ist dabei uninteressant.

Schmarrn:

Wenn ich es doch von der Telekom schriftlich habe, kannst Du nicht "Schmarrn" dazu sagen.
Ich hab doch die Mail hier !
In dieser steht deutlich "abgewiesen".

[angelripper]

Der "einliefernder Host" stellt für mich den Absender dar.
Das ist der Mensch hinter der Windows-Kiste. Er schreibt eine Mail, schickt es über den Mailserver als authentifizierter Absender an den Zielserver (SMTPAuth).

Ähm... also für mich sitzt der Mensch der die Mail schreibt immer noch an einem Client und nicht direkt am Host...

Kurze Zwischenfrage:

Kann es sein, dass das Mail der telekom eigentlich nur bedeutet, dass sie darauf achten, ob z.b. ein Mail von einer GMX-Adresse auch vom GMX-Mailserver kommt und nicht von irgendeinem anderen Mailserver indem sie über eben diesen Eintrag prüfen, ob die Ip die es übergibt auch mit dem was sie angibt zu sein übereinstimmt?

Ich bezweifle stark, dass die telekom solche Mails grundsätzlich ablehnt, kann mir aber gut vorstellen, dass diese im Spamfilter oder wie auch immer das Ding heissen mag grundsätzlich eine höhere Spamwertigkeit haben und somit schon bei geringen weiteren Auffälligkeiten weg ist. Auf Support-Mails würde ich mich in solchen technischen Fragen nicht immer 100% verlassen, denn wie man hier sieht, redet man schnell aneinander vorbei, und da wäre ein genaues nachfragen sicher sinnvoller, als eine Antwort auf ein Mail, welches womöglich irgendwie missverständlich war oder falsch verstanden wurde...

[Delta]

Ich habs ehrlich gesagt aufgegeben, mich mit der Thematik auseinander zu setzen.
Fakt ist, reject_unknown_client hat nichts mit dem Mailserver an sich zu tun.
Dies bezieht sich auf den Client - also denjenigen der die Mail tatsächlich schreibt.
> Received: from [83.64.140.83] (helo=lab.at)
trifft nur zu falls die Mail wirklich von 83.64.140.83 verfasst wurde.
Durch wieviele Mailserver das ganze geht, ist dabei uninteressant.

Nein. Der "Client" ist in diesem Fall der Host, der zu deinem Mailserver connected. Das kann jetzt ein lustiger Kerl mit Telnet, ein Kunde direkt mit einem Mailclient oder - wie in den meisten Faellen - ein anderer Mailserver sein.

[wavenetuser]

So schaut das ganze aus:

Mailclient (Outlook oder was auch immer) (kein rDNS)
-> eigener Mailserver (rDNS vorhanden)
-> Telekom Mailserver

Trotz des vorhandenen rDNS des eigenen Mailservers weist der Telekom-Mailserver (mx1.bon.at) die Mail zurück wenn der Client kein rDNS hat.
Das ist was ich die ganze Zeit versuche zu sagen.