July 2018 - postfix-users

interessante Erkenntnis zu 'smtpd_delay_reject'
by Walter H. 30 Jul '18

30 Jul '18

Hallo, mit der Einstellung smtpd_delay_reject = no ist es unmöglich, sich am submission-Port mit UserId/Password zu authentifizieren; hab dann in der master.cf folgendes submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject und damit funktioniert die Authentification am submission-Port und SPAM-Clients werden bereits verabschiedet bevor noch ein MAIL FROM kommt; meine main.cf hat das smtpd_delay_reject_submission = yes smtpd_delay_reject = no smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_unknown_helo_hostname, reject_non_fqdn_helo_hostname, reject_rhsbl_helo rhsbl.sorbs.net, check_helo_mx_access cidr:/etc/postfix/drop.cidr, check_helo_ns_access cidr:/etc/postfix/drop.cidr, permit smtpd_client_restrictions_submission = permit_sasl_authenticated, reject smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, reject_unknown_client_hostname, reject_unknown_reverse_client_hostname, reject_rbl_client cbl.abuseat.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client noptr.spamrats.com, reject_rbl_client dyna.spamrats.com, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, check_client_access hash:/etc/postfix/client_access, check_client_access cidr:/etc/postfix/client_access.cidr, permit smtpd_sender_restrictions = reject_unknown_sender_domain, reject_non_fqdn_sender, reject_rhsbl_sender rhsbl.sorbs.net, check_sender_mx_access cidr:/etc/postfix/drop.cidr, check_sender_ns_access cidr:/etc/postfix/drop.cidr, check_sender_access hash:/etc/postfix/sender_access, permit smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, check_policy_service unix:private/policy-spf, check_recipient_access hash:/etc/postfix/recipient_access, reject smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_etrn_restrictions = permit_mynetworks, reject /etc/postfix/drop.cidr kommt von hier: http://www.spamhaus.org/drop/drop.lasso /etc/postfix/client_access.cidr beinhaltet Netzwerkblöcke, denen ich den Zugriff verweigere (z.B. alle Netze welche über spf.protection.outlook.com aufgelöst werden) /etc/postfix/sender_access beinhaltet Absender, die ich ablehne (z.B. alle Länder-TLDs bis auf ein paar handverlesene, ebenso Freemail-Domains wie hotmail.com, yahoo, ...) /etc/postfix/recipient_access beinhaltet alle meine Mailaliase mittels Header-Checks noch ein paar Besonderheiten: z.B. Mails in einem Zeichensatz, den ich nicht verstehe (Alle bis auf: US-ASCII, UTF-8, ISO-8859-1(5)) d.h. ein SPAM/Malware-Sender muss sich wirklich bemühen, damit bei mir was durchkommt; ein Eintrag wie dieser Jul 20 22:47:42 vhost01 postfix/cleanup[19994]: CF5C94140B: reject: mime-error improper use of 8-bit data in message header: Subject: Bitte best??tigen Sie Ihre Anmeldung zum Newsletter from mail1.verkehrsbuero.com[213.33.97.21]; from=<#SPAM-SENDER#> to=<#MY-EMAIL#> zeigt mir, daß ich mit strict_8bitmime = yes strict_7bit_headers = yes strict_8bitmime_body = yes ebenfalls nichts falsch mache; Grüße, Walter

2 1

Nur XCLIENT als Authentifizierung-Methode
by Hativ 27 Jul '18

27 Jul '18

