[Postfixbuch-users] HELO/EHLO-Namen per DNS/IP überprüfen

[IT-Mailinglists]

Hallo,

gibt es eine Option die es ermöglicht den übermittelten HELO/EHLO-Namen des Servers der die Verbindung zum Postfix aufbaut zu überprüfen?
Ich möchte also, dass wenn sich ein Server mit zum Beispiel mail.gmx.net beim Postfix meldet, dass dann Postfix einen reverse Lookup auf mail.gmx.net durchführt und schaut ob die IP der rDNS-Abfrage mit dem Server übereinstimmt der sich zum Postfix verbunden hat und vorgibt mail.gmx.net zu sein.
Soweit ich das verstehe leisten das die Optionen reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname und reject_unknown_helo_hostname ja nicht. Eine andere Option die sowas bewerkstelligen könnte habe ich auch nicht gefunden. Nun stellt sich mir die Frage, bin ich blind, oder gibt es diesen Check aus gutem Grund nicht - wenn das so ist, würde ich natürlich gern den Grund verstehen wollen. :)

Sinn der ganzen Aktion soll sein das Spammer frühzeitig abgewehrt werden, auch wenn Sie sich als gültiger Mailserver (wie mail.gmx.net) ausgeben.

Ich hoffe das war einigermaßen verständlich formuliert. :)

Hier meine aktuellen Restrictions:

smtpd_recipient_restrictions =
# unsaubere Mails verbieten
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
# nicht ausgehandeltes Pipelining
reject_unauth_pipelining,
# eigene User erlauben
permit_mynetworks,
# Reverse Lookup und Gegenkontrolle mit Forward Lookup durchfuehren
reject_unknown_client_hostname,
# RBLs checken
check_policy_service inet:127.0.0.1:10040,
# Open Relay verhindern
reject_unauth_destination,
# (implizites) Erlauben
permit


Beste Grüße,
Daniel

[Andreas Schulze]

Post by IT-Mailinglists
Sinn der ganzen Aktion soll sein das Spammer frühzeitig abgewehrt werden, auch wenn Sie sich als gültiger Mailserver (wie mail.gmx.net) ausgeben.

anhand des HELO Parameters *willst* Du keine DNS/rDNS Tests machen.
Da gibt's zu viele False positives.

Du kannst testen,
- dass der heloparameter syntaktisch korrekt ist ( reject_invalid_helo_hostname / smtpd_helo_required = yes )
- dass der Heloparameter ein fqdn hat ( reject_non_fqdn_helo_hostname )
das geht aber nur am mx, nicht dort wo Clients einliefern
- das die Gegenstelle bestimmte Helos nicht benutzt
* localhost, 127.0.01, die eigene IP, den eigenen Hostnamen, die eigene Domain
check_helo_access

Strengere Prüfungen erzeugen große Schmerzen ...
--
Andreas Schulze
Internetdienste | P252

DATEV eG
90329 Nürnberg | Telefon [phone] | Telefax [phone]
E-Mail info @datev.de | Internet www.datev.de
Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70
Vorstand
Prof. Dieter Kempf (Vorsitzender)
Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender)
Dipl.-Kfm. Michael Leistenschneider
Jörg Rabe v. Pappenheim
Dipl.-Vw. Eckhard Schwarzer
Vorsitzender des Aufsichtsrates: Reinhard Verholen

[Kai Fürstenberg]

