Phishing Mails

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Phishing Mails

Joachim Fahrner
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

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)



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Robert Schetterer-2
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_hostname

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

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Robert Schetterer-2
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_hostname
>
> 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

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Joachim Fahrner
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Joachim Fahrner
In reply to this post by Robert Schetterer-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Walter H.
In reply to this post by Robert Schetterer-2
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_hostname
>>
>> 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




smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Robert Schetterer-2
In reply to this post by Joachim Fahrner
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

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Joachim Fahrner
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

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 ...



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

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...


Grüße
Thore

--

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Robert Schetterer-2
In reply to this post by Walter H.
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

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Robert Schetterer-2
In reply to this post by Joachim Fahrner
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

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Phishing Mails

Uwe Drießen
In reply to this post by Robert Schetterer-2
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Robert Schetterer-2
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

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Robert Schetterer-2
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

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Phishing Mails

Robert Schetterer-2
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

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
12
Loading...