interessante Erkenntnis zu 'smtpd_delay_reject'

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

interessante Erkenntnis zu 'smtpd_delay_reject'

Walter H.
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


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

Re: interessante Erkenntnis zu 'smtpd_delay_reject'

Patrick Ben Koetter-2
* Walter H. <[hidden email]>:
> mit der Einstellung
> smtpd_delay_reject = no
> ist es unmöglich, sich am submission-Port mit UserId/Password zu
> authentifizieren;

Diese Aussage ist falsch.

Richtig ist: Wenn Du eine policy hast, die Filter auf MUAs anwendet, noch
bevor sie sich authentifizieren können, dann haben sie keine Chance sich
*vorher* von allen anderen abzuheben und so privilegiert von diesen Filtern
ausgenommen zu werden.

Aus diesem Grund habe ich auch vor mehreren Jahren eigene mua_*_restrictions
angeregt, die Wietse auch in das template der master.cf übernommen hat.

In diesen mua_*_restrictions kannst Du Regeln setzen, die submission-Clients
privilegiert. Ich empfehle folgende Logik:

1. Erzwinge TLS
2. Nimm die Nachricht nur an, wenn sie transportfähig ist
3. Prüfe auf abuse-Szenarien
4. Nimm die Mail an wenn der Client erfolgreich authentifiziert werden konnte
5. Prüfe die Nachricht auf Malware
6. Prüfe die Nachricht auf Spam
7. Transportiere die Nachricht oder bounce sie an den Absender

p@rick




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



--
[*] sys4 AG
 
https://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, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein