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
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?
Mon, 24 Jul 2017 14:06:05 +0200 "Walter H." walter.h@mathemainzel.info ==> postfix-users@de.postfix.org :
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
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).
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
Am 2017-07-24 15:53, schrieb Uwe Drießen:
- 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
Im Auftrag von Joachim Fahrner
Am 2017-07-24 15:53, schrieb Uwe Drießen:
- 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
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 toharvest email addresses.
Example: disable_vrfy_command = noFremde 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
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 toharvest email addresses.
Example: disable_vrfy_command = noFremde 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 ...
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=20170723205623.1BEFC1016DC@server.fahrner.name Jul 23 22:56:23 server postfix/qmgr[5188]: 1BEFC1016DC: from=double-bounce@fahrner.name, 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=sparkasse@autolederfarbe.de, 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 sparkasse@autolederfarbe.de: 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 sparkasse@autolederfarbe.de: Sender address rejected: undeliverable address: host w00c4958.kasserver.com[85.13.129.212] said: 550 5.1.1 sparkasse@autolederfarbe.de: Recipient address rejected: User unknown in virtual alias table (in reply to RCPT TO command); from=sparkasse@autolederfarbe.de to=jf@fahrner.name 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=sparkasse@autolederfarbe.de to=jf@fahrner.name; 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=sparkasse@autolederfarbe.de to=jf@fahrner.name; 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=20170723205615.2C7AC5C41420@dd3332.kasserver.com 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 20170723205615.2C7AC5C41420@dd3332.kasserver.com 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=20170723205615.2C7AC5C41420@dd3332.kasserver.com,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.
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=20170723205623.1BEFC1016DC@server.fahrner.name Jul 23 22:56:23 server postfix/qmgr[5188]: 1BEFC1016DC: from=double-bounce@fahrner.name, 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=sparkasse@autolederfarbe.de, 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 sparkasse@autolederfarbe.de: 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 sparkasse@autolederfarbe.de: Sender address rejected: undeliverable address: host w00c4958.kasserver.com[85.13.129.212] said: 550 5.1.1 sparkasse@autolederfarbe.de: Recipient address rejected: User unknown in virtual alias table (in reply to RCPT TO command); from=sparkasse@autolederfarbe.de to=jf@fahrner.name 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=sparkasse@autolederfarbe.de to=jf@fahrner.name; 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=sparkasse@autolederfarbe.de to=jf@fahrner.name; 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=20170723205615.2C7AC5C41420@dd3332.kasserver.com 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 20170723205615.2C7AC5C41420@dd3332.kasserver.com 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=20170723205615.2C7AC5C41420@dd3332.kasserver.com,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
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
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
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 "sparkasse@autolederer.de". Wichtig ist denen, dass Wörter wie "Sparkasse" (oder was sie halt gerade abphishen wollen) möglichst oft auftaucht, damit man nicht mistrauisch wird.
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 "sparkasse@autolederer.de". 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)
Hallo Walter.
Walter H. - 24.07.17, 20:09:
Anders bei den Phishing-Betrügern, die wollen ja möglichst unentdeckt bleiben. Die erfinden dann so Absender wie "sparkasse@autolederer.de". 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)
Huch, und wer bemerkt dann, falls ein Server-Admin einen dieser Server auf eine andere IP oder einen anderen Hostnamen/Domain umzieht? Bei Ablehnung via Postscreen oder Ähnliches sehe ich das dann wenigstens im Log.
Nun, bei vielen Mailinglisten freier Software-Projekte würde ich das ja noch bemerken, aber bislang kam in meinen privaten Mailserver auch nicht soviel Mail rein, dass Postscreen oder selbst Postfix damit ernsthaft ins Schwitzen gekommen wäre und ich daher motiviert gewesen wäre zu IP-Tables zu greifen.
Und auch so… eine Whitelist aller Server, von denen ich Mail erwarte… das sind *Einige*. Ich denke, den Aufwand möchte ich mir nicht machen.
Adios,
On 24.07.2017 22:06, Martin Steigerwald wrote:
Hallo Walter.
Walter H. - 24.07.17, 20:09:
Anders bei den Phishing-Betrügern, die wollen ja möglichst unentdeckt bleiben. Die erfinden dann so Absender wie "sparkasse@autolederer.de". 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)
Huch, und wer bemerkt dann, falls ein Server-Admin einen dieser Server auf eine andere IP oder einen anderen Hostnamen/Domain umzieht?
wenn es wichtig ist, wirst Du es mitbekommen, ansonsten ist es unwichtig ...
Bei Ablehnung via Postscreen oder Ähnliches sehe ich das dann wenigstens im Log.
bei IPtables auch ..., ist nur ein anderer;
Nun, bei vielen Mailinglisten freier Software-Projekte würde ich das ja noch bemerken, aber bislang kam in meinen privaten Mailserver auch nicht soviel Mail rein,
bei meinem kam bis jetzt gar keine rein, aber tausende Versuche ihn als Relay zu mißbrauchen, welche damit auch abgestellt sind (auch Versuche via Port 80 udgl. etwas zu erreichen) ...
Und auch so… eine Whitelist aller Server, von denen ich Mail erwarte… das sind *Einige*. Ich denke, den Aufwand möchte ich mir nicht machen.
wie Du meinst ...
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 "sparkasse@autolederer.de". 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
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
On 24.07.2017 21:02, Joachim Fahrner wrote:
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.
eigentlich nur bei bestimmten Absenderdomains wie z.B. gmx, gmail, yahoo, ... macht es Sinn; und andere Absender sind entweder direkt hart gesperrt oder eben nicht;
Am 2017-07-24 21:16, schrieb Walter H.:
eigentlich nur bei bestimmten Absenderdomains wie z.B. gmx, gmail, yahoo, ... macht es Sinn;
Von da bekomme ich den allerwenigsten Spam. Was mir regelmässig durchrutscht sind so Exoten wie autolederer.de. Wie gesagt, bei mir kommt eigentlich nur noch Phishing durch, und das sind regelmässig ganz "unverbrauchte" Server von irgendwelchen Kleinfirmen (nicht nur DE, auch Italien war schon öfter dabei), die noch auf keinen Blacklists sind. Ich vermute mal, dass die da Mailaccounts hacken und für ihre Zwecke misbrauchen. Fire&Forget. Da kommt nie wieder ein zweites Mal was vom gleichen Server.
Am 24.07.2017 um 21:02 schrieb 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
eine typische Anwendung war zumindest frueher bei grossen Absender Domains nach vorgeschalteten checks ein sender verify fuer z.B yahoo, hotmail aber ich hab das abgeschafft weil es nicht viel brachte ob es heute noch zuverlaessig funktionieren wuerde oder sinnvoll waere bezweifle ich.
Ansonsten kann man solche Sonderfaelle konstruieren... wenn man z.B seine eigenen Mails ueber mehrere Relays routed und da nicht existierende Sender abfangen will ( weil warum auch immer kein anderes Verfahren moeglich ist ) Das Feature wird schlichtweg kaum gebraucht real....
Best Regards MfG Robert Schetterer
Ich vergesse immer auf Alle Antworten zu klicken :-(
Im Auftrag von Joachim Fahrner
Gesendet: Montag, 24. Juli 2017 19:37 An: postfix-users@de.postfix.org Betreff: Re: Microsoft ESMTP MAIL Service
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.
Dein Server wird bombadiert mit Absenderadressen 10000 Stück von 1000 unterschiedlichen Absender IP Adressen die alle als Domainanteil den Server von Robert haben Deine Software macht dann innerhalb von 10 Minuten 10000 Abfragen an Roberts server
Und das ist nicht aus der Luft gegriffen das sind Szenarien die einige hier schon erlebt haben Das ist dann der Zeitpunkt für LMAA und Postfix stop 5 Stunden warten, postfix start und schauen ob der Sturm verebbt ist
Dein Server verliert die Reputation mit dem Verify Und es gibt server und Mailsoftware die machen das über das verifykommando und versuchen eben keine Mail zu senden :-)
Und ja ich weis wie Postfix da arbeitet Und ja ich habe auch was gegen 10000 versuchte Mailzustellung konfiguriert :-) Und ja ich kenne sogar IPset und fail2ban :-)
Und du musst mit einem gewissen Bodensatz heute einfach leben The security is sitting between desk and chair Or you have an 30cm Problem :-)
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 "sparkasse@autolederer.de". Wichtig ist denen, dass Wörter wie "Sparkasse" (oder was sie halt gerade abphishen wollen) möglichst oft auftaucht, damit man nicht mistrauisch wird.
Das erledigen headerchecks schnell und unkompliziert
if /^From:.*Sparkasse.*/ if !/<.+@sparkassen(-).*..+>$/ /^/ REJECT fuck off, we go on strike and do not provide packages, Your Mailaccount was hacked endif endif
sollte bei obigem Beispiel greifen wenn nicht hat Robert sicher eine Idee :-)
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
* Joachim Fahrner jf@fahrner.name:
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 hat Recht. Dein Server macht reject_unverified_sender, DAS ist der Grund.
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)
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
Zitat von Robert Schetterer rs@sys4.de:
zu deutsch vergiss das einfach ,oder nutze es nur in Sonderfaellen
Oder nimm in Kauf das dir manche Leute die E-Mail nicht verstanden haben keine E-Mails schicken können. Das ist meistens sogar gut so.
Gruß
Andreas
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.
* Joachim Fahrner jf@fahrner.name:
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?
PRVS ist das. https://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation
Hallo Ralf,
Am 2017-07-25 15:56, schrieb Ralf Hildebrandt:
PRVS ist das. https://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation
Ok, hatte ich auch schon rausgefunden. Hab grad nochmal in deinem Buch nachgelesen, Kapitel 9.5.5 (envelope sender überprüfen). Das hat mich auf eine Idee gebracht: Die Mails, die nicht schon durch RBLs, Spamassassin, usw. geblockt werden, sind bei mir in der Regel Phishingmails. Und die haben ganz markante Wörter im Absender, "sicherheit", "sparkasse", "paypal" usw. In deinem Buch gibst du Beispiele, wie man über solche Keywords die Überprüfung triggern kann, somit könnte ich die glaube ich ganz gut selektiv anwenden.
Hat sich das Buch schon wieder gelohnt ;-)
Jochen
Am 25.07.2017 um 17:53 schrieb Joachim Fahrner:
Hallo Ralf,
Am 2017-07-25 15:56, schrieb Ralf Hildebrandt:
PRVS ist das. https://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation
Ok, hatte ich auch schon rausgefunden. Hab grad nochmal in deinem Buch nachgelesen, Kapitel 9.5.5 (envelope sender überprüfen). Das hat mich auf eine Idee gebracht: Die Mails, die nicht schon durch RBLs, Spamassassin, usw. geblockt werden, sind bei mir in der Regel Phishingmails. Und die haben ganz markante Wörter im Absender, "sicherheit", "sparkasse", "paypal" usw. In deinem Buch gibst du Beispiele, wie man über solche Keywords die Überprüfung triggern kann, somit könnte ich die glaube ich ganz gut selektiv anwenden.
das ist zumindest Mal vom Ansatz her eine gute Idee ! Allerdings wuerde ich es trotzdem erst weiter vorfiltern und mich nicht nur auf dieses adressen wording verlassen
aus dem Stand sehe ich da aber nur header checks mit postfix und die koennten an einen Transport uebergeben der dann sender verify macht schmeckt aber ein wenig nach einer zweiten postfix instance...
siehe
http://www.postfix.org/header_checks.5.html
in einem milter waere das aber evtl trivial muesste man mal den milter profi nach seiner Meinung fragen, ich denek mind einer liest mit *g
bzw ich bin mir ziemlich sicher dass es bereits milter gibt die solche Adressen triggern koennen und sender verification milter gibts ganz sicher dann koennte man den Filter Pfad mit milter manager bestimmen
zb
https://www.benzedrine.ch/milter-regex.html http://www.jmaimon.com/sendmail/callahead-milter/patches/callahead-milter.v0... https://milter-manager.osdn.jp/reference/introduction.html
erhebt jetzt alles keinen Anspruch auf absolute Richtigkeit nur schnell zusammengegoogelt
Hat sich das Buch schon wieder gelohnt ;-)
Jochen
Best Regards MfG Robert Schetterer
Am 25.07.2017 um 22:03 schrieb Robert Schetterer:
Am 25.07.2017 um 17:53 schrieb Joachim Fahrner:
Hallo Ralf,
Am 2017-07-25 15:56, schrieb Ralf Hildebrandt:
PRVS ist das. https://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation
Ok, hatte ich auch schon rausgefunden. Hab grad nochmal in deinem Buch nachgelesen, Kapitel 9.5.5 (envelope sender überprüfen). Das hat mich auf eine Idee gebracht: Die Mails, die nicht schon durch RBLs, Spamassassin, usw. geblockt werden, sind bei mir in der Regel Phishingmails. Und die haben ganz markante Wörter im Absender, "sicherheit", "sparkasse", "paypal" usw. In deinem Buch gibst du Beispiele, wie man über solche Keywords die Überprüfung triggern kann, somit könnte ich die glaube ich ganz gut selektiv anwenden.
das ist zumindest Mal vom Ansatz her eine gute Idee ! Allerdings wuerde ich es trotzdem erst weiter vorfiltern und mich nicht nur auf dieses adressen wording verlassen
aus dem Stand sehe ich da aber nur header checks mit postfix und die koennten an einen Transport uebergeben der dann sender verify macht schmeckt aber ein wenig nach einer zweiten postfix instance...
siehe
http://www.postfix.org/header_checks.5.html
in einem milter waere das aber evtl trivial muesste man mal den milter profi nach seiner Meinung fragen, ich denek mind einer liest mit *g
bzw ich bin mir ziemlich sicher dass es bereits milter gibt die solche Adressen triggern koennen und sender verification milter gibts ganz sicher dann koennte man den Filter Pfad mit milter manager bestimmen
zb
https://www.benzedrine.ch/milter-regex.html http://www.jmaimon.com/sendmail/callahead-milter/patches/callahead-milter.v0... https://milter-manager.osdn.jp/reference/introduction.html
erhebt jetzt alles keinen Anspruch auf absolute Richtigkeit nur schnell zusammengegoogelt
Hat sich das Buch schon wieder gelohnt ;-)
Jochen
Best Regards MfG Robert Schetterer
oder andere Idee du fischst sowas mit sieve heraus, der Vorteil da kannst du eine Menge ohne grossen Aufwand vorschalten z.B Domains fuer die du das machen willst, sieve kann externe scripts ausfuehren
Z.b swaks sollte dann eigentlich eine Adresse validieren koennen , ist das Resultat dann negativ sortierst du es in deinen Spam Ordner, das waere fuer den Empfaenger mehr save ,ausserdem kannst du noch einen Kommentar hinzufuegen z.B in den Betreff sowas wie validation failed etc schreiben.
Dass du damit andere nervst bleibt aber erhalten aber man koennte im script auch eine File DB mit vorher schon fehlgeschlagenen Ueberpruefungen anlegen ,die dann gleich in den Spam Ordner wandern.
Pflege braucht das aber auch , was aber ueber sieve editoren evtl einfach ist und man muss es nicht global machen sondern kann es per user implementieren.
Best Regards MfG Robert Schetterer
Am 2017-07-24 12:27, schrieb Joachim Fahrner:
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)
Das Rätsel ist gelöst: Der Server betreibt Greylisting mit einem Mindestabstand von 5 Minuten. Postfix versucht es per default alle 3 Sekunden nochmal, und das geht dem irgendwann auf den Senkel (Too many connections). Im Postfix kann man die Retry-Abstände erhöhen mit address_verify_poll_delay. Dann sollte das eigentlich klappen.
Jochen
participants (9)
-
Joachim Fahrner -
Lars Täuber -
lst_hoe02＠kwsoft.de -
Martin Steigerwald -
Ralf Hildebrandt -
Robert Schetterer -
Uwe Drießen -
Walter H. -
Walter H.