Microsoft ESMTP MAIL Service

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

Microsoft ESMTP MAIL Service

Joachim Fahrner
Hat hier schon mal jemand was mit dem im Betreff genannten Mailserver zu
tun gehabt? Der benimmt sich ja merkwürdig.
Im Envelope-From setzt der ein "prvs=[Hexstring]=" vor den eigentlichen
Absender. Was soll denn das?
Und wenn mein reject_unverified_sender versucht dem etwas zuzustellen,
dann kommt folgendes als Antwort:

RCPT from mx00.pricosoft.com[80.152.164.96]: 450 4.1.7
<prvs=8378AE1123=user@domain>: Sender address rejected: unverified
address: host mx00.pricosoft.com[80.152.164.96] said: 451 4.7.1
<prvs=8378AE1123=user@domain>: Recipient address rejected: Throttling
too many connections from new source -  Try again later. (in reply to
RCPT TO command)

Und das mit den "too many connections" halte ich für arg übertrieben,
habe heute ganze 6 Mails davon im Log.

Was treibt Microsoft da???

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

Re: Microsoft ESMTP MAIL Service

Walter H.
On Mon, July 24, 2017 12:27, Joachim Fahrner wrote:
> Hat hier schon mal jemand was mit dem im Betreff genannten Mailserver zu
> tun gehabt?
des is'nen Teil vom MS-Exchange ...

> Der benimmt sich ja merkwürdig.
> Im Envelope-From setzt der ein "prvs=[Hexstring]=" vor den eigentlichen
> Absender. Was soll denn das?
> Und wenn mein reject_unverified_sender versucht dem etwas zuzustellen,
welche Bedeutung soll denn bitte reject_unverified_sender beim Absenden
(übergeben der Mail an Smarthosts, MX-Servern, ...) haben?
Config-Fehler?
> dann kommt folgendes als Antwort:

>
> RCPT from mx00.pricosoft.com[80.152.164.96]: 450 4.1.7
> <prvs=8378AE1123=user@domain>: Sender address rejected: unverified
> address: host mx00.pricosoft.com[80.152.164.96] said: 451 4.7.1
> <prvs=8378AE1123=user@domain>: Recipient address rejected: Throttling
> too many connections from new source -  Try again later. (in reply to
> RCPT TO command)

ist das der Logeintrag in DEINEM Postfix, wie Du die Mail dorthin schickst?



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

Re: Microsoft ESMTP MAIL Service

Lars Täuber
Mon, 24 Jul 2017 14:06:05 +0200
"Walter H." <[hidden email]> ==> [hidden email] :

> On Mon, July 24, 2017 12:27, Joachim Fahrner wrote:
> > Hat hier schon mal jemand was mit dem im Betreff genannten Mailserver zu
> > tun gehabt?  
> des is'nen Teil vom MS-Exchange ...
>
> > Der benimmt sich ja merkwürdig.
> > Im Envelope-From setzt der ein "prvs=[Hexstring]=" vor den eigentlichen
> > Absender. Was soll denn das?
> > Und wenn mein reject_unverified_sender versucht dem etwas zuzustellen,  
> welche Bedeutung soll denn bitte reject_unverified_sender beim Absenden
> (übergeben der Mail an Smarthosts, MX-Servern, ...) haben?
> Config-Fehler?
> > dann kommt folgendes als Antwort:  
>
> >
> > RCPT from mx00.pricosoft.com[80.152.164.96]: 450 4.1.7
> > <prvs=8378AE1123=user@domain>: Sender address rejected: unverified
> > address: host mx00.pricosoft.com[80.152.164.96] said: 451 4.7.1
> > <prvs=8378AE1123=user@domain>: Recipient address rejected: Throttling
> > too many connections from new source -  Try again later. (in reply to
> > RCPT TO command)  
>
> ist das der Logeintrag in DEINEM Postfix, wie Du die Mail dorthin schickst?
>

So funktioniert reject_unverified_sender. Der empfangende Server überprüft, ob die als Absender angegebene E-Mailadresse existiert, indem er versucht dorthin eine Mail abzusenden.
Meistens geht das schief, da diese BATV[1] in den meisten Exchange-Servern leider so eingestellt ist, dass die Mailserver an die von Ihnen vergebenen temporären Mailadresse keine Mails empfangen. Es geht auch anders (Uni-Halle), aber anscheinend wissen die wenigsten Exchangeadmins, wie das geht. Das Einschalten dieser Option ist offenbar nur ein Haken, den man in der Konfiguration setzen kann. Und der Hilfetext dazu verspricht gutes gegen Spammer.

Wir haben hier auch damit zu kämpfen und lösen das mit einer manuell geführten Ausnahmeliste bestimmter Server.

Wenn da mal jemand eine bessere Lösung hat, wäre das schön.
Vielleicht bekommt Postfix mal die Fähigkeit, aus einer solchen prvs=____= -Adresse die eigentliche für einen sender_check zu extrahieren.


Grüße
Lars

[1] https://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation

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

