interessante Erkenntnis zu 'smtpd_delay_reject'

[Walter H.]

Hallo,

mit der Einstellung
smtpd_delay_reject = no



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


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

ist es unmöglich, sich am submission-Port mit UserId/Password zu authentifizieren; und damit funktioniert die Authentification am submission-Port und SPAM-Clients /etc/postfix/drop.cidr kommt von hier: http://www.spamhaus.org/drop/drop.lasso

(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:




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

/etc/postfix/client_access.cidr beinhaltet Netzwerkblöcke, denen ich den Zugriff verweigere 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;

smime.p7s
Description: S/MIME Cryptographic Signature