Hallo,
so langsam wird das hier zum (unfreiwilligen) Hobby mit den Phishing-Mails.
Ich frage mich gerade, warum das hier nicht abgewiesen wurde:
Received: from mail.sicherheit.de (unknown [83.169.1.6])
Die IP hat zwar einen Reverse pointer zu mail.sicherheit.de:
$ host 83.169.1.6 6.1.169.83.in-addr.arpa domain name pointer mail.sicherheit.de.
Aber mail.sicherheit.de hat eine ganz andere IP:
$ host mail.sicherheit.de mail.sicherheit.de has address 72.52.10.14
Sowas müsste sich doch blocken lassen. Ist das nicht Bestandteil von reject_invalid_helo_hostname?
Jochen
On 01.07.2017 09:14, Joachim Fahrner wrote:
Hallo,
so langsam wird das hier zum (unfreiwilligen) Hobby mit den Phishing-Mails.
Ich frage mich gerade, warum das hier nicht abgewiesen wurde:
Received: from mail.sicherheit.de (unknown [83.169.1.6])
Die IP hat zwar einen Reverse pointer zu mail.sicherheit.de:
$ host 83.169.1.6 6.1.169.83.in-addr.arpa domain name pointer mail.sicherheit.de.
Aber mail.sicherheit.de hat eine ganz andere IP:
$ host mail.sicherheit.de mail.sicherheit.de has address 72.52.10.14
der Klassiker, wobei die Ursache nicht mal zwingend bösartig war; dies geschieht z.B. schon dadurch, wenn jemand mit seiner Domain zu einem anderen Hoster umzieht und beim alten Hoster die reverse DNS Einträge nicht zurückgesetzt/geändert werden ... (wobei das dann irgendwie der Beweis f. IPv4s im Überfluss wäre)
Sowas müsste sich doch blocken lassen. Ist das nicht Bestandteil von reject_invalid_helo_hostname?
damit blockierst nur die Mails, welche beim HELO eine Domain angeben, die es im DNS entweder nicht gibt oder sonst was ... wenn da jemand weil er lustig ist eben mail.sicherheit.de angibt, geht das durch, wie Du ja selbst erkannt hast, gibt es die;
interessanter wäre ein Mechanismus, der exakt die Mails durchläßt, wo die IP einen reverse DNS ergibt, welcher tatsächlich ein forward DNS wieder diese IP ergibt ... (damit hast den ganzen Quark, wo jemand irgendwas vorgaukelt, weg)
Am 01.07.2017 um 09:55 schrieb Walter H.:
On 01.07.2017 09:14, Joachim Fahrner wrote:
Hallo,
so langsam wird das hier zum (unfreiwilligen) Hobby mit den Phishing-Mails.
Ich frage mich gerade, warum das hier nicht abgewiesen wurde:
Received: from mail.sicherheit.de (unknown [83.169.1.6])
Die IP hat zwar einen Reverse pointer zu mail.sicherheit.de:
$ host 83.169.1.6 6.1.169.83.in-addr.arpa domain name pointer mail.sicherheit.de.
Aber mail.sicherheit.de hat eine ganz andere IP:
$ host mail.sicherheit.de mail.sicherheit.de has address 72.52.10.14
der Klassiker, wobei die Ursache nicht mal zwingend bösartig war; dies geschieht z.B. schon dadurch, wenn jemand mit seiner Domain zu einem anderen Hoster umzieht und beim alten Hoster die reverse DNS Einträge nicht zurückgesetzt/geändert werden ... (wobei das dann irgendwie der Beweis f. IPv4s im Überfluss wäre)
Sowas müsste sich doch blocken lassen. Ist das nicht Bestandteil von reject_invalid_helo_hostname?
damit blockierst nur die Mails, welche beim HELO eine Domain angeben, die es im DNS entweder nicht gibt oder sonst was ... wenn da jemand weil er lustig ist eben mail.sicherheit.de angibt, geht das durch, wie Du ja selbst erkannt hast, gibt es die;
interessanter wäre ein Mechanismus, der exakt die Mails durchläßt, wo die IP einen reverse DNS ergibt, welcher tatsächlich ein forward DNS wieder diese IP ergibt ... (damit hast den ganzen Quark, wo jemand irgendwas vorgaukelt, weg)
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostnam...
Reject the request when the client IP address has no address->name mapping. This is a weaker restriction than the reject_unknown_client_hostname feature, which requires not only that the address->name and name->address mappings exist, but also that the two mappings reproduce the client IP address. The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address->name lookup failed due to a temporary problem. This feature is available in Postfix 2.3 and later.
das gibt real aber zuviel Aerger, wenn man den anwenden will sollte man vorfiltern, also nicht per se auf alles anwenden !
Best Regards MfG Robert Schetterer
Am 01.07.2017 um 12:45 schrieb Robert Schetterer:
Am 01.07.2017 um 09:55 schrieb Walter H.:
On 01.07.2017 09:14, Joachim Fahrner wrote:
Hallo,
so langsam wird das hier zum (unfreiwilligen) Hobby mit den Phishing-Mails.
Ich frage mich gerade, warum das hier nicht abgewiesen wurde:
Received: from mail.sicherheit.de (unknown [83.169.1.6])
Die IP hat zwar einen Reverse pointer zu mail.sicherheit.de:
$ host 83.169.1.6 6.1.169.83.in-addr.arpa domain name pointer mail.sicherheit.de.
Aber mail.sicherheit.de hat eine ganz andere IP:
$ host mail.sicherheit.de mail.sicherheit.de has address 72.52.10.14
der Klassiker, wobei die Ursache nicht mal zwingend bösartig war; dies geschieht z.B. schon dadurch, wenn jemand mit seiner Domain zu einem anderen Hoster umzieht und beim alten Hoster die reverse DNS Einträge nicht zurückgesetzt/geändert werden ... (wobei das dann irgendwie der Beweis f. IPv4s im Überfluss wäre)
Sowas müsste sich doch blocken lassen. Ist das nicht Bestandteil von reject_invalid_helo_hostname?
damit blockierst nur die Mails, welche beim HELO eine Domain angeben, die es im DNS entweder nicht gibt oder sonst was ... wenn da jemand weil er lustig ist eben mail.sicherheit.de angibt, geht das durch, wie Du ja selbst erkannt hast, gibt es die;
interessanter wäre ein Mechanismus, der exakt die Mails durchläßt, wo die IP einen reverse DNS ergibt, welcher tatsächlich ein forward DNS wieder diese IP ergibt ... (damit hast den ganzen Quark, wo jemand irgendwas vorgaukelt, weg)
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostnam...
Reject the request when the client IP address has no address->name mapping. This is a weaker restriction than the reject_unknown_client_hostname feature, which requires not only that the address->name and name->address mappings exist, but also that the two mappings reproduce the client IP address. The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address->name lookup failed due to a temporary problem. This feature is available in Postfix 2.3 and later.
sorry der isses
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client) Reject the request when 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address. This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above. The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address->name or name->address lookup failed due to a temporary problem.
schon ewig nimmer nachgesehen
das gibt real aber zuviel Aerger, wenn man den anwenden will sollte man vorfiltern, also nicht per se auf alles anwenden !
Best Regards MfG Robert Schetterer
Best Regards MfG Robert Schetterer
Am 2017-07-01 12:48, schrieb Robert Schetterer:
sorry der isses
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
Dachte ich mir doch, dass es da was geben muss. Ich hatte unter den helo restrictions geguckt. http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions
Jochen
On 01.07.2017 12:48, Robert Schetterer wrote:
Am 01.07.2017 um 12:45 schrieb Robert Schetterer:
Am 01.07.2017 um 09:55 schrieb Walter H.:
On 01.07.2017 09:14, Joachim Fahrner wrote:
Hallo,
so langsam wird das hier zum (unfreiwilligen) Hobby mit den Phishing-Mails.
Ich frage mich gerade, warum das hier nicht abgewiesen wurde:
Received: from mail.sicherheit.de (unknown [83.169.1.6])
Die IP hat zwar einen Reverse pointer zu mail.sicherheit.de:
$ host 83.169.1.6 6.1.169.83.in-addr.arpa domain name pointer mail.sicherheit.de.
Aber mail.sicherheit.de hat eine ganz andere IP:
$ host mail.sicherheit.de mail.sicherheit.de has address 72.52.10.14
der Klassiker, wobei die Ursache nicht mal zwingend bösartig war; dies geschieht z.B. schon dadurch, wenn jemand mit seiner Domain zu einem anderen Hoster umzieht und beim alten Hoster die reverse DNS Einträge nicht zurückgesetzt/geändert werden ... (wobei das dann irgendwie der Beweis f. IPv4s im Überfluss wäre)
Sowas müsste sich doch blocken lassen. Ist das nicht Bestandteil von reject_invalid_helo_hostname?
damit blockierst nur die Mails, welche beim HELO eine Domain angeben, die es im DNS entweder nicht gibt oder sonst was ... wenn da jemand weil er lustig ist eben mail.sicherheit.de angibt, geht das durch, wie Du ja selbst erkannt hast, gibt es die;
interessanter wäre ein Mechanismus, der exakt die Mails durchläßt, wo die IP einen reverse DNS ergibt, welcher tatsächlich ein forward DNS wieder diese IP ergibt ... (damit hast den ganzen Quark, wo jemand irgendwas vorgaukelt, weg)
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostnam...
Reject the request when the client IP address has no address->name mapping. This is a weaker restriction than the reject_unknown_client_hostname feature, which requires not only that the address->name and name->address mappings exist, but also that the two mappings reproduce the client IP address. The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address->name lookup failed due to a temporary problem. This feature is available in Postfix 2.3 and later.
sorry der isses
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
reject_unknown_client_hostname (with Postfix< 2.3: reject_unknown_client) Reject the request when 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address. This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above. The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address->name or name->address lookup failed due to a temporary problem.
schon ewig nimmer nachgesehen
das gibt real aber zuviel Aerger, wenn man den anwenden will sollte man vorfiltern, also nicht per se auf alles anwenden !
ich hab bei meinem der im Internet als mein SMTP (mit TLS Port 587) und als MX (Port 25) f. die selbe Domain fungiert folgendes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_hostname, reject_non_fqdn_helo_hostname
smtpd_client_restrictions = permit_mynetworks, reject_unknown_client_hostname smtpd_etrn_restrictions = permit_mynetworks, reject
smtpd_sender_restrictions = check_sender_mx_access cidr:/etc/postfix/drop.cidr, check_sender_ns_access cidr:/etc/postfix/drop.cidr, reject_non_fqdn_sender, reject_unknown_sender_domain
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unauth_destination, reject_unknown_recipient_domain, check_recipient_access hash:/etc/postfix/recipient_access, reject
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unknown_recipient_domain
in /etc/postfix/main.cf
mit
wget -q -nd --output-document=- http://www.spamhaus.org/drop/drop.lasso |awk '/; SBL/ { printf( "%s\tREJECT %s\n", $1, $3 ) }'
/etc/postfix/drop.cidr
aktualiser ich von Zeit zu Zeit /etc/postfix/drop.cidr
wobei vieles kommt gleich gar nicht zum Tragen, weil ich im Falle, daß da wirres Zeug per SSH od. HTTP(S) daherkommt (per logwatch mitgeteilt), ich den gesamten Range der zu einzelnen IPs gehört z.B. so -I INPUT -i eth0 -s 1.171.0.0/16 -j DROP in der IPtables Firewall blockier
Am 2017-07-01 12:45, schrieb Robert Schetterer:
das gibt real aber zuviel Aerger, wenn man den anwenden will sollte man vorfiltern, also nicht per se auf alles anwenden !
Wo kann das denn Ärger geben?
Problem heutzutage ist (aus meiner Sicht), dass die Phishing Mails immer perfekter werden. Da wird echt viel Energie reingesteckt, anders als bei Spam. Bei Spam möchte man möglichst viele Leute möglichst billig erreichen. Bei Phishing reicht es wenige zu erreichen, die dafür aber möglichst "zuverlässig". Man will da möglichst perfekt "Seriosität" vortäuschen. Es ist erstaunlich, wie da extra für den Zweck "unbefleckte" Server angemietet werden, und das DNS eines renomierten Dienstes möglichst täuschend echt simuliert wird. An den Headern erkennt man kaum noch dass der Absender nicht vertrauenswürdig ist, nur an den Links die man dann klicken soll sieht man, dass die auf irgendeine dubiose Seite leiten.
Da stecken professionell arbeitende Banden dahinter, mit ziemlich viel Knowhow. Aber die krieg ich schon auch noch in den Griff. Man hat ja sonst keine Hobbies. ;-)
Jochen
Am 01.07.2017 um 13:29 schrieb Joachim Fahrner:
Am 2017-07-01 12:45, schrieb Robert Schetterer:
das gibt real aber zuviel Aerger, wenn man den anwenden will sollte man vorfiltern, also nicht per se auf alles anwenden !
Wo kann das denn Ärger geben?
Problem heutzutage ist (aus meiner Sicht), dass die Phishing Mails immer perfekter werden. Da wird echt viel Energie reingesteckt, anders als bei Spam. Bei Spam möchte man möglichst viele Leute möglichst billig erreichen. Bei Phishing reicht es wenige zu erreichen, die dafür aber möglichst "zuverlässig". Man will da möglichst perfekt "Seriosität" vortäuschen. Es ist erstaunlich, wie da extra für den Zweck "unbefleckte" Server angemietet werden, und das DNS eines renomierten Dienstes möglichst täuschend echt simuliert wird. An den Headern erkennt man kaum noch dass der Absender nicht vertrauenswürdig ist, nur an den Links die man dann klicken soll sieht man, dass die auf irgendeine dubiose Seite leiten.
Da stecken professionell arbeitende Banden dahinter, mit ziemlich viel Knowhow. Aber die krieg ich schon auch noch in den Griff. Man hat ja sonst keine Hobbies. ;-)
Jochen
Hallo Jochen, man sollte von sich nicht auf andere schliessen du kannst auf deinem Server machen was du willst, wenn du aber als Dienstleister taetig bist musst du deine Massnahmen schon sorgfaeltig abwaegen....
reject_unknown_reverse_client_hostname geht ok in den meisten setups
reject_unknown_client_hostname macht ein Haufen zusaetzliche Support Arbeit und 99 % aller Kunden interesiert eine technische Erklaerung nicht die Bohne, also wenn man das verwenden will ist es klug vorher zu filtern zb mit
smtpd_restriction_classes
oder einem policy server , milter etc
Best Regards MfG Robert Schetterer
Am 2017-07-01 15:55, schrieb Robert Schetterer:
also wenn man das verwenden will ist es klug vorher zu filtern zb mit
smtpd_restriction_classes
oder einem policy server , milter etc
Ok. Aber ich steh da wohl grad auf der Leitung. Nach welchen Kriterien sollte man da filtern? Wen prüft man damit, und wen lässt man an der Prüfung vorbei?
Jochen
On 01.07.2017 16:47, Joachim Fahrner wrote:
Am 2017-07-01 15:55, schrieb Robert Schetterer:
also wenn man das verwenden will ist es klug vorher zu filtern zb mit
smtpd_restriction_classes
oder einem policy server , milter etc
Ok. Aber ich steh da wohl grad auf der Leitung. Nach welchen Kriterien sollte man da filtern? Wen prüft man damit, und wen lässt man an der Prüfung vorbei?
Jochen
ich denke er meint, daß es durchaus möglich ist, daß es Mails gibt, welche berechtigterweise kommen, aber durch dieses harte blocken aber fehlschlagen, wobei ich mir die Frage stelle, ob ein Mailserver überhaupt eine Existenzberechtigung hat, wenn er sich mit HELO xxxx meldet und dieses xxxx nicht dessen DNS Name ist und die IP Adresse welche connected im Reverse DNS ebensowenig xxxx entspricht ...
Am 2017-07-01 17:00, schrieb Walter H.:
ich denke er meint, daß es durchaus möglich ist, daß es Mails gibt, welche berechtigterweise kommen, aber durch dieses harte blocken aber fehlschlagen, wobei ich mir die Frage stelle, ob ein Mailserver überhaupt eine Existenzberechtigung hat, wenn er sich mit HELO xxxx meldet und dieses xxxx nicht dessen DNS Name ist und die IP Adresse welche connected im Reverse DNS ebensowenig xxxx entspricht ...
Das sehe ich eigentlich auch so. Jeder professionelle Dienst sollte eigentlich ein korrekt konfiguriertes DNS haben. Und wenn Mails irgendwelcher Hobby-Admins geblockt werden, dann kann das nicht so schlimm sein. Wenn einem so eine Mail wichtig ist, kann man immer noch einzelne Server auf eine Whitelist setzen.
Jochen
On 01.07.17 - 17:29, Joachim Fahrner wrote:
Am 2017-07-01 17:00, schrieb Walter H.:
wobei ich mir die Frage stelle, ob ein Mailserver überhaupt eine Existenzberechtigung hat, wenn er sich mit HELO xxxx meldet und dieses xxxx nicht dessen DNS Name ist und die IP Adresse welche connected im Reverse DNS ebensowenig xxxx entspricht ...
Das sehe ich eigentlich auch so. Jeder professionelle Dienst sollte eigentlich ein korrekt konfiguriertes DNS haben. Und wenn Mails irgendwelcher Hobby-Admins geblockt werden, dann kann das nicht so schlimm sein. Wenn einem so eine Mail wichtig ist, kann man immer noch einzelne Server auf eine Whitelist setzen.
Jochen
Es gibt da leider auch unter den "großen" teils fragwürdige Vorgehensweisen beim Betrieb von Mailservern.
So ist bei mir beispielsweise Facebook seit geraumer Zeit auf einer Whitelist, da sie ernsthaft von Hosts mit RDNS_DYNAMIC und anderen lustigen Problemen Mails bei mir zustellen...
Grüße Thore
--
Im Auftrag von Thore Boedecker
On 01.07.17 - 17:29, Joachim Fahrner wrote:
Am 2017-07-01 17:00, schrieb Walter H.:
wobei ich mir die Frage stelle, ob ein Mailserver überhaupt eine Existenzberechtigung hat, wenn er sich mit HELO xxxx meldet und dieses xxxx nicht dessen DNS Name ist und die IP Adresse welche connected im Reverse DNS ebensowenig xxxx entspricht ...
Das sehe ich eigentlich auch so. Jeder professionelle Dienst sollte eigentlich ein korrekt konfiguriertes DNS haben. Und wenn Mails irgendwelcher Hobby-Admins geblockt werden, dann kann das nicht so
schlimm
sein. Wenn einem so eine Mail wichtig ist, kann man immer noch einzelne Server auf eine Whitelist setzen.
Jochen
Es gibt da leider auch unter den "großen" teils fragwürdige Vorgehensweisen beim Betrieb von Mailservern.
So ist bei mir beispielsweise Facebook seit geraumer Zeit auf einer Whitelist, da sie ernsthaft von Hosts mit RDNS_DYNAMIC und anderen lustigen Problemen Mails bei mir zustellen...
Bist du dem mal nachgegangen mit den Facebookmails ? waren das wirklich echte von Facebook ? Ich hab das bei mir noch nicht im logfile gesehen
Wenn es wirklich von Facebook kommt ... Und warum sollte Facebook etwas ändern ? Solange ich nicht erwischt werde ignoriere ich gerne mal eine Rote Ampel :-)
Wenn etwas OHNE Konsequenzen bleibt obwohl es nicht sauber ist ..
Grüße Thore
Mit freundlichen Grüßen
Uwe Drießen -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
--
Am 01.07.2017 um 17:29 schrieb Joachim Fahrner:
Am 2017-07-01 17:00, schrieb Walter H.:
ich denke er meint, daß es durchaus möglich ist, daß es Mails gibt, welche berechtigterweise kommen, aber durch dieses harte blocken aber fehlschlagen, wobei ich mir die Frage stelle, ob ein Mailserver überhaupt eine Existenzberechtigung hat, wenn er sich mit HELO xxxx meldet und dieses xxxx nicht dessen DNS Name ist und die IP Adresse welche connected im Reverse DNS ebensowenig xxxx entspricht ...
Das sehe ich eigentlich auch so. Jeder professionelle Dienst sollte eigentlich ein korrekt konfiguriertes DNS haben. Und wenn Mails irgendwelcher Hobby-Admins geblockt werden, dann kann das nicht so schlimm sein. Wenn einem so eine Mail wichtig ist, kann man immer noch einzelne Server auf eine Whitelist setzen.
Jochen
Hi, sorry wie schon erwaehnt koennt ihr auf euren Mailserver so verfahren, aber mit der Realitaet auf grossen Kunden Mailsystemen hat das eben nicht viel zu tun. Nicht alles was technisch moeglich ist, ist auch gleich immer eine gute Idee fuer alle
Best Regards MfG Robert Schetterer
Am 01.07.2017 um 17:00 schrieb Walter H.:
On 01.07.2017 16:47, Joachim Fahrner wrote:
Am 2017-07-01 15:55, schrieb Robert Schetterer:
also wenn man das verwenden will ist es klug vorher zu filtern zb mit
smtpd_restriction_classes
oder einem policy server , milter etc
Ok. Aber ich steh da wohl grad auf der Leitung. Nach welchen Kriterien sollte man da filtern? Wen prüft man damit, und wen lässt man an der Prüfung vorbei?
Jochen
ich denke er meint, daß es durchaus möglich ist, daß es Mails gibt, welche berechtigterweise kommen, aber durch dieses harte blocken aber fehlschlagen, wobei ich mir die Frage stelle, ob ein Mailserver überhaupt eine Existenzberechtigung hat, wenn er sich mit HELO xxxx meldet und dieses xxxx nicht dessen DNS Name ist und die IP Adresse welche connected im Reverse DNS ebensowenig xxxx entspricht ...
client restrictions beziehen sich auf die Ip Adresse nicht auf das helo das helo ist nach rfc mehr oder weniger Schall und Rauch ,es wird nur als "formal" richtig gefordert ( zumindest war das mal so ), ich will jetzt nicht nachlesen ,aber soviel ich erinnere ist nicht mal ein reverse ptr gefordert sondern nur ein A und/oder MX Eintrag, alles andere ist mehr oder weniger best practice oder hat sich im Laufe der Zeit eben als pseudo Standard durchgesetzt ... jedenfalls wird man ebenfalls nicht gluecklich werden wenn man mit postfix im helo einen aufloesbaren dns Eintrag zwingend fordert der dann noch zusaetzlich forward und reverse matchen soll. Umgekehrt ist man allerdings gut beraten wenn man seinen eigenen Mailserver als Sender eben moeglichst genauso einrichtet. Postfix hat zwar viele Moeglichkeiten solche restrictions einzurichten es ist aber relativ unbequem diese mit postfix dynamisch anzupassen ( Achtung das heisst nicht dass es nicht sinnvoll oder nicht moeglich ist ), besser ist das jedoch in miltern und/oder policy servern zu realisieren, vor allem weil man dort eben besser klassifizieren kann ( vergleich spamassassin ). die Aufgabe von postfix ist es in erster Linie emails zu senden und zu empfangen, nicht die Filterung.
Best Regards MfG Robert Schetterer
Im Auftrag von Robert Schetterer
client restrictions beziehen sich auf die Ip Adresse nicht auf das helo das helo ist nach rfc mehr oder weniger Schall und Rauch ,es wird nur als "formal" richtig gefordert ( zumindest war das mal so ), ich will jetzt nicht nachlesen ,aber soviel ich erinnere ist nicht mal ein reverse ptr gefordert sondern nur ein A und/oder MX Eintrag, alles andere ist mehr oder weniger best practice oder hat sich im Laufe der Zeit eben als pseudo Standard durchgesetzt ... jedenfalls wird man ebenfalls nicht gluecklich werden wenn man mit postfix im helo einen aufloesbaren dns Eintrag zwingend fordert der dann noch zusaetzlich forward und reverse matchen soll. Umgekehrt ist man allerdings gut beraten wenn man seinen eigenen Mailserver als Sender eben moeglichst genauso einrichtet.
Soweit ich mich an die RFC's in Ihrem Zusammenhang / Zusammenspiel aus den einzelnen Bereichen erinnere ist das sehr wohl aus den RFC's abzuleiten das PTR als auch alle DNS Namen auf die jeweilige IP zurückzuverfolgen sein sollen/müssen
War vor ca. 3 oder 4 Jahren eine Große Diskussion auf der Liste von Peer Heinlein und sollte dort auch mit der Nennung aller relevanten RFC's zu finden sein.
Allerdings ist immer die Sache in wie weit diese strenge Prüfung auf den Mailservern eingesetzt werden kann. Es wäre allerdings ein Schritt in die Richtige Richtung gegen UBE/UCE usw.
Best Regards MfG Robert Schetterer
Mit freundlichen Grüßen
Uwe Drießen -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
Am 02.07.2017 um 21:48 schrieb Uwe Drießen:
Im Auftrag von Robert Schetterer
client restrictions beziehen sich auf die Ip Adresse nicht auf das helo das helo ist nach rfc mehr oder weniger Schall und Rauch ,es wird nur als "formal" richtig gefordert ( zumindest war das mal so ), ich will jetzt nicht nachlesen ,aber soviel ich erinnere ist nicht mal ein reverse ptr gefordert sondern nur ein A und/oder MX Eintrag, alles andere ist mehr oder weniger best practice oder hat sich im Laufe der Zeit eben als pseudo Standard durchgesetzt ... jedenfalls wird man ebenfalls nicht gluecklich werden wenn man mit postfix im helo einen aufloesbaren dns Eintrag zwingend fordert der dann noch zusaetzlich forward und reverse matchen soll. Umgekehrt ist man allerdings gut beraten wenn man seinen eigenen Mailserver als Sender eben moeglichst genauso einrichtet.
Soweit ich mich an die RFC's in Ihrem Zusammenhang / Zusammenspiel aus den einzelnen Bereichen erinnere ist das sehr wohl aus den RFC's abzuleiten das PTR als auch alle DNS Namen auf die jeweilige IP zurückzuverfolgen sein sollen/müssen
War vor ca. 3 oder 4 Jahren eine Große Diskussion auf der Liste von Peer Heinlein und sollte dort auch mit der Nennung aller relevanten RFC's zu finden sein.
kann ich mir kaum vorstellen, hab aber auch grad keine Zeit nachzulesen, real wird das allerdings zu einigen false positives fuehren
Allerdings ist immer die Sache in wie weit diese strenge Prüfung auf den Mailservern eingesetzt werden kann. Es wäre allerdings ein Schritt in die Richtige Richtung gegen UBE/UCE usw.
Best Regards MfG Robert Schetterer
Mit freundlichen Grüßen
Uwe Drießen
Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
Best Regards MfG Robert Schetterer
Am 2017-07-03 06:50, schrieb Robert Schetterer:
kann ich mir kaum vorstellen, hab aber auch grad keine Zeit nachzulesen, real wird das allerdings zu einigen false positives fuehren
Ich könnte mir vorstellen dass es einige Dienste trifft, wo ein Webserver etwas aus Scripten heraus (PHP) verschickt, z.B. Bestellbestätigungen aus Online-Shops. Die sind meist ziemlich mies konfiguriert.
Jochen
Am 03.07.2017 um 07:51 schrieb Joachim Fahrner:
Am 2017-07-03 06:50, schrieb Robert Schetterer:
kann ich mir kaum vorstellen, hab aber auch grad keine Zeit nachzulesen, real wird das allerdings zu einigen false positives fuehren
Ich könnte mir vorstellen dass es einige Dienste trifft, wo ein Webserver etwas aus Scripten heraus (PHP) verschickt, z.B. Bestellbestätigungen aus Online-Shops. Die sind meist ziemlich mies konfiguriert.
Jochen
Es gibt bedauerlicherweise x mailsysteme in der Welt die nachlaessig konfiguriert sind ,auf die eine oder andere Art, und wie die Welt so ist meint der eine oder andere Empfaenger genau von diesen Absendern kommen die "wirklich" wichtigen Mails *g , will man also nicht im Support versinken ( und evtl. kein Geld mehr verdienen ) muss man sich schon sehr genau ueberlegen wie man was filtert. Ausserdem gibts da einfach sehr viele kulturelle und rechtliche Unterschiede.
Best Regards MfG Robert Schetterer
Am 2017-07-03 17:38, schrieb Robert Schetterer:
will man also nicht im Support versinken ( und evtl. kein Geld mehr verdienen ) muss man sich schon sehr genau ueberlegen wie man was filtert.
Schon klar, das macht natürlich einen riesen Unterschied, ob man einen Maildienst anbietet, oder das nur privat für die Familie betreibt. Ich könnte z.B. alles per default sperren, und nur Amazon, Zalando und ebay auf eine Whitelist setzen. Würde keiner merken. ;-)
Jochen
Am 03.07.2017 um 18:14 schrieb Joachim Fahrner:
Am 2017-07-03 17:38, schrieb Robert Schetterer:
will man also nicht im Support versinken ( und evtl. kein Geld mehr verdienen ) muss man sich schon sehr genau ueberlegen wie man was filtert.
Schon klar, das macht natürlich einen riesen Unterschied, ob man einen Maildienst anbietet, oder das nur privat für die Familie betreibt. Ich könnte z.B. alles per default sperren, und nur Amazon, Zalando und ebay auf eine Whitelist setzen. Würde keiner merken. ;-)
Jochen
sicher dass Tschibo nicht auch ein Muss ist ? *g
Best Regards MfG Robert Schetterer
Am 2017-07-03 19:40, schrieb Robert Schetterer:
sicher dass Tschibo nicht auch ein Muss ist ? *g
Nein, Tchibo und H&M machen die Mädels offline ;-)
Im Auftrag von Robert Schetterer
Ich hatte mal wieder vergessen allen antworten anzuklicken :-)
Am 03.07.2017 um 07:51 schrieb Joachim Fahrner:
Am 2017-07-03 06:50, schrieb Robert Schetterer:
kann ich mir kaum vorstellen, hab aber auch grad keine Zeit nachzulesen, real wird das allerdings zu einigen false positives fuehren
Ich könnte mir vorstellen dass es einige Dienste trifft, wo ein Webserver etwas aus Scripten heraus (PHP) verschickt, z.B. Bestellbestätigungen aus Online-Shops. Die sind meist ziemlich mies konfiguriert.
Jochen
Es gibt bedauerlicherweise x mailsysteme in der Welt die nachlaessig konfiguriert sind ,auf die eine oder andere Art, und wie die Welt so ist meint der eine oder andere Empfaenger genau von diesen Absendern kommen die "wirklich" wichtigen Mails *g , will man also nicht im Support versinken ( und evtl. kein Geld mehr verdienen ) muss man sich schon sehr genau ueberlegen wie man was filtert. Ausserdem gibts da einfach sehr viele kulturelle und rechtliche Unterschiede.
Aber auch nur weil es zu viele Systeme gibt die von nachlässig konfigurierten Mailsystemen Mails annehmen. Wenn es jedes Mal den Absender 30 Euro kostet weil er sich nicht angeschnallt hat dann dauert das kein jahr und wir haben 95% sauber konfigurierte Mailserver Damit unter anderem auch bis zu 50% weniger UBE / UCE weil das eben nicht an jedem Dialin geht was für Mailserver gebraucht wird. Es hat für alle eigentlich nur Vorteile
Soviel mehr an Sicherheit für nicht mal 5 Minuten Aufwand am Server bzw. ist er Neu dann ist es gleich mitgemacht. Und selbst im tiefsten Kongo gibt es genug Fachwissen wie man es machen sollte. Eine Verbindliche RFC, in der alle diese Merkmale im Bezug auf Mail, ausdrücklich drin stehen an die sich wirklich ALLE halten müssen dann dauert es keine 6 Monate.
Ob groß ob klein hat jeder ein Stimme und dann ist das auch schnell durchgesetzt. Aber ich weiß RFC's zu verabschieden dauert länger als wenn das Europaparlament in die Pötte kommen soll :-)
Mit freundlichen Grüßen
Uwe Drießen -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
participants (5)
-
Joachim Fahrner -
Robert Schetterer -
Thore Boedecker -
Uwe Drießen -
Walter H.