Reverse Lookup für authentifizierte Nutzer umgehen

1. offizieller Beitrag

    Hallo,


    ich möchte das Feature
    "Reject message if the originating IP has no reverse DNS entry"
    nutzen. Damit sperre ich aber auch meine eigenen (Einwahl)kunden
    aus, weil die Regel immer fehlschlägt:



    05-30 14:19:30 +0200 16 mx SMTP-IN:00000C05: << EHLO pitdsllto3l52u
    05-30 14:19:30 +0200 08 mx DNR:00000C05: Search PTR for '194.77.208.182'
    05-30 14:19:30 +0200 08 mx DNR:00000C05: Sending query (1/1) to 80.243.45.80:53
    05-30 14:19:30 +0200 08 mx DNR:00000C05: '194.77.208.182' found PTR 'n8-182.dsl.vianetworks.de'
    05-30 14:19:30 +0200 08 mx SMTP-IN:00000C05: Reverse DNS check failed for <pitdsllto3l52u> connected from <194.77.208.182>
    05-30 14:19:30 +0200 08 mx SMTP-IN:00000C05: Set smtp action to REJECT


    Dasselbe passiert auch bei Webmail, weil der DNR dann versucht,
    127.0.0.1 reverse aufzulösen.
    Während ich das letzte Problem noch mittels
    AXIGEN Mail Server - How to exclude a certain IP/IP range from reverse DNS checks
    beheben könnte, ist das bei ersterem so nicht möglich.


    Kann mir hier jemand weiterhelfen?
    - Ich nutze Version 6.0.1


    Andreas

    Das Problem dabei ist, daß ich keine IP-Bereiche angeben kann. Es geht hier um Nutzer, die sich über ihren Access-Provider einwählen und irgendeine IP-Adresse zugewiesen bekommen. Sie dürften normalerweise senden, wenn sie sich authentifiziert haben. Da aber das Reverse Lookup bereits vorher erfolgt, werden sie abgewiesen.
    Ich habe die Protokolle so gelesen, daß der Server nicht nur fragt, ob überhaupt ein Reverse-Eintrag für die IP-Adresse vorhanden ist (was auch für Einwahlaccounts immer gefordert werden kann), sondern ob dieser auch mit dem per HELO avisierten Hostnamen übereinstimmt (was natürlich in diesem Fall nicht möglich ist).

    • Offizieller Beitrag

    Zuerst werden die Reverse-DNS / DNSBLs gecheckt und dann erst die Authentifizierung - aus verschiedensten Gründen.

    Die Ranges lassen sich doch je nach Provider ausnehmen, wie z.B. Arcor - die werden auf Anfrage rausgegeben. Bedingt durch die DSL-Technologie erhalten Kunden pro Standort nur einen kleineren möglichen Bereich, sodass man die einfach auch selbst ermitteln kann.

    Der Mailserver ist für ISP-Betrieb vorgesehen und wurde auch als ISP-Version gekauft. Dem Kunden ist völlig freigestellt, über welchen Access-Provider er sich am Server anmeldet. Er muß das auch niemandem mitteilen. Natürlich könnte man alle dynamisch vergebenen IP-Adressen aller hier aktiven Provider freigeben, dann aber ist das Feature im Prinzip ausgehebelt. Zusammenfassend wäre also festzustellen, daß der Filter im ISP-Betrieb nicht anwendbar ist. Ist das richtig?

    • Offizieller Beitrag

    Gerade für den ISP-Betrieb ist dieses Feature in der Implementation so richtig... Denn zuerst muss der Reverse-Eintrag festgestellt werden, dann die Authentifizierung.
    Sonst würde z.B. ein Cluster nicht sicher funktionieren oder ein Sync zwischen zwei Mailservern. Das Logikkonzept ist in allen Modulen von AXIGEN so hinterlegt.


    Sie können das als Feature-Request dennoch gerne an den Hersteller melden: support@axigen.com - vielleicht als Option die Reihenfolge (erst Authentifizierung, dann Reverse) festzulegen - da sind wir außen vor bezüglich Implementierung.


    Ich würde den Reverse-Eintrag nicht in einem Produktivsystem als Spamschutz verwenden, sondern eher als Sicherheitsfeature bei Serverclustern - da selbst bei großen Firmen es passiert, dass der Reverse nicht klappt - weil z.B. der Mailserver umgezogen ist und noch nicht alle DNS-Server das Update haben und dann kommt keine Mail an. Es gibt bessere Möglichkeiten Spam abzuwehren, als den Reverse Lookup zu prüfen.