Re: Microsoft ESMTP MAIL Service

Joachim Fahrner
In reply to this post by Walter H.
Am 2017-07-24 14:06, schrieb Walter H.:

>> Und wenn mein reject_unverified_sender versucht dem etwas zuzustellen,
> welche Bedeutung soll denn bitte reject_unverified_sender beim Absenden
> (übergeben der Mail an Smarthosts, MX-Servern, ...) haben?
> Config-Fehler?

Ich empfange diese Mails vom Exchange, ich sende sie nicht.

>> RCPT from mx00.pricosoft.com[80.152.164.96]: 450 4.1.7
>> <prvs=8378AE1123=user@domain>: Sender address rejected: unverified
>> address: host mx00.pricosoft.com[80.152.164.96] said: 451 4.7.1
>> <prvs=8378AE1123=user@domain>: Recipient address rejected: Throttling
>> too many connections from new source -  Try again later. (in reply to
>> RCPT TO command)
>
> ist das der Logeintrag in DEINEM Postfix, wie Du die Mail dorthin
> schickst?

Ja und nein. Es ist MEIN Logeintrag, und ich EMPFANGE. Das ist die
Antwort vom Exchange bei meinem verify_sender.



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

Re: Microsoft ESMTP MAIL Service

Joachim Fahrner
In reply to this post by Lars Täuber
Am 2017-07-24 15:20, schrieb Lars Täuber:

> So funktioniert reject_unverified_sender. Der empfangende Server
> überprüft, ob die als Absender angegebene E-Mailadresse existiert,
> indem er versucht dorthin eine Mail abzusenden.
> Meistens geht das schief, da diese BATV[1] in den meisten
> Exchange-Servern leider so eingestellt ist, dass die Mailserver an die
> von Ihnen vergebenen temporären Mailadresse keine Mails empfangen. Es
> geht auch anders (Uni-Halle), aber anscheinend wissen die wenigsten
> Exchangeadmins, wie das geht. Das Einschalten dieser Option ist
> offenbar nur ein Haken, den man in der Konfiguration setzen kann. Und
> der Hilfetext dazu verspricht gutes gegen Spammer.

Exakt so ist es. Leider. :-(

In der Praxis ist das verify_sender wohl nicht zu gebrauchen. Ob wohl
ich ja grundsätzlich irgendwie der Meinung bin "warum sollte ich Mails
annehmen auf die ich nicht antworten kann"? (oder die im Envelope
behaupten von jemand anders zu sein).

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

AW: Microsoft ESMTP MAIL Service

Uwe Drießen
Im Auftrag von Joachim Fahrner

>
> Am 2017-07-24 15:20, schrieb Lars Täuber:
> > So funktioniert reject_unverified_sender. Der empfangende Server
> > überprüft, ob die als Absender angegebene E-Mailadresse existiert,
> > indem er versucht dorthin eine Mail abzusenden.
> > Meistens geht das schief, da diese BATV[1] in den meisten
> > Exchange-Servern leider so eingestellt ist, dass die Mailserver an die
> > von Ihnen vergebenen temporären Mailadresse keine Mails empfangen.
> Es
> > geht auch anders (Uni-Halle), aber anscheinend wissen die wenigsten
> > Exchangeadmins, wie das geht. Das Einschalten dieser Option ist
> > offenbar nur ein Haken, den man in der Konfiguration setzen kann. Und
> > der Hilfetext dazu verspricht gutes gegen Spammer.
>
> Exakt so ist es. Leider. :-(
>
> In der Praxis ist das verify_sender wohl nicht zu gebrauchen. Ob wohl
> ich ja grundsätzlich irgendwie der Meinung bin "warum sollte ich Mails
> annehmen auf die ich nicht antworten kann"? (oder die im Envelope
> behaupten von jemand anders zu sein).


1. Weil man mit dem Senderverify durchaus unbeteiligte Server Dritter in die Knie zwingen kann

Stell dir vor einer schreibt mit einem gefälschten Absender und bombardiert damit 1000 Mailserver die alle das senderverify machen
Was macht dann Microsoft (oder jeder andere Mailserver)  ?
Die sind dann nur noch mit dem senderverify beschäftigt  
Die Server sind dann Tod

2. auch ich unterbinde das Senderverify!

disable_vrfy_command                =   yes
nimm die Mail an oder gib sie zurück aber belaste das Netz nicht mit unnötigen abfragen
Ein Spamer wird dir IMMER ein YES / EXISTIERT zurückgeben also was bringt die Prüfung ?
Die Mailadresse wird nach Versand gelöscht und dann ? kannste senden was und wo auch immer hin sie kommt nicht mehr an :-)
 

3. gibt es ausreichend Prüfmöglichkeiten ob der Sendehost zu dem Domainanteil passt oder auch nicht
4. Leider nicht jeder Mailserver überprüft oder die benutzte Adresse auch zum eigenen Host passt

 
Ich bin Mailserver ich transportiere Mail
Ich prüfe die Rahmenbedingungen unter denen ich Mails annehme
Bist du gut als Fälscher und machst alles richtig dann hast du es verdient auch zugestellt zu werden :-)

