[Postfixbuch-users] gezielter gegen Spam vorgehen, aber wie?

Matthias Haegele mhaegele at linuxrocks.dyndns.org
Di Mai 2 14:12:20 CEST 2006


Matthias Haegele schrieb:
> Rainer Wiesenfarth schrieb:

[...]
>> Verwendest Du auch Greylisting? Ich weiß, ist nicht ganz unumstritten

> btw:
> ist "einfacher" ohne mysql einzusetzen

das bezog ich im kontext auf greylisting (address_verify ist leichter 
einzusetzen als ...)

> Grüsse & hth

Habe mal eine ein bisschen kommentierte postconf -n angehängt:
Achtung vieeeeeel Text ;-):

> MH > hermes:~# postconf -n
Cache für address_verify:
> address_verify_map = btree:/var/spool/postfix/verified_senders
> append_dot_mydomain = no

Mailadressen nicht auf Gültigkeit bestätigen lassen:
> disable_vrfy_command = yes
> mime_header_checks = pcre:/etc/postfix/mime_header_checks

> smtpd_data_restrictions = reject_multi_recipient_bounce
> smtpd_helo_required = yes
> smtpd_recipient_restrictions = permit_mynetworks,     

Verschiedene Prüfungen u. a. auch z.B. clients verbieten den 
Servernamen/IP des Mailservers im helo/ehlo zu verwenden ...:
(Bei Unklarheit: 
http://www.postfix.org/postconf.5.html#Name_der_restiction/Parameter)
permit_sasl_authenticated,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unauth_destination,
reject_unauth_pipelining,
reject_invalid_hostname,
check_helo_access pcre:/etc/postfix/helo_checks
check_sender_mx_access cidr:/etc/postfix/bogus_mx
reject_rbl_client relays.ordb.org
check_recipient_access hash:/etc/postfix/roleaccount_exceptions,
reject_rhsbl_sender dsn.rfc-ignorant.org
reject_unknown_sender_domain
reject_unverified_sender
permit

> smtpd_sasl_auth_enable = yes
> smtpd_sasl_local_domain =
> smtpd_sasl_security_options = noanonymous

Böse Clients ausbremsen:
> smtpd_soft_error_limit = 5
 > smtpd_error_sleep_time = 5s
 > smtpd_hard_error_limit = 15

Kann man "hart" rejecten, da temporäre (z.B. DNS-Auflösungsfehler) mit 
450er Code zurückgegeben werden ...:
> unverified_sender_reject_code = 550 >

Die Maps auf die in main.cf verwiesen wird:
cat /etc/postfix/helo_checks
> /^hermes\.linuxrocks\.dyndns\.org$/     550 Dont use my hostname go away
> /^213\.239\.199\.112$/                  550 Dont use my IP Address go away
> /^\[213\.239\.199\.112\]$/              550 Dont use my IP Address go away
> /^[0-9.]+$/                     550 Your client is not RFC 2821 compliant

aus dem Buch übernommen ob das noch aktuell ist k.A.:
> cat /etc/postfix/bogus_mx
> #spam havens
> 69.6.0.0/18     550 REJECT Listed on Register Of Known Spam Operations
> # wild-card MTA
> 64.94.110.11/32 550 REJECT Verisgin Domain Wildcard (feels responsible for all# bogus networks
> 0.0.0.0/8       550 Mail server in broadcast network
> 10.0.0.0/8      550 No route to your RFC 1918 network
> 127.0.0.0/8     550 Mail server in loopback network
> 224.0.0.0/4     550 Mail server in multicast network
> 192.168.0.0/16  550 No route to your RFC 1918 network
> 172.16.0.0./12  550 No route to your private network

Gefährliche Attachments blocken:

hermes:~# cat /etc/postfix/mime_header_checks
# By mh from Postfixbook
#
# Files blocked by their suffix
/name=\"(.*)\.(386|bat|bin|chm|cmd|cmd|com|do|exe|hta|jse|lnk|msi|ole)\"$/
         REJECT Unwanted type of attachment $1.$2
/name=\"(.*)\.(pif|reg|rm|scr|shb|shm|shs|sys|vbe|vbs|vxd|xl|xsl)\"$/
         REJECT Unwanted type of attachment $1.$2


Das ist nur als Beispiel gedacht und funktioniert bei mir so, muss aber 
nicht "der Weisheit letzter Schluss sein" und kann für andere 
Szenarionen deshalb gänzlich ungeeignet sein ...





Mehr Informationen über die Mailingliste Postfixbuch-users