[Postfixbuch-users] welche blacklists?

So Nov 1 11:13:16 CET 2009

Hallo Paul,

"das ist seine Konfig" trifft inzwischen - nicht
zuletzt dank euerer Hilfe - nicht mehr zu.

Meine Konfig. in main.cf sieht derzeit so aus,
und ich wäre euch ehrlich dankbar, wenn ihr sie
noch einmal einer ernsthaften Kontrolle unterzöget:

[...]
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = no
readme_directory = no

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = 
btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

myhostname = mail.xxger.com
mydomain = xxger.com
default_database_type = btree
alias_maps = btree:/etc/aliases
alias_database = btree:/etc/aliases
virtual_alias_domains = btree:/etc/postfix/virtual_alias_domains
virtual_alias_maps = btree:/etc/postfix/virtual_alias_maps
myorigin = /etc/mailname
mydestination = $myhostname, $mydomain, localhost.$mydomain, 
localhost
relayhost =
mynetworks = 193.96.xxx.0/24 10.1.1.0/24 127.0.0.0/8 
[::ffff:127.0.0.0]/104 [::1]/128
# mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/
content_filter = smtp-amavis:[127.0.0.1]:10024
header_checks = pcre:/etc/postfix/header_checks-pcre
body_checks = pcre:/etc/postfix/body_checks-pcre

smtpd_recipient_restrictions =
   check_recipient_access 
btree:/etc/postfix/access_recipient_rfc-btree,
   check_client_access cidr:/etc/postfix/access_client-cidr,
   check_helo_access btree:/etc/postfix/access_helo-btree,
   check_helo_access cidr:/etc/postfix/access_helo-cidr,
   check_sender_access btree:/etc/postfix/access_sender-btree,
   check_recipient_access btree:/etc/postfix/access_recipient-btree,
   reject_non_fqdn_sender,
   reject_non_fqdn_recipient,
   reject_unknown_sender_domain,
   reject_unknown_recipient_domain,
   permit_sasl_authenticated,
   permit_mynetworks,
   reject_unauth_destination,
   reject_rbl_client ix.dnsbl.manitu.net,
   check_policy_service inet:127.0.0.1:12525,
   check_policy_service inet:127.0.0.1:60000,
   reject_unverified_recipient,
   permit

Ich habe also aufgrund euerer Ratschläge geändert:
- access_helo in IP- und Domain-Checks per cidr bzw. btree
- reject_unauth_dest. direkt nach den mynetworks und sasl_auth.
- (den Einwurf von Peer verstehe ich, nutze aber kein backup-mx)
- nur noch ein rbl-check: manitu _vor_ polw und grey

Ich weiß, dass das abschließende 'permit' überflüssig ist, aber 
ich finde es schön, so abzuschließen. ;-)

Wenn ihr bitte mal nach oben, in den allg. Teil schaut:
da habe ich
# mailbox_command = procmail -a "$EXTENSION"
auskommentiert.
Damit benutzt postfix wieder seine Standard-MDAs 'local' und
'virtual'.
Es kam mir so vor, als ob Courier-imap damit besser zurecht
käme als mit dem procmail-MDA. Liege ich da richtig, oder
verschenke ich damit einen mir unbakannten Vorteil von procmail?

Ich bin für jeden Verbesserungsvorschlag dankbar. :-)

Mit Pauls neuen Ergänzungen bzgl. smtpd_data_restrictions
möchte ich mich noch beschäftigen = nachlesen in postfix.org.

Viele Grüße und ein schönes Rest-WE

Norbert