Post by IT-Mailinglists
gibt es eine Option die es ermöglicht den übermittelten
HELO/EHLO-Namen des Servers der die Verbindung zum Postfix aufbaut zu
überprüfen? Ich möchte also, dass wenn sich ein Server mit zum
Beispiel mail.gmx.net beim Postfix meldet, dass dann Postfix einen
reverse Lookup auf mail.gmx.net durchführt und schaut ob die IP der
rDNS-Abfrage mit dem Server übereinstimmt der sich zum Postfix
verbunden hat und vorgibt mail.gmx.net zu sein. Soweit ich das
verstehe leisten das die Optionen reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname und reject_unknown_helo_hostname ja
nicht. Eine andere Option die sowas bewerkstelligen könnte habe ich
auch nicht gefunden. Nun stellt sich mir die Frage, bin ich blind,
oder gibt es diesen Check aus gutem Grund nicht - wenn das so ist,
würde ich natürlich gern den Grund verstehen wollen. :)
Sinn der ganzen Aktion soll sein das Spammer frühzeitig abgewehrt
werden, auch wenn Sie sich als gültiger Mailserver (wie mail.gmx.net)
ausgeben.

Dafür sind HELO-Checks aber denkbar ungeeignet. Eine solche Einstellung
wäre extrem restriktiv und viele reguläre Anbieter würden gar nicht erst
durchkommen.

Beispiel: Die Mailserver bei 1&1 heissen alle mountng.kundenserver.de
(zumindest dem HELO nach). Die hatten auch mal das Problem, dass ein
paar (wahrscheinlich neu aufgesetzte) Server sich
"localhost.localdomain" nannten.

Sinnvolle(re) Tests wären eher, ob sich ein fremder Server nicht als
eigener ausgibt (localhost ist eigentlich auch unsinnig, helo_checks)
oder einen ungültigen HELO-Namen verwendet
(reject_invalid_helo_hostname) oder gar keinen FQDN verwendet
(reject_non_fqdn_hostname).

Du dagegen willst prüfen, ob der HELO auch mit dem Reverse-Namen
übereinstimmt und ablehnen, wenn er das nicht macht. Das halte ich für
zu riskant und sollte vielleicht eher mit policyd-weight gewichtet und
nicht pauschal abgelehnt werden.

[Shirazi, Goodarz]

Hallo zusammen,

wir überlegen auch, ob eine Prüfung der IP Adresse des Absenders eine Option für uns wäre.
Ich habe sogar irgendwo (ct?) gelesen, dass gmx.net, web.de, 1und1 usw. nur Mails von in DNS eingetragenen MTAs annehmen.

Gruß
Goodarz

-----Ursprüngliche Nachricht-----
Von: postfixbuch-users-bounces at listen.jpberlin.de [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Kai Fürstenberg
Gesendet: Donnerstag, 3. Februar 2011 11:15
An: Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein.
Betreff: Re: [Postfixbuch-users] HELO/EHLO-Namen per DNS/IP überprüfen

Post by IT-Mailinglists
gibt es eine Option die es ermöglicht den übermittelten
HELO/EHLO-Namen des Servers der die Verbindung zum Postfix aufbaut zu
überprüfen? Ich möchte also, dass wenn sich ein Server mit zum
Beispiel mail.gmx.net beim Postfix meldet, dass dann Postfix einen
reverse Lookup auf mail.gmx.net durchführt und schaut ob die IP der
rDNS-Abfrage mit dem Server übereinstimmt der sich zum Postfix
verbunden hat und vorgibt mail.gmx.net zu sein. Soweit ich das
verstehe leisten das die Optionen reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname und reject_unknown_helo_hostname ja
nicht. Eine andere Option die sowas bewerkstelligen könnte habe ich
auch nicht gefunden. Nun stellt sich mir die Frage, bin ich blind,
oder gibt es diesen Check aus gutem Grund nicht - wenn das so ist,
würde ich natürlich gern den Grund verstehen wollen. :)
Sinn der ganzen Aktion soll sein das Spammer frühzeitig abgewehrt
werden, auch wenn Sie sich als gültiger Mailserver (wie mail.gmx.net)
ausgeben.

Dafür sind HELO-Checks aber denkbar ungeeignet. Eine solche Einstellung wäre extrem restriktiv und viele reguläre Anbieter würden gar nicht erst durchkommen.

