Re: Dovecot Sasl | Auth not enabled
Am 20.02.2019 um 14:27 schrieb Stefanie Leisestreichler:
Am 20.02.19 um 14:08 schrieb Alex JOST:
Am 20.02.2019 um 12:53 schrieb Stefanie Leisestreichler:
Hallo. Ich benutze Dovecot Sasl und bekomme diese Fehlermeldung:
regular_text: Out: 220 mx18.mxtest.example.de regular_text: In: EHLO 130.180.70.238 regular_text: Out: 250-mx18.mxtest.example.de regular_text: Out: 250-PIPELINING regular_text: Out: 250-SIZE 10240000 regular_text: Out: 250-VRFY regular_text: Out: 250-ETRN regular_text: Out: 250-STARTTLS regular_text: Out: 250-ENHANCEDSTATUSCODES regular_text: Out: 250-8BITMIME regular_text: Out: 250-DSN regular_text: Out: 250 SMTPUTF8 regular_text: In: AUTH LOGIN regular_text: Out: 503 5.5.1 Error: authentication not enabled regular_text: regular_text: Session aborted, reason: lost connection
Es fehlen bei der Rückmeldung des MX beim Connect jegliche Angaben wie AUTH-250 LOGIN, usw., obwohl ich die folgenden Sasl-Parameter benutze:
# SASL smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous # zeigt "250-AUTH=..." zusätzlich zu "250-AUTH ..." ohne =, bspw. für Outlook bis Version 2003: broken_sasl_auth_clients = yes smtpd_sasl_local_domain = example.de
Um welchen Port geht es hier?
Der Telnet war auf Port 25.
OK, ich hatte vermutet es ginge um Port 587. Für Port 587 werden die Einstellungen von main.cf meistens in der master.cf überschrieben.
Hast Du ein 'postfix reload' ausgeführt, nachdem Du smtpd_tls_auth_only = no' gesetzt hast?
PS: AUTH auf Port 25 ist eigentlich keine gute Idee. Wenn möglich immer einen eigenen Port dafür benutzen.
Am 20.02.19 um 14:45 schrieb Alex JOST:
PS: AUTH auf Port 25 ist eigentlich keine gute Idee. Wenn möglich immer einen eigenen Port dafür benutzen.
Das mache ich gerne so, wie Du es vorschlägst. Ich nehme an, Du meinst ich soll statt dessen Port 587 verwenden, oder?
Gerne würde ich auch verstehen, warum Du das empfiehlst. Würdest Du mir das ggfs. kurz erläutern oder einen Link zu einer entsprechenden Doku senden?
Danke, Steffi
Am 20.02.2019 um 15:32 schrieb Stefanie Leisestreichler:
Am 20.02.19 um 14:45 schrieb Alex JOST:
PS: AUTH auf Port 25 ist eigentlich keine gute Idee. Wenn möglich immer einen eigenen Port dafür benutzen.
Das mache ich gerne so, wie Du es vorschlägst. Ich nehme an, Du meinst ich soll statt dessen Port 587 verwenden, oder?
Genau. Port 587 ist inzwischen der Standardport für einliefernde MUAs.
Gerne würde ich auch verstehen, warum Du das empfiehlst. Würdest Du mir das ggfs. kurz erläutern oder einen Link zu einer entsprechenden Doku senden?
Patrick hat es im Wesentlich gut erklärt, aber das strikte Trennen von MTAs und MUAs hat nicht nur den Vorteil, dass man beim einen die Verschlüsselung erzwingen kann, während man beim anderen auch unverschlüsselte Verbindungen zulässt. Es erlaubt Dir generell unterschiedliche Konfigurationen für einliefernde Server und Deine Benutzer zu nutzen.
Die wichtigsten Punkte sind für mich: * unterschiedlich starke Verschlüsselung * DNSBLs (z.B. mit Postscreen) * Ratelimiting
Wichtig ist aber nur das im Vorfeld schon klar zu trennen. Die Benutzer dazu zu bewegen die Einstellungen nachträglich in allen Geräte zu ändern kostet sehr viel Mühe und Zeit.
Am 20.02.19 um 17:05 schrieb Alex JOST:
Die wichtigsten Punkte sind für mich:
- unterschiedlich starke Verschlüsselung
- DNSBLs (z.B. mit Postscreen)
- Ratelimiting
Vielen herzlichen Dank, auch für diesen Hinweis. Auch das werde ich - so wie von Dir vorgeschlagen - 1:1 umsetzen. Da habe ich noch einiges zu lesen, scheint mir...
Steffi
* Alex JOST jost+lists@dimejo.at:
Am 20.02.2019 um 15:32 schrieb Stefanie Leisestreichler:
Am 20.02.19 um 14:45 schrieb Alex JOST:
PS: AUTH auf Port 25 ist eigentlich keine gute Idee. Wenn möglich immer einen eigenen Port dafür benutzen.
Das mache ich gerne so, wie Du es vorschlägst. Ich nehme an, Du meinst ich soll statt dessen Port 587 verwenden, oder?
Genau. Port 587 ist inzwischen der Standardport für einliefernde MUAs.
Gerne würde ich auch verstehen, warum Du das empfiehlst. Würdest Du mir das ggfs. kurz erläutern oder einen Link zu einer entsprechenden Doku senden?
Patrick hat es im Wesentlich gut erklärt, aber das strikte Trennen von MTAs und MUAs hat nicht nur den Vorteil, dass man beim einen die Verschlüsselung erzwingen kann, während man beim anderen auch unverschlüsselte Verbindungen zulässt. Es erlaubt Dir generell unterschiedliche Konfigurationen für einliefernde Server und Deine Benutzer zu nutzen.
Die wichtigsten Punkte sind für mich:
- unterschiedlich starke Verschlüsselung
- DNSBLs (z.B. mit Postscreen)
- Ratelimiting
Genau. Die Trennung von MUA -587-> MSA und MTA -25-> MTA gestattet unterschiedliche Policies. Ich setze zusätzlich noch smtpd_delay_reject = no auf Port 25, weil ich dort nicht auf fehlerhaft implementierte MUAs mehr Rücksicht nehmen muss.
Auf großen Plattformen mache ich das nicht, solange ich mir das Ressourcentechnisch erlauben kann. Da lasse ich die Spammer lange in die Session reinrennen, damit die Tools viel über den Spammer lernen können. Das hilft bei Auswertungen typische Merkmale von Spammern zu erkennen. Würde ich sie sofort rejecten wäre der Lerngewinn geringer.
Wichtig ist aber nur das im Vorfeld schon klar zu trennen. Die Benutzer dazu zu bewegen die Einstellungen nachträglich in allen Geräte zu ändern kostet sehr viel Mühe und Zeit.
Für die Konfiguration von MUAs empfehle ich https://automx.org. Das macht es für Endanwender einfach, ihr Mailprogramm zu konfigurieren. Spart Zeit, man kann "seine" sichere policy einfach durchsetzen und entlastet den Support erheblich.
p@rick
Am 20.02.19 um 17:05 schrieb Alex JOST:
Die wichtigsten Punkte sind für mich:
- unterschiedlich starke Verschlüsselung
- DNSBLs (z.B. mit Postscreen)
- Ratelimiting
Bezüglich Ratelimiting... Wäre die folgende Konfiguration ein passabler Ansatz?
#========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) #========================================================================== slow unix - - N - 1 smtp
/etc/postfix/transport example.org slow:
slow_destination_recipient_limit = 1 slow_destination_concurrency_limit = 2
Am 21.02.2019 um 21:08 schrieb Stefanie Leisestreichler:
Am 20.02.19 um 17:05 schrieb Alex JOST:
Die wichtigsten Punkte sind für mich:
- unterschiedlich starke Verschlüsselung
- DNSBLs (z.B. mit Postscreen)
- Ratelimiting
Bezüglich Ratelimiting... Wäre die folgende Konfiguration ein passabler Ansatz?
#========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) #========================================================================== slow unix - - N - 1 smtp
/etc/postfix/transport example.org slow:
slow_destination_recipient_limit = 1 slow_destination_concurrency_limit = 2
Damit ändert sich nur die Geschwindigkeit mit der Postfix Nachrichten an andere Server verschickt. Ich meinte Ratelimiting für eingehende Nachrichten (z.B. mit rspamd oder postfwd).
Am 22.02.19 um 09:50 schrieb Alex JOST:
Ich meinte Ratelimiting für eingehende Nachrichten (z.B. mit rspamd oder postfwd).
Danke für den hilfreichen Hinweis, Alex. Bei meinen Recherchen hierzu sah ich, dass Du, wie auch Patrick, wohl den rspamd bevorzugst. Den werde ich mir dann auch einmal genauer ansehen...
LG Steffi
participants (3)
-
Alex JOST -
Patrick Ben Koetter -
Stefanie Leisestreichler