PV schrieb:
> Alois Kratochwill schrieb:
>> Hi,
>> und nun wäre ein Musterbeispiel eurer Erkenntniss für uns alle von großem
>> Nutzen!
> Du meinst ein Musterbeispiel für 'warum ist es "besser"
> reject_unauth_destination vor den RBL Checks zu setzen'?
> 
> Nun ähm, also
> das ist seine Konfig:
> smtpd_recipient_restrictions =
>     check_client_access cidr:/etc/postfix/access_client,
>     check_helo_access btree:/etc/postfix/access_helo,
>     check_sender_access btree:/etc/postfix/access_sender,
>     check_recipient_access btree:/etc/postfix/access_recipient,
>     reject_nonfqdn_sender,
>     reject_nonfqdn_recipient,
>     reject_unknown_sender_domain,
>     reject_unknown_recipient_domain,
>     permit_sasl_authenticated,
>     permit_mynetworks,
>     reject_rbl_client zen.spamhaus.org,
>     reject_rbl_client ix.dnsbl.manitu.net,
>     reject_rbl_client bl.spamcop.net,
>     reject_rbl_client dnsbl.njabl.org,
>     recect_rbl_client list.dsbl.org,
>     reject_rhsbl_client blackhole.securitysage.com,
>     check_policy_service inet:127.0.0.1:12525,
>     check_policy_service inet:127.0.0.1:60000,
>     reject_unverified_recipient,
>     reject_unauth_destination,
>     permit
> 
> Und das würde ich daraus machen:
> smtpd_recipient_restrictions =
>     check_recipient_access btree:/etc/postfix/access_recipient-rfc,
>     check_client_access cidr:/etc/postfix/access_client,
>     check_helo_access btree:/etc/postfix/access_helo,
>     check_sender_access btree:/etc/postfix/access_sender,
>     check_recipient_access btree:/etc/postfix/access_recipient,
>     reject_nonfqdn_sender,
>     reject_nonfqdn_recipient,
>     reject_unknown_sender_domain,
>     reject_unknown_recipient_domain,
>     permit_sasl_authenticated,
>     permit_mynetworks,
>     reject_invalid_helo_hostname,
>     reject_unauth_destination,
>     reject_rbl_client ix.dnsbl.manitu.net,
>     check_policy_service inet:127.0.0.1:12525,
>     check_policy_service inet:127.0.0.1:60000,
>     reject_unverified_recipient
> smtpd_data_restrictions         =
>     reject_multi_recipient_bounce
>     warn_if_reject reject_unauth_pipelining
> 
> Soll heißen:
> Ich setze reject_unauth_destination direkt nachdem ganz klar ist, dass
> die Mail auslieferbar ist (also nach check_mumble_dings, fqdn,
> permit_bla) oder von meinen Leuten (sasl & mynetworks).
> Wenn die Mail bis hierhin noch nicht permittet wurde, ist fast sicher,
> dass die Mail von fremden stammt.
> Da ich keine kaputten Helo mag, setze ich es direkt danach ein. Kann
> sein, muss nicht. Der check kostet nichts und liefert wenig false positivs.
> Dann stellst du sicher, dass der Server bei der Mail weiß, dass die Mail
> auch für ihn bestimmt ist (reject_unauth_destination).
> Weil ich Manitus Liste sehr vertraue, setze ich den als harten reject ein.
> Anschliessend erst starte ich die spritverbrauchenden Motoren an und
> setze postgrey und polw ein.
> Wen die Mail das überlebt hat, dann wird erst wieder das
> wieder ressourcenverbrauchende Verifying gestartet. Am besten mit DB.
> z.B.
> address_verify_map      = btree:/var/lib/postfix/address_verify_map_DB
> Anschliessend noch ein paar andere kuriose aber sinnvolle Rejects
> (multi_recipient).
> 
> Alles klar?
> 
> Viele Grüße
> Paul
> 
> 
> 
> 
>> Danke,
>> Alois
>>
>>
>>
>>
>>
>>
>>
>> -------------------
>> Hi Paul,
>>
>> ja, wir denken in die selbe Richtung.
>> Du drückst es nur besser und richtiger aus.
>>
>> Viele Grüße
>>
>> Norbert
>>
>> PV schrieb:
>>
>>>> Ja, das meinte ich: man REJECTED hier alles, was nicht für die
>>>> eigenen Adressen gültig ist und vermeidet so, quasi intern noch
>>>> zum Spam-Verteiler zu werden?
>>>> Danke und freundliche Grüße
>>> Ich bin mir nicht ganz sicher, ob wir uns verstehen, daher hier noch ein
>>> paar Brainstorming Gedanken.
>>>
>>> So früh wie möglich, so spät wie nötig... würde ich
>>> reject_unauth_destination setzen, denn
>>> warum z.B. einen RBL Check durchführen, wenn klar ist, dass du sowieso
>>> nicht zuständig für die Zieldomain bist.
>>>
>>> Ich denke, wir denken schon in die richtige Richtung. :)
>>>
>>> Gruß,
>>> Paul
>>>
>>>> Norbert
>>> --
>>
>> --
>> _______________________________________________
>> Postfixbuch-users -- http://www.postfixbuch.de
>> Heinlein Professional Linux Support GmbH
>>
>> Postfixbuch-users at listen.jpberlin.de
>> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users
> --
> _______________________________________________
> Postfixbuch-users -- http://www.postfixbuch.de
> Heinlein Professional Linux Support GmbH
> 
> Postfixbuch-users at listen.jpberlin.de
> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users