Beispiel: Die Mailserver bei 1&1 heissen alle mountng.kundenserver.de (zumindest dem HELO nach). Die hatten auch mal das Problem, dass ein paar (wahrscheinlich neu aufgesetzte) Server sich "localhost.localdomain" nannten.

Sinnvolle(re) Tests wären eher, ob sich ein fremder Server nicht als eigener ausgibt (localhost ist eigentlich auch unsinnig, helo_checks) oder einen ungültigen HELO-Namen verwendet
(reject_invalid_helo_hostname) oder gar keinen FQDN verwendet (reject_non_fqdn_hostname).

Du dagegen willst prüfen, ob der HELO auch mit dem Reverse-Namen übereinstimmt und ablehnen, wenn er das nicht macht. Das halte ich für zu riskant und sollte vielleicht eher mit policyd-weight gewichtet und nicht pauschal abgelehnt werden.

--
Kai Fürstenberg

PM an: kai at fuerstenberg punkt ws

--

[Kai Fürstenberg]

Post by Shirazi, Goodarz
wir überlegen auch, ob eine Prüfung der IP Adresse des Absenders eine
Option für uns wäre. Ich habe sogar irgendwo (ct?) gelesen, dass
gmx.net, web.de, 1und1 usw. nur Mails von in DNS eingetragenen MTAs
annehmen.

im DNS sind nur eingehende Mail-Server eingetragen. Es bietet sich in
jedem Fall an, genau diese Server auch für ausgehende Mails zu
verwenden, aber viele machen das eben nicht. Die haben eingehenden und
ausgehenden Verkehr streng getrennt, und bestimmt auch aus gutem Grund.
Die würden damit alle ausgesperrt.

[Driessen]

On Behalf Of Kai Fürstenberg

Post by Kai Fürstenberg

Post by Shirazi, Goodarz
wir überlegen auch, ob eine Prüfung der IP Adresse des Absenders eine
Option für uns wäre. Ich habe sogar irgendwo (ct?) gelesen, dass
gmx.net, web.de, 1und1 usw. nur Mails von in DNS eingetragenen MTAs
annehmen.

im DNS sind nur eingehende Mail-Server eingetragen. Es bietet sich in
jedem Fall an, genau diese Server auch für ausgehende Mails zu
verwenden, aber viele machen das eben nicht. Die haben eingehenden und
ausgehenden Verkehr streng getrennt, und bestimmt auch aus gutem Grund.
Die würden damit alle ausgesperrt.

Nö. Veto.

Gerade die versendenden Mailserver stehen im DNS denn genau diese wollen ja
Ihre Mails loswerden.

Wer einen Ausgangsmailserver OHNE korrekten DNS (PTR, A, Helo als A-record)
betreibt dem kann man eh nicht mehr helfen.

Du meinst den MX record. Dieser sagt nur aus das Mails für Domain XYZ bitte
über Server halligalli eingeliefert werden soll.
Der MX hat mit dem Versand erstmal nichts zu.(kann allerdings auf der selben
IP rennen)

Post by Kai Fürstenberg
--
Kai Fürstenberg
PM an: kai at fuerstenberg punkt ws

Mit freundlichen Grüßen

Drießen

[Kai Fürstenberg]

Post by Driessen
On Behalf Of Kai Fürstenberg

Post by Kai Fürstenberg

Post by Shirazi, Goodarz
wir überlegen auch, ob eine Prüfung der IP Adresse des Absenders eine
Option für uns wäre. Ich habe sogar irgendwo (ct?) gelesen, dass
gmx.net, web.de, 1und1 usw. nur Mails von in DNS eingetragenen MTAs
annehmen.

im DNS sind nur eingehende Mail-Server eingetragen. Es bietet sich in
jedem Fall an, genau diese Server auch für ausgehende Mails zu
verwenden, aber viele machen das eben nicht. Die haben eingehenden und
ausgehenden Verkehr streng getrennt, und bestimmt auch aus gutem Grund.
Die würden damit alle ausgesperrt.