Hallo, ist es möglich als Authentifizierung-Methode nur XCLIENT zu erlauben und nur das (für autorisierte Clients) als ESMTP Feature zu propagieren? Ich habe folgendes konfiguriert: smtpd_authorized_xclient_hosts = 123.123.123.123 smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous, noplaintext "smtpd_sasl_auth_enable = yes" muss gesetzt sein, damit XCLIENT funktioniert. Damit werden immer diverse Authentifizierungsmethoden angeboten. Diese habe ich weiter mit "smtpd_sasl_security_options" eingeschränkt. Aktuell wird damit noch "DIGEST-MD5 CRAM-MD5 NTLM" angeboten. Wenn ich es versuche weiter einzuschränken, z.B. mit der Aufnahme von "nodictionary", wirft Postfix bei der ersten Verbindung folgende Fehler und stürzt ab: Jul 27 00:07:17 srv1 postfix/smtpd[15340]: warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms Jul 27 00:07:17 srv1 postfix/smtpd[15340]: fatal: no SASL authentication mechanisms Jul 27 00:07:18 srv1 postfix/master[15322]: warning: process /usr/lib/postfix/sbin/smtpd pid 15340 exit status 1 Jul 27 00:07:18 srv1 postfix/master[15322]: warning: /usr/lib/postfix/sbin/smtpd: bad command startup -- throttling Ich möchte aber nur XCLIENT propagiert haben, ansonsten keine Authentifizierung. Grüße

2 1

transport statt pipe(8) oder local(8)..?
by Christian Bricart 19 Jul '18

19 Jul '18

Hallo zusammen, irgendwie scheine ich gerade nen Knoten im Hirn zu haben .. ;-) Wenn der Weg ein Skript über pipe(8) oder local(8) delivery agent weiter zu verarbeiten ist, ich das aber gerne über einen transport regeln/"prefixen" würde, weil das besser in's bestehende Setup passt... wie würde ich das dann tun..? Also bspw wäre der "normale" Weg: # main.cf: virtual_alias_maps = hash:/etc/postfix/virtual # /etc/postfix/virtual: thisuser(a)example.com forwarduser # /etc/aliases: forwarduser: "|/usr/local/bin/doforward someuser(a)example.net " Das ist aber insofern unflexibel, als dass ich für jede Zieladresse Adresse einen eigenen Alias anlegen müsste, der sich dann im Argument für den Parameter des aufzurufenden Skripts unterscheidet.. Ergo würde ich daraus gerne einen "forwarder-transport" machen, der Art: # /etc/postfix/virtual: thisuser(a)example.com forwarder:someuser@example.net # master.cf: # mit forwarder_destination_recipient_limit=1 in main.cf ? forwarder unix - n n - - pipe user=nobody argv=/usr/local/bin/doforward ${nexthop} Nach der Lektüre von transport(5) dürfte ${nexthop} aber nicht die Form einer Mailadresse annehmen? Oder jemand andere/bessere Vorschläge..? Grüsse Christian

2 1

SMTPUTF8 is required, but was not offered by host
by Thomas Barth 05 Jul '18

05 Jul '18

Hallo, meine Testmails werden nicht zugestellt, sobald ich in der Betreffzeile ein Umlaut verwende (UTF-8). Ich verwende für Testmails ein Perl-Skript mit dem Modul MIME::Lite. Aus dem Log: Jul 5 09:18:07 mx1 postfix/lmtp[16338]: C50F2481BC6: to=<tbarth(a)txbweb.de>, relay=mx1.txbweb.de[private/dovecot-lmtp], delay=511, delays=511/0.02/0.02/0, dsn=4.6.7, status=SOFTBOUNCE (SMTPUTF8 is required, but was not offered by host mx1.txbweb.de[private/dovecot-lmtp]) Über die Suche fand ich einen Hinweis dazu auf dieser Seite https://github.com/hardware/mailserver/issues/166 Hier wurde folgende Einstellung vorgenommen: smtputf8_enable = yes smtputf8_autodetect_classes = sendmail, verify Dies habe ich in /etc/postfix/main.cf eingetragen und Postfix neu gestartet. Das Problem besteht weiterhin. Nun habe ich gesehen (http://www.postfix.org/postconf.5.html#smtputf8_autodetect_classes), dass das eigentlich Standardeinstellungen von Postfix sind. Und was kann ich jetzt tun? Und vor allem, wo hängen meine Testmails und wie kann ich sie löschen? mailq listet nichts in der Queue auf, aber es wird regelmäßig versucht, die Testmails noch zuzustellen. Postfix Version ist 3.1.8-0+deb9u1. Gruß, Thomas B.

3 6