Konfiguration DNSBL V.19

[hase]

Hallo,
aktuell habe ich in der main.cf folgenden Block für die dnsbl zu stehen:

smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_multi_recipient_bounce,
reject_unauth_destination,
reject_rbl_client ix.dnsbl.manitu.net,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client dul.dnsbl.sorbs.net

In der neusten KH-Version können nun ja die DNSBL Einträge eingefügt werden.
Wenn ich die dnsbl nun dort einfüge, existieren diese doch doppelt in der main.cf
Wie bzw. was sollte ich vornehmen, das es keine Konflikte gibt?

[Alexander]

Da brauchst du dir keine Sorge machen, trage einfach die 3 Blacklisten in das entsprechende Feld im KeyHelp ein und der Eintrag wird korrekt gesetzt.
Anschließend kannst du natürlich gern noch einmal die Datei kontrollieren, ob alles nun deinen Vorstellungen entspricht.

(KeyHelp verwendet "postconf" zur Aktualisierung der Konfiguration, welcher wiederum sicherstellt, das Einträge korrekt in der main.cf gespeichert werden)

[hase]

Da brauchst du dir keine Sorge machen, trage einfach die 3 Blacklisten in das entsprechende Feld im KeyHelp ein und der Eintrag wird korrekt gesetzt.
Anschließend kannst du natürlich gern noch einmal die Datei kontrollieren, ob alles nun deinen Vorstellungen entspricht.

(KeyHelp verwendet "postconf" zur Aktualisierung der Konfiguration, welcher wiederum sicherstellt, das Einträge korrekt in der main.cf gespeichert werden)

Ja, die Einträge werden gesetzt, habe ich eben getestet. Aber mein o.g. Block bleibt auch weiterhin in der main.cf enthalten, also irgendwie alles doppelt dann

[Alexander]

Dann lösche die von dir ursprünglich erstellten Einträge und überlasse KeyHelp das managed der Einstellung.

Wenn du irgendwann weitere Einträge für "smtpd_recipient_restrictions" ergänzen möchtest, kannst du das auch tun. KeyHelp respektiert die bereits vorhandenen Einstellungen für diesen Parameter und aktualisiert nur die Blacklist/Whitelist Einstellungen.

[hase]

@Alexander,

also ich habe das jetzt mal über 24h lang getestet.
Laut Logfiles wird so gut wie nichts mehr geblockt, nur vereinzelt noch.
Vorher bei den manuellen einträgen wie oben von mir beschrieben, funktionierte alles einwandfrei.

Was ist eigentlich der Unterschied von "smtpd_recipient_restrictions" zu "smtpd_client_restrictions" ?
Kann es vielleicht damit was zu tun haben?

[Jolinar]

Was ist eigentlich der Unterschied von "smtpd_recipient_restrictions" zu "smtpd_client_restrictions" ?

Schau dir mal diesen Beitrag an. Da werden die einzelnen Restrictions ziemlich gut erklärt.

Edit:
Zum Thema Blocklisten auch sehr lesenswert: Klick mich

[hase]

@Alexander,

also ich habe das jetzt mal über 24h lang getestet.
Laut Logfiles wird so gut wie nichts mehr geblockt, nur vereinzelt noch.
Vorher bei den manuellen einträgen wie oben von mir beschrieben, funktionierte alles einwandfrei.

Was ist eigentlich der Unterschied von "smtpd_recipient_restrictions" zu "smtpd_client_restrictions" ?
Kann es vielleicht damit was zu tun haben?

Hallo nochmal,
also habe es den ganzen Tag über auf 2 verschiedene Server laufen lassen. Es wird definitiv so gut wie nichts mehr geblockt
Nur wenn ich die Einträge, wie vorher, manuell eintrage funktioniert es wie es sein soll.

Ob es daran liegt das KH die Einträge in der main.cf in einer Zeile schreibt weiss ich nicht...
Irgendwie stimmt da was nicht.

[derFu]

@Alexander,

also ich habe das jetzt mal über 24h lang getestet.
Laut Logfiles wird so gut wie nichts mehr geblockt, nur vereinzelt noch.
Vorher bei den manuellen einträgen wie oben von mir beschrieben, funktionierte alles einwandfrei.

Was ist eigentlich der Unterschied von "smtpd_recipient_restrictions" zu "smtpd_client_restrictions" ?
Kann es vielleicht damit was zu tun haben?

Die smtpd_recipient_restrictions werden nach den smtpd_client_restrictions abgearbeitet.

Wenn Du die Blacklists vorher in den smtpd_client_restrictions hattest, ist es eigentlich logisch, dass jetzt weniger geblockt wird. Diese *_restrictions werden meine ich in der Reihenfolge

-smtpd_client_restrictions
-smtpd_helo_restrictions
-smtpd_sender_restrictions
-smtpd_recipient_restrictions

abgearbeitet.

Jetzt hast du die "reject_rbl_client"-Einträge in den smtpd_recipient_restrictions, deshalb wird nur noch geblockt, was die vorherigen noch passiert konnte

Ob es daran liegt das KH die Einträge in der main.cf in einer Zeile schreibt weiss ich nicht...
Irgendwie stimmt da was nicht.

Eher nicht. Die Doku sagt

Specify a list of restrictions, separated by commas and/or whitespace.

http://www.postfix.org/postconf.5.html# ... strictions

[hase]

@Alexander,

also ich habe das jetzt mal über 24h lang getestet.
Laut Logfiles wird so gut wie nichts mehr geblockt, nur vereinzelt noch.
Vorher bei den manuellen einträgen wie oben von mir beschrieben, funktionierte alles einwandfrei.

Was ist eigentlich der Unterschied von "smtpd_recipient_restrictions" zu "smtpd_client_restrictions" ?
Kann es vielleicht damit was zu tun haben?

Die smtpd_recipient_restrictions werden nach den smtpd_client_restrictions abgearbeitet.

Wenn Du die Blacklists vorher in den smtpd_client_restrictions hattest, ist es eigentlich logisch, dass jetzt weniger geblockt wird. Diese *_restrictions werden meine ich in der Reihenfolge

-smtpd_client_restrictions
-smtpd_helo_restrictions
-smtpd_sender_restrictions
-smtpd_recipient_restrictions

abgearbeitet.

Jetzt hast du die "reject_rbl_client"-Einträge in den smtpd_recipient_restrictions, deshalb wird nur noch geblockt, was die vorherigen noch passiert konnte

Hi,
die vorherigen dnsbl-Einträge bei "smtpd_client_restrictions" habe ich logischer weise doch entfernt, so das nur die neuen Einträge von KH enthalten sind.

[Jolinar]

@hase: Kannst du mal die Ausgabe von

Code: Select all

cat /etc/postfix/main.cf

posten? Den Wert für myhostname kannst du entfernen/anonymisieren.

[hase]

@hase: Kannst du mal die Ausgabe von

Code: Select all

cat /etc/postfix/main.cf

posten? Den Wert für myhostname kannst du entfernen/anonymisieren.

Bitteschön

myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

## Turning off the backwards-compatibility safety net
## http://www.postfix.org/COMPATIBILITY_README.html
compatibility_level = 2

## appending .domain is the MUA's job.
append_dot_mydomain = no

## uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

## max mailsize in byte
message_size_limit = 36700160

## TLS parameters
smtpd_use_tls = yes
smtpd_tls_auth_only = yes

smtpd_tls_cert_file = /etc/ssl/keyhelp/mail.pem
smtpd_tls_key_file = /etc/ssl/keyhelp/mail.pem
smtpd_tls_CAfile = /etc/ssl/keyhelp/mail-ca.crt
smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
smtp_tls_protocols = !SSLv2 !SSLv3
smtpd_tls_protocols = !SSLv2 !SSLv3

smtp_tls_security_level = may
smtpd_tls_security_level = may

## TLS cypher for PFS
smtp_tls_mandatory_ciphers = high
smtpd_tls_mandatory_ciphers = high
## medium for now, otherwise breakes with older SMTP
smtp_tls_ciphers = medium
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem

## Dovecot Settings for deliver, SASL Auth and virtual transport
## uncomment those line to use Dovecot
mailbox_command = /usr/lib/dovecot/deliver

#dovecot_destination_recipient_limit = 1
#transport_maps = hash:/etc/postfix/transport
mailbox_transport = dovecot

smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

myhostname = xxxxxxxxxxx.de
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = localhost, $myhostname
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

## handing off local delivery to Dovecot's LMTP, and telling it where to store mail
virtual_transport = lmtp:unix:private/dovecot-lmtp
#virtual_transport = dovecot

## virtual domains, users, and aliases
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

## spam filter
content_filter = amavis:127.0.0.1:10024

## concerning the peer
smtpd_soft_error_limit = 5
smtpd_error_sleep_time = 10s

smtpd_helo_required = yes

smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_multi_recipient_bounce,
reject_unauth_destination

smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
# check_helo_access regexp:/etc/postfix/helo_access,
reject_invalid_hostname,
reject_non_fqdn_hostname

## concerning the envelope
smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unauth_destination,
reject_unknown_sender_domain,
reject_unknown_client,
reject_non_fqdn_hostname

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_recipient, check_policy_service unix:private/policy, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client cbl.abuseat.org, reject_rbl_client bl.blocklist.de, reject_rbl_client b.barracudacentral.org
# check_policy_service inet:127.0.0.1:10023

smtpd_recipient_limit = 50
smtpd_recipient_overshoot_limit = 50

## header checks
header_checks = regexp:/etc/postfix/header_checks
milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:127.0.0.1:12345
non_smtpd_milters = inet:127.0.0.1:12345

[derFu]

@Alexander,

also ich habe das jetzt mal über 24h lang getestet.
Laut Logfiles wird so gut wie nichts mehr geblockt, nur vereinzelt noch.
Vorher bei den manuellen einträgen wie oben von mir beschrieben, funktionierte alles einwandfrei.

Was ist eigentlich der Unterschied von "smtpd_recipient_restrictions" zu "smtpd_client_restrictions" ?
Kann es vielleicht damit was zu tun haben?

Die smtpd_recipient_restrictions werden nach den smtpd_client_restrictions abgearbeitet.

Wenn Du die Blacklists vorher in den smtpd_client_restrictions hattest, ist es eigentlich logisch, dass jetzt weniger geblockt wird. Diese *_restrictions werden meine ich in der Reihenfolge

-smtpd_client_restrictions
-smtpd_helo_restrictions
-smtpd_sender_restrictions
-smtpd_recipient_restrictions

abgearbeitet.

Jetzt hast du die "reject_rbl_client"-Einträge in den smtpd_recipient_restrictions, deshalb wird nur noch geblockt, was die vorherigen noch passiert konnte

Hi,
die vorherigen dnsbl-Einträge bei "smtpd_client_restrictions" habe ich logischer weise doch entfernt, so das nur die neuen Einträge von KH enthalten sind.

Moin!

Hatte ich verstanden. Du schreibst, es wird im Vergleich zu früher weniger blockiert. Und Du hast nach dem Unterschied zwischen client_restrictions und recipient_restrictions gefragt.

Ich bin davon ausgegangen, dass Du die Zahlen der DNSBL-Blocks früher/jetzt isoliert vergleichst. Ich zum Beispiel habe auf einem Server insgesamt bei gleichen Voraussetzungen nicht mehr Spam, aber weniger Rejects durch Blacklists, dafür mehr durch andere Restrictions.

Ein Spammer hat nicht zwingend nur das Merkmal "Blacklisteintrag", sondern mehrere, und wird dann ggf. jetzt vor den Blacklists von anderen rejects geblockt, die bei Deiner alten Konf nicht mehr zum Zuge kamen. Von Restriction zu Restriction, von reject zu reject werden es nach unten hin weniger Mails, also am Ende der Kette sind es weniger Mails, die durch reject_rbl_client geblockt werden müssen.

Wenn Du jetzt also isolierst schaust, wie viele von den DNSBL-Einträgen geblockt werden, müssen es weniger sein.

Nehmen wir an, in Deiner vorherigen Konf hast Du 900 Mails durch die reject_rbl_client-Einträge in client_restrictions geblockt.
Gleich am Anfang. Diese Mails haben die anderen Restrictions gar nicht mehr durchlaufen.

Jetzt sind diese reject_rbl_client-Einträge drei Restrictions später, in recipient_restrictions.

Von den ehemals 900 Blacklist-geblockten aus Deiner vorherigen Konf bleiben jetzt

- nur noch 50 bei client_restrictions (jetzt ja ohne Blacklists)
- 300 bei helo_restrictions, z.B. bei "reject_invalid_hostname"
- 100 bei sender_restrictions, z.B. bei "reject_unknown_sender_domain"
- 100 in den anderen Rejects bei recipient_restrictions außer den Blacklist

hängen und werden rejected, bevor die Blacklist-Rejects drankommen.

Bleiben für die Blacklists Am Ende noch 900-50-300-100-100=350 zum Blockieren übrig, statt der 900 von früher.

Oder nochmal anders: wenn Du die Zahlen der reject_rbl_client-Abweisungen von früher und jetzt vergleichst, musst Du zeitgleich auch schauen, ob die Zahlen anderer Rejects höher geworden sind.

Darauf wollte ich hinaus.

[Jolinar]

Bitteschön

Hmm...syntaktisch ist alles in Ordnung.
Was mir aber aufgefallen ist...In deinem Startpost sind andere BL angegeben als die aktuell in deiner Config eingetragenen. Ich kann jetzt allerdings nichts zu der Qualität der neu verwendeten BL von blocklist.de und barracudacentral.org sagen, weil ich keine der beiden selber nutze.
Rein aus Neugier: In deiner manuellen Config hast du noch die BL von sorbs.net verwendet, warum ist die in deiner aktuellen Config weggefallen?

[hase]

Bitteschön

Hmm...syntaktisch ist alles in Ordnung.

Rein aus Neugier: In deiner manuellen Config hast du noch die BL von sorbs.net verwendet, warum ist die in deiner aktuellen Config weggefallen?

Hi,
die sorbs habe ich entfernt da diese mit barracuda fast gleichwertig ist.