Nö. Veto.
Gerade die versendenden Mailserver stehen im DNS denn genau diese wollen ja
Ihre Mails loswerden.
Wer einen Ausgangsmailserver OHNE korrekten DNS (PTR, A, Helo als A-record)
betreibt dem kann man eh nicht mehr helfen.
Du meinst den MX record. Dieser sagt nur aus das Mails für Domain XYZ bitte
über Server halligalli eingeliefert werden soll.
Der MX hat mit dem Versand erstmal nichts zu.(kann allerdings auf der selben
IP rennen)

Genau das meinte ich. :-)

Wenn ich was von "in DNS eingetragenen MTAs" lese denke ich halt an MX.
Denn bei den anderen im DNS eingetragenen Servern ist nicht gesagt, dass
dort auch ein MTA läuft, geschweige denn dass der für irgendwelche Mails
zuständig ist.

[Jan Behrend]

Post by IT-Mailinglists
Hallo,
gibt es eine Option die es ermöglicht den übermittelten HELO/EHLO-Namen des Servers der die Verbindung zum Postfix aufbaut zu überprüfen?
Ich möchte also, dass wenn sich ein Server mit zum Beispiel mail.gmx.net beim Postfix meldet, dass dann Postfix einen reverse Lookup auf mail.gmx.net durchführt und schaut ob die IP der rDNS-Abfrage mit dem Server übereinstimmt der sich zum Postfix verbunden hat und vorgibt mail.gmx.net zu sein.
Soweit ich das verstehe leisten das die Optionen reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname und reject_unknown_helo_hostname ja nicht. Eine andere Option die sowas bewerkstelligen könnte habe ich auch nicht gefunden. Nun stellt sich mir die Frage, bin ich blind, oder gibt es diesen Check aus gutem Grund nicht - wenn das so ist, würde ich natürlich gern den Grund verstehen wollen. :)
Sinn der ganzen Aktion soll sein das Spammer frühzeitig abgewehrt werden, auch wenn Sie sich als gültiger Mailserver (wie mail.gmx.net) ausgeben.

Hallo Daniel,

vielliecht ist ja der Policy-Weight-Daemon ja etwas für Dich ...

Description: a Perl policy daemon for the Postfix MTA
Its intended to eliminate forged envelope senders and HELOs (i.e. in
bogus mails). It allows you to score DNSBLs (RBL/RHSBL), HELO,
MAIL FROM and client IP addresses before any queuing is done. It allows
you to REJECT messages which have a score higher than allowed,
providing improved blocking of spam and virus mails. policyd-weight
caches the most frequent client/sender combinations (SPAM as well
as HAM) to reduce the number of DNS queries.
Homepage: http://www.policyd-weight.org/

Gruß von Jan
--
MAX-PLANCK-INSTITUT fuer Radioastronomie
Jan Behrend - Rechenzentrum
----------------------------------------
Auf dem Huegel 69, D-53121 Bonn
Tel: [phone], Fax: [phone]
jbehrend at mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : smime.p7s
Dateityp : application/pkcs7-signature
Dateigröße : 5855 bytes
Beschreibung: S/MIME Cryptographic Signature
URL : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20110203/00458c2f/attachment.p7s>

[Driessen]

On Behalf Of IT-Mailinglists

Post by IT-Mailinglists
smtpd_recipient_restrictions =
# unsaubere Mails verbieten
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
# nicht ausgehandeltes Pipelining
reject_unauth_pipelining,
# eigene User erlauben
permit_mynetworks,
# Reverse Lookup und Gegenkontrolle mit Forward Lookup
durchfuehren
reject_unknown_client_hostname,

schau dir auch mal

reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_client_hostname,
reject_unknown_helo_hostname,

da müsste das richtige dabei sein

Post by IT-Mailinglists
Beste Grüße,
Daniel
--

Mit freundlichen Grüßen

Drießen