Bei jeder Prüfung die du durchführst sorge dafür das KEIN unbeteiligter Dritter damit belästigt werden kann.

Der Senderverify geht an den DNS und prüft welche IP im DNS steht und macht dort die Prüfung. Das muss NICHT der Sendende Server sein.
Alle Prüfungen/Abweisungen  in Session, vermeide Latebounces.



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: AW: Microsoft ESMTP MAIL Service

Joachim Fahrner
Am 2017-07-24 15:53, schrieb Uwe Drießen:
> 2. auch ich unterbinde das Senderverify!
>
> disable_vrfy_command                =   yes

Postfix nutzt dafür nicht das Verify-Kommando. Damit unterbindest du das
nicht.
http://www.postfix.org/ADDRESS_VERIFICATION_README.html

"Postfix assumes that a remote SMTP server will reject unknown addresses
in reply to the RCPT TO command."

> nimm die Mail an oder gib sie zurück aber belaste das Netz nicht mit
> unnötigen abfragen
> Ein Spamer wird dir IMMER ein YES / EXISTIERT zurückgeben also was
> bringt die Prüfung ?

Wietse wird sich sicher was dabei gedacht haben, sonst hätte er es nicht
implementiert.

Jochen

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

AW: AW: Microsoft ESMTP MAIL Service

Uwe Drießen
Im Auftrag von Joachim Fahrner


> Am 2017-07-24 15:53, schrieb Uwe Drießen:
> > 2. auch ich unterbinde das Senderverify!
> >
> > disable_vrfy_command                =   yes
>
> Postfix nutzt dafür nicht das Verify-Kommando. Damit unterbindest du das
> nicht.
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html
>
> "Postfix assumes that a remote SMTP server will reject unknown addresses
> in reply to the RCPT TO command."
>
> > nimm die Mail an oder gib sie zurück aber belaste das Netz nicht mit
> > unnötigen abfragen
> > Ein Spamer wird dir IMMER ein YES / EXISTIERT zurückgeben also was
> > bringt die Prüfung ?
>
> Wietse wird sich sicher was dabei gedacht haben, sonst hätte er es nicht
> implementiert.

Ja hat er sich auch :-)

disable_vrfy_command (default: no)

    Disable the SMTP VRFY command. This stops some techniques used to harvest email addresses.

    Example:

    disable_vrfy_command = no

Fremde bei mir

Und du kannst es drehen und wenden wie du möchtest ich kann mich an die Diskussionen auf Peers Liste schon vor 3 - 4 - 5 Jahren erinnern warum man es nicht tun soll :-)  

And take a look at the limitations  

http://www.postfix.org/ADDRESS_VERIFICATION_README.html#limitations

damit wird es nur noch selektiv einsetzbar.
Ich nutze es in der Regel dann wenn ich die Mailadressen eines nachgelagerten Hosts nicht alle habe um zu prüfen ob der Relayhost die Mail annehmen würde, nicht ob ich dem Absender eine zurückschicken kann.

>
> Jochen



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: Microsoft ESMTP MAIL Service

Walter H.
In reply to this post by Joachim Fahrner
On 24.07.2017 15:29, Joachim Fahrner wrote:
> Ob wohl ich ja grundsätzlich irgendwie der Meinung bin "warum sollte
> ich Mails annehmen auf die ich nicht antworten kann"? (oder die im
> Envelope behaupten von jemand anders zu sein).
>
hat nur den Pferdefuß, daß Du dir dabei selbst eine trittst ... ,
spätestens wenn ausgehender Mailserver vom Sender ein anderer ist als
der eingehende Mailserver;
(der Mailserver, der Dir eine Mail geben will, wird NIE eine von anderen
Hosts annehmen)


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

Re: AW: AW: Microsoft ESMTP MAIL Service

Joachim Fahrner
In reply to this post by Uwe Drießen
Am 2017-07-24 16:47, schrieb Uwe Drießen:

> disable_vrfy_command (default: no)
>
>     Disable the SMTP VRFY command. This stops some techniques used to
> harvest email addresses.
>
>     Example:
>
>     disable_vrfy_command = no
>
> Fremde bei mir

Lies nochmal genau was ich geschrieben/zitiert habe. Die Sender address
verification benutzt NICHT das SMTP VRFY Kommando, sondern versucht ganz
normal mit RCPT TO eine Mailzustellung. Deswegen schützt du dich eben
nicht gegen solche Verifikation. Da täuscht du dich.

Jochen


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

Re: AW: AW: Microsoft ESMTP MAIL Service

Walter H.
On 24.07.2017 17:05, Joachim Fahrner wrote:

> Am 2017-07-24 16:47, schrieb Uwe Drießen:
>> disable_vrfy_command (default: no)
>>
>>     Disable the SMTP VRFY command. This stops some techniques used to
>> harvest email addresses.
>>
>>     Example:
>>
>>     disable_vrfy_command = no
>>
>> Fremde bei mir
>
> Lies nochmal genau was ich geschrieben/zitiert habe. Die Sender
> address verification benutzt NICHT das SMTP VRFY Kommando, sondern
> versucht ganz normal mit RCPT TO eine Mailzustellung. Deswegen schützt
> du dich eben nicht gegen solche Verifikation. Da täuscht du dich.
was soll das bringen, wenn damit eine Mailzustellung - eigentlich
sinnlos - verzögert wird?
die andere Seite, muss ja nicht sofort annehmen, und damit schaukelt
sich etwas auf, was nicht wirklich Sinn macht;
spätestens dann, wenn Du z.B. einen Link zum aktivieren von irgendwas
bekommst und dieser nur 1 Stunde gültig ist,
und auf die Art es aber mehr als diese 1 Stunde dauert bis die Mail
erfolgreich zugestellt werden kann ...
macht ja keinen Sinn ...





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

Re: Microsoft ESMTP MAIL Service

Robert Schetterer-2
In reply to this post by Walter H.
Am 24.07.2017 um 16:55 schrieb Walter H.:

> On 24.07.2017 15:29, Joachim Fahrner wrote:
>> Ob wohl ich ja grundsätzlich irgendwie der Meinung bin "warum sollte
>> ich Mails annehmen auf die ich nicht antworten kann"? (oder die im
>> Envelope behaupten von jemand anders zu sein).
>>
> hat nur den Pferdefuß, daß Du dir dabei selbst eine trittst ... ,
> spätestens wenn ausgehender Mailserver vom Sender ein anderer ist als
> der eingehende Mailserver;
> (der Mailserver, der Dir eine Mail geben will, wird NIE eine von anderen
> Hosts annehmen)
>

lesen und verstehen

http://www.postfix.org/ADDRESS_VERIFICATION_README.html#sender_always

du kannst das gerne einschalten musst dann halt mit den Fehlern leben

beachte besonders

Sender address verification for all email

Unfortunately, sender address verification cannot simply be turned on
for all email - you are likely to lose legitimate mail from
mis-configured systems. You almost certainly will have to set up white
lists for specific addresses, or even for entire domains.

zu deutsch vergiss das einfach ,oder nutze es nur in Sonderfaellen

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: AW: AW: Microsoft ESMTP MAIL Service

Joachim Fahrner
In reply to this post by Walter H.
Am 2017-07-24 17:19, schrieb Walter H.:

> was soll das bringen, wenn damit eine Mailzustellung - eigentlich
> sinnlos - verzögert wird?
> die andere Seite, muss ja nicht sofort annehmen, und damit schaukelt
> sich etwas auf, was nicht wirklich Sinn macht;

Mit dem gleichen Argument müsstest du auch postscreen und postgrey
ablehnen.

Hier eine aktuelles Beispiel wo es geholfen hätte (momentan hab ich es
nur als warn_if_reject konfiguriert, deshalb kam die Phishing-Mail
durch:

Jul 23 22:56:15 server postfix/postscreen[29838]: CONNECT from
[85.13.129.212]:49554 to [172.31.1.100]:25
Jul 23 22:56:15 server postfix/dnsblog[29840]: addr 85.13.129.212 listed
by domain list.dnswl.org as 127.0.5.1
Jul 23 22:56:21 server postfix/postscreen[29838]: PASS NEW
[85.13.129.212]:49554
Jul 23 22:56:22 server postfix/smtpd[29843]: connect from
dd3332.kasserver.com[85.13.129.212]
Jul 23 22:56:22 server postfix/smtpd[29843]: Anonymous TLS connection
established from dd3332.kasserver.com[85.13.129.212]: TLSv1.2 with
cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jul 23 22:56:23 server postfix/cleanup[29850]: 1BEFC1016DC:
message-id=<[hidden email]>
Jul 23 22:56:23 server postfix/qmgr[5188]: 1BEFC1016DC:
from=<[hidden email]>, size=277, nrcpt=1 (queue active)
Jul 23 22:56:23 server postfix/verify[29848]: cache
proxy:btree:/var/lib/postfix/verified_senders full cleanup: retained=475
dropped=2 entries
Jul 23 22:56:23 server postfix/smtp[29851]: Trusted TLS connection
established to w00c4958.kasserver.com[85.13.129.212]:25: TLSv1.2 with
cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jul 23 22:56:23 server postfix/smtp[29851]: 1BEFC1016DC:
to=<[hidden email]>,
relay=w00c4958.kasserver.com[85.13.129.212]:25, delay=0.66,
delays=0.01/0.04/0.55/0.06, dsn=5.1.1, status=undeliverable (host
w00c4958.kasserver.com[85.13.129.212] said: 550 5.1.1
<[hidden email]>: Recipient address rejected: User unknown
in virtual alias table (in reply to RCPT TO command))
Jul 23 22:56:23 server postfix/qmgr[5188]: 1BEFC1016DC: removed
Jul 23 22:56:26 server postfix/smtpd[29843]: NOQUEUE: reject_warning:
RCPT from dd3332.kasserver.com[85.13.129.212]: 550 5.1.7
<[hidden email]>: Sender address rejected: undeliverable
address: host w00c4958.kasserver.com[85.13.129.212] said: 550 5.1.1
<[hidden email]>: Recipient address rejected: User unknown
in virtual alias table (in reply to RCPT TO command);
from=<[hidden email]> to=<[hidden email]> proto=ESMTP
helo=<dd3332.kasserver.com>
Jul 23 22:56:27 server policyd-weight[5974]: weighted check:  
NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 CL_IP_EQ_FROM_MX=-3.1;
<client=dd3332.kasserver.com[85.13.129.212]> <helo=dd3332.kasserver.com>
<from=[hidden email]> <to=[hidden email]>; rate: -6.1
Jul 23 22:56:27 server policyd-weight[5974]: decided action=PREPEND
X-policyd-weight:  NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5
CL_IP_EQ_FROM_MX=-3.1; rate: -6.1;
<client=dd3332.kasserver.com[85.13.129.212]> <helo=dd3332.kasserver.com>
<from=[hidden email]> <to=[hidden email]>; delay: 1s
Jul 23 22:56:27 server postfix/smtpd[29843]: 7B8991016DC:
client=dd3332.kasserver.com[85.13.129.212]
Jul 23 22:56:27 server postfix/cleanup[29850]: 7B8991016DC:
message-id=<[hidden email]>
Jul 23 22:56:27 server opendkim[4343]: 7B8991016DC: dd3332.kasserver.com
[85.13.129.212] not internal
Jul 23 22:56:27 server opendkim[4343]: 7B8991016DC: not authenticated
Jul 23 22:56:27 server opendkim[4343]: 7B8991016DC: no signature data
Jul 23 22:56:27 server opendmarc[4353]: 7B8991016DC: autolederfarbe.de
none
Jul 23 22:56:27 server spamd[3671]: spamd: got connection over
/var/run/spamd.sock
Jul 23 22:56:27 server spamd[3671]: spamd: processing message
<[hidden email]> for jf:116
Jul 23 22:56:28 server spamd[3671]: spamd: clean message (0.0/5.0) for
jf:116 in 0.8 seconds, 7169 bytes.
Jul 23 22:56:28 server spamd[3671]: spamd: result: . 0 -
HTML_MESSAGE,UNPARSEABLE_RELAY
scantime=0.8,size=7169,user=jf,uid=116,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=/var/run/spamd.sock,mid=<[hidden email]>,autolearn=ham
autolearn_force=no

Alles hat bei dieser Mail versagt: postscreen, dmarc, dkim,
policyd-weight, spamassassin. Das einzige was geholfen hätte:
sender_verify.

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

Re: Microsoft ESMTP MAIL Service

Robert Schetterer-2
Am 24.07.2017 um 18:48 schrieb Joachim Fahrner:

> Am 2017-07-24 17:19, schrieb Walter H.:
>
>> was soll das bringen, wenn damit eine Mailzustellung - eigentlich
>> sinnlos - verzögert wird?
>> die andere Seite, muss ja nicht sofort annehmen, und damit schaukelt
>> sich etwas auf, was nicht wirklich Sinn macht;
>
> Mit dem gleichen Argument müsstest du auch postscreen und postgrey
> ablehnen.
>
> Hier eine aktuelles Beispiel wo es geholfen hätte (momentan hab ich es
> nur als warn_if_reject konfiguriert, deshalb kam die Phishing-Mail durch:
>
> Jul 23 22:56:15 server postfix/postscreen[29838]: CONNECT from
> [85.13.129.212]:49554 to [172.31.1.100]:25
> Jul 23 22:56:15 server postfix/dnsblog[29840]: addr 85.13.129.212 listed
> by domain list.dnswl.org as 127.0.5.1
> Jul 23 22:56:21 server postfix/postscreen[29838]: PASS NEW
> [85.13.129.212]:49554
> Jul 23 22:56:22 server postfix/smtpd[29843]: connect from
> dd3332.kasserver.com[85.13.129.212]
> Jul 23 22:56:22 server postfix/smtpd[29843]: Anonymous TLS connection
> established from dd3332.kasserver.com[85.13.129.212]: TLSv1.2 with
> cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Jul 23 22:56:23 server postfix/cleanup[29850]: 1BEFC1016DC:
> message-id=<[hidden email]>
> Jul 23 22:56:23 server postfix/qmgr[5188]: 1BEFC1016DC:
> from=<[hidden email]>, size=277, nrcpt=1 (queue active)
> Jul 23 22:56:23 server postfix/verify[29848]: cache
> proxy:btree:/var/lib/postfix/verified_senders full cleanup: retained=475
> dropped=2 entries
> Jul 23 22:56:23 server postfix/smtp[29851]: Trusted TLS connection
> established to w00c4958.kasserver.com[85.13.129.212]:25: TLSv1.2 with
> cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Jul 23 22:56:23 server postfix/smtp[29851]: 1BEFC1016DC:
> to=<[hidden email]>,
> relay=w00c4958.kasserver.com[85.13.129.212]:25, delay=0.66,
> delays=0.01/0.04/0.55/0.06, dsn=5.1.1, status=undeliverable (host
> w00c4958.kasserver.com[85.13.129.212] said: 550 5.1.1
> <[hidden email]>: Recipient address rejected: User unknown
> in virtual alias table (in reply to RCPT TO command))
> Jul 23 22:56:23 server postfix/qmgr[5188]: 1BEFC1016DC: removed
> Jul 23 22:56:26 server postfix/smtpd[29843]: NOQUEUE: reject_warning:
> RCPT from dd3332.kasserver.com[85.13.129.212]: 550 5.1.7
> <[hidden email]>: Sender address rejected: undeliverable
> address: host w00c4958.kasserver.com[85.13.129.212] said: 550 5.1.1
> <[hidden email]>: Recipient address rejected: User unknown
> in virtual alias table (in reply to RCPT TO command);
> from=<[hidden email]> to=<[hidden email]> proto=ESMTP
> helo=<dd3332.kasserver.com>
> Jul 23 22:56:27 server policyd-weight[5974]: weighted check:
> NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 CL_IP_EQ_FROM_MX=-3.1;
> <client=dd3332.kasserver.com[85.13.129.212]> <helo=dd3332.kasserver.com>
> <from=[hidden email]> <to=[hidden email]>; rate: -6.1
> Jul 23 22:56:27 server policyd-weight[5974]: decided action=PREPEND
> X-policyd-weight:  NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5
> CL_IP_EQ_FROM_MX=-3.1; rate: -6.1;
> <client=dd3332.kasserver.com[85.13.129.212]> <helo=dd3332.kasserver.com>
> <from=[hidden email]> <to=[hidden email]>; delay: 1s
> Jul 23 22:56:27 server postfix/smtpd[29843]: 7B8991016DC:
> client=dd3332.kasserver.com[85.13.129.212]
> Jul 23 22:56:27 server postfix/cleanup[29850]: 7B8991016DC:
> message-id=<[hidden email]>
> Jul 23 22:56:27 server opendkim[4343]: 7B8991016DC: dd3332.kasserver.com
> [85.13.129.212] not internal
> Jul 23 22:56:27 server opendkim[4343]: 7B8991016DC: not authenticated
> Jul 23 22:56:27 server opendkim[4343]: 7B8991016DC: no signature data
> Jul 23 22:56:27 server opendmarc[4353]: 7B8991016DC: autolederfarbe.de none
> Jul 23 22:56:27 server spamd[3671]: spamd: got connection over
> /var/run/spamd.sock
> Jul 23 22:56:27 server spamd[3671]: spamd: processing message
> <[hidden email]> for jf:116
> Jul 23 22:56:28 server spamd[3671]: spamd: clean message (0.0/5.0) for
> jf:116 in 0.8 seconds, 7169 bytes.
> Jul 23 22:56:28 server spamd[3671]: spamd: result: . 0 -
> HTML_MESSAGE,UNPARSEABLE_RELAY
> scantime=0.8,size=7169,user=jf,uid=116,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=/var/run/spamd.sock,mid=<[hidden email]>,autolearn=ham
> autolearn_force=no
>
> Alles hat bei dieser Mail versagt: postscreen, dmarc, dkim,
> policyd-weight, spamassassin. Das einzige was geholfen hätte:
> sender_verify.
>

ich denke die postfix faqs sind da voellig klar, sender verify sollte
man nur selektiv anwenden, ein gutes Verfahren ist also eine Kaskade, da
die Verfahren zb alle als milter verfuegbar sind kann man die Logik z.B
in/mit milter manager bauen. Das Problem bei sender verify ist schlicht
dass es einfach nicht sicher funktioniert, ein verify deines servers
koennte z.b auch auf der anderen Seite von greylisting beantwortet
werden, damit waere das Resultat dann unbrauchbar usw


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: Microsoft ESMTP MAIL Service

Joachim Fahrner
Am 2017-07-24 19:06, schrieb Robert Schetterer:

> ich denke die postfix faqs sind da voellig klar, sender verify sollte
> man nur selektiv anwenden, ein gutes Verfahren ist also eine Kaskade,
> da
> die Verfahren zb alle als milter verfuegbar sind kann man die Logik z.B
> in/mit milter manager bauen. Das Problem bei sender verify ist schlicht
> dass es einfach nicht sicher funktioniert, ein verify deines servers
> koennte z.b auch auf der anderen Seite von greylisting beantwortet
> werden, damit waere das Resultat dann unbrauchbar usw

Klar, ohne whitelisting bekommt man zu viele rejects (siehe dieser MS
Exchange Server). Deswegen wird ja auch empfohlen das eine Weile mit
warn_if_reject zu betreiben, einerseits die Datenbank aufzubauen, und
andrerseits sich eine persönliche whitelist anzulegen. Aber gerade gegen
Phishing-Mails scheint es mir derzeit die einzige funktionierende Lösung
zu sein. Spam wird bei mir mittlerweile zu 99,9% abgewehrt, das einzige
was noch durchkommt ist ab und zu eine Phishing-Mail. Die
Phishing-Betrüger gehen auch völlig anders vor. Die sind nicht darauf
angewiesen möglichst viele Empfänger zu erreichen, denen ist es
wichtiger wenige Empfänger *zuverlässig* zu erreichen, ohne das diese
Verdacht schöpfen. Ganz andere Vorgehensweise. Die müssen ihre Identität
möglichst gut verschleiern und möglichst keinen "Alarm auslösen".

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

Re: Microsoft ESMTP MAIL Service

Robert Schetterer-2
Am 24.07.2017 um 19:20 schrieb Joachim Fahrner:

> Am 2017-07-24 19:06, schrieb Robert Schetterer:
>
>> ich denke die postfix faqs sind da voellig klar, sender verify sollte
>> man nur selektiv anwenden, ein gutes Verfahren ist also eine Kaskade, da
>> die Verfahren zb alle als milter verfuegbar sind kann man die Logik z.B
>> in/mit milter manager bauen. Das Problem bei sender verify ist schlicht
>> dass es einfach nicht sicher funktioniert, ein verify deines servers
>> koennte z.b auch auf der anderen Seite von greylisting beantwortet
>> werden, damit waere das Resultat dann unbrauchbar usw
>
> Klar, ohne whitelisting bekommt man zu viele rejects (siehe dieser MS
> Exchange Server). Deswegen wird ja auch empfohlen das eine Weile mit
> warn_if_reject zu betreiben, einerseits die Datenbank aufzubauen, und
> andrerseits sich eine persönliche whitelist anzulegen. Aber gerade gegen
> Phishing-Mails scheint es mir derzeit die einzige funktionierende Lösung
> zu sein. Spam wird bei mir mittlerweile zu 99,9% abgewehrt, das einzige
> was noch durchkommt ist ab und zu eine Phishing-Mail. Die
> Phishing-Betrüger gehen auch völlig anders vor. Die sind nicht darauf
> angewiesen möglichst viele Empfänger zu erreichen, denen ist es
> wichtiger wenige Empfänger *zuverlässig* zu erreichen, ohne das diese
> Verdacht schöpfen. Ganz andere Vorgehensweise. Die müssen ihre Identität
> möglichst gut verschleiern und möglichst keinen "Alarm auslösen".
>
> Jochen

Jochen , wenn du meinen Server staendig nach mail adressen befragst die
nicht existieren, sperre ich deinen Server weil das wiederum Abuse ist
und melde wiederum deinen Server auf eine RBL und so machen das viele
Admins, wenn sie es nicht per se schon automatisiert haben
in der Theorie klingt das Feature fein in der Praxis funktioniert es
nicht zuverlaessig,habe ich alles vor Jahren schon getestet.

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: Microsoft ESMTP MAIL Service

Joachim Fahrner
Am 2017-07-24 19:24, schrieb Robert Schetterer:
> Jochen , wenn du meinen Server staendig nach mail adressen befragst die
> nicht existieren, sperre ich deinen Server weil das wiederum Abuse ist
> und melde wiederum deinen Server auf eine RBL

Wieso? Du bekommst doch von mir nicht mehr Anfragen als du mir Mails
schickst. Und zwar pro Absenderadresse nur einmal eine Anfrage. Und wenn
andere deine Mailadressen massenhaft misbrauchen, dann schütze deine
Domain eben mit SPF oder DMARC.

Außerdem ändern sich die Zeiten. Spammer müssen heute keine Absender
mehr erfinden. Die nehmen real existierende Adressen. Anders bei den
Phishing-Betrügern, die wollen ja möglichst unentdeckt bleiben. Die
erfinden dann so Absender wie "[hidden email]". Wichtig ist
denen, dass Wörter wie "Sparkasse" (oder was sie halt gerade abphishen
wollen) möglichst oft auftaucht, damit man nicht mistrauisch wird.


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

Re: Microsoft ESMTP MAIL Service

Walter H.
On 24.07.2017 19:36, Joachim Fahrner wrote:
> Am 2017-07-24 19:24, schrieb Robert Schetterer:
>> Jochen , wenn du meinen Server staendig nach mail adressen befragst die
>> nicht existieren, sperre ich deinen Server weil das wiederum Abuse ist
>> und melde wiederum deinen Server auf eine RBL
>
> Wieso?
na ja im Envelope passiert ja nur sowas:

EHLO xxxx
reply
MAIL FROM: <...>
reply
RCPT TO: <....>
reply
QUIT
reply

und das würde ich als Abuse sehen ...

folgendes sollte hoffentlich nicht passieren, wäre als DDoS durchaus denkbar
<BEGIN>
ein Botnetz versucht bei Dir Mails abzuladen - mit den verschiedensten
Absendern,
und das nicht nur auf Deinem Server sondern auch auf vielen, und jetzt
hast das kartesische Produkt
jeder dieser Ziel-Mailserver veranstaltet mit den bestimmten
Absender-Servern das Spielen von oben ...
und schwupp, sind diese alle auf einer Liste ...
<END>

> Du bekommst doch von mir nicht mehr Anfragen als du mir Mails
> schickst. Und zwar pro Absenderadresse nur einmal eine Anfrage. Und
> wenn andere deine Mailadressen massenhaft misbrauchen, dann schütze
> deine Domain eben mit SPF oder DMARC.
>
SPF ist so gut wie die potentiellen Zielserver der SPAM-Industrie es
auch implementiert haben ...
DMARC bringt gar nix, ich betrachte nur die vielen Mails, welche als
Antwort meiner Mails an Maillisten wie diese hier gehen ...
wobei dieser Server hier zumindest was bestimmte Eigenschaften angeht
korrekt implementiert ist -> signierte Mails kommen auch als signierte
an ...

> Außerdem ändern sich die Zeiten. Spammer müssen heute keine Absender
> mehr erfinden. Die nehmen real existierende Adressen.
klar, weil sie ja durch sämtliche Mechanismen (SPAMfilter, ...)
durchkommen wollen ...
> Anders bei den Phishing-Betrügern, die wollen ja möglichst unentdeckt
> bleiben. Die erfinden dann so Absender wie "[hidden email]".
> Wichtig ist denen, dass Wörter wie "Sparkasse" (oder was sie halt
> gerade abphishen wollen) möglichst oft auftaucht, damit man nicht
> mistrauisch wird.
>
wenn man bei dem sender_verify ohnehin eine whitelist braucht, kann man
diese gleich direkt haben,
und alles andere direkt blockieren ...
indem man einfach per IPtables was auch immer nur die Mailserver zuläßt
von wo man Mails erwartet ...
(wer seinen eigenen privaten Mail server betreibt ist damit am besten dran)



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

Re: Microsoft ESMTP MAIL Service

Robert Schetterer-2
In reply to this post by Joachim Fahrner
Am 24.07.2017 um 19:36 schrieb Joachim Fahrner:
> Am 2017-07-24 19:24, schrieb Robert Schetterer:
>> Jochen , wenn du meinen Server staendig nach mail adressen befragst die
>> nicht existieren, sperre ich deinen Server weil das wiederum Abuse ist
>> und melde wiederum deinen Server auf eine RBL
>
> Wieso? Du bekommst doch von mir nicht mehr Anfragen als du mir Mails
> schickst. Und zwar pro Absenderadresse nur einmal eine Anfrage. Und wenn
> andere deine Mailadressen massenhaft misbrauchen, dann schütze deine
> Domain eben mit SPF oder DMARC.


Zunaechst gibt es keine Pflicht SPF DMARC DKIM etc zu haben
oder es zu validieren, dann sind strikte Policies eher selten
wegen damit verbundener Probleme, das caching deines Servers daempft das
Problem nur
denn dein Server kann mit x nicht existierenden
Mailadressen von x Quellen beballert werden, die Server an die du
verifizierst koennen x Massnahmen zur Begrenzung
pro Zeiteinheit und/oder greylisting, postscreen oder was auch immer
haben d.h du bekommst evtl keine Antwort die fuer deinen Mailserver
zuverlaessig verwertbar ist, das Verfahren ist wirklich nur im absoluten
Einzelfall sinnvoll, im Zweifelsfalls machst du die Sache fuer Dritte
und dich selbst nur schlimmer, da du mit sinnfreien Abfragen deine wie
die Smtp Slots anderer fuer legalen Mailverkehr blockierst.


>
> Außerdem ändern sich die Zeiten. Spammer müssen heute keine Absender
> mehr erfinden. Die nehmen real existierende Adressen. Anders bei den
> Phishing-Betrügern, die wollen ja möglichst unentdeckt bleiben. Die
> erfinden dann so Absender wie "[hidden email]". Wichtig ist
> denen, dass Wörter wie "Sparkasse" (oder was sie halt gerade abphishen
> wollen) möglichst oft auftaucht, damit man nicht mistrauisch wird.
>
>

ich sehe da nichts Neues das gabs schon immer ,im Gegenteil im Grunde
hat sich da nicht viel Neues getan, ich kann eigentlich nur "eine"
Aenderung feststellen , dass man Ziele "genauer" aufs Korn nimmt


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: Microsoft ESMTP MAIL Service

Joachim Fahrner
Am 2017-07-24 20:51, schrieb Robert Schetterer:

> das Verfahren ist wirklich nur im absoluten
> Einzelfall sinnvoll,

Was verstehst du denn unter "Einzelfall"? Eine bestimmte Installation,
so wie meine, oder für bestimmte Absenderdomains? Letzteres halte ich
für wenig sinnvoll, denn die Verifizierung macht ja erst bei unbekannten
Absendern Sinn. Bei bekannten Absendern kann ich auch direkt hart
sperren.

Jochen


12
Loading...