[Postfixbuch-users] Spamwelle die dreihunderzweiundvierzigste?!

[Egon Gruber]

Eigentlich nicht. ich verwende für die RBLs den policyd-weight. Allerdings
> kommen 80% der Emails nicht soweit. Die meisten fliegen über dialip 
> Blockliste raus. Dann fallen viele über reject_unknown_client mit 450 raus. 
> Der policyd-weight und damit die RBLs kommen nicht allzu oft zum Einsatz.
>   
>> Wieviele smtpd sind denn bei dir simultan in Gebrauch wegen dieser
>> Zombies? Wieviele hast du als max gesetzt?
>>     
>
> zuerst hatte ich 100 smtpd laufen. Das hat zu normalen Zeiten dick gereicht. 
> Da lag das Maximum der parallel aktiven smtpd zwischen 80 und 790. 
> Heute bin ich über 300 nach 500 auf 1000 gegangen. Ich weiß, das Maximum der 
> parallel aktiven smtpd lag dann bei ca. 600. Ich habe das minütlich per ps 
> und grep ausgewertet und in ein File geschrieben. Allerdings habe ich die 
> Queues für Virenscanner und Spamchecks nicht größer gemacht. Eine Auswertung 
> des gestrigen Logs hat ergeben, das über 90% der Mails einfach raus fliegen 
> und gar nicht erst zum DATA kommen. Damit denke ich kann ich das riskieren, 
> die Maschine läuft ohne große Probleme mit akzeptabler Last. Im Monitoring 
> ist nichts zu erkennen, dass es zu problemen gekommen wäre
>   
Seit Montag habe ich dasselbe Problem. Gestern Vormittag und vor allem 
auch habe ich sehr viele Mailzustellungsversuche
von Clients, viele ohne PTR, viele aus Dial-In-Netzen.

Ich habe nun heute den Standartwert von smtdp von 100 anfangs auf 200, 
dann 300 und
nun schlussendlich auf 850 gesetzt, wobei nun glücklicherweise der Wert 
von 600
nur selten überschritten wird. Mit RAM-Speicherplatz und CPU habe ich 
keinerlei Probleme.

Jetzt läuft der SMTP Connect relativ ohne Probleme. Vorher war dieser 
extrem lansam
und zwischen Telnet und Helo dauerte es oft bis zu einer Minute oder 
mehr. So wurden auch
einige Mails verzögert zugestellt und unser Monitoringsystem hat immer 
wieder Alarm geschlagen,
dass der Mailservice (Port 25) nicht aktiv sei.

Denke das Hauptproblem ist, dass sehr viele Clients (unknown, aus 
DIAL-IN-Netzen) eine
Verbindung aufbauen und somit Ressourcen besetzen.

Einige diese Verbindungen werden bis zum Timeout von 300s aufrecht 
gehalten, obwohl
diese mittels RBL (554) sofort abgewiesen wurden. Somit besetzen diese 
Clients
für 300s (Standarteinstellung) den smtpd.

Logauszug eines Timeouts nach Abweisung mittels RBL.

Aug 30 11:57:04 artemide-b postfix/smtpd[4106]: NOQUEUE: reject: RCPT 
from unknown[88.235.74.34]: 554 Service unavailable; Client host 
[88.235.74.34] blocked using zen.spamhaus.org; 
http://www.spamhaus.org/query/bl?ip=88.235.74.34; 
from=<hubbubsnch1 at buffalo.edu> to=<aller at schule.suedtirol.it> 
proto=ESMTP helo=<[88.235.74.34]>
Aug 30 12:02:04 artemide-b postfix/smtpd[4106]: timeout after DATA from 
unknown[88.235.74.34]
Aug 30 12:02:04 artemide-b postfix/smtpd[4106]: disconnect from 
unknown[88.235.74.34]


Logauszug, wo der Client mittels RBL sofort abwiesen wird.

Aug 30 00:11:26 artemide-b postfix/smtpd[20636]: NOQUEUE: reject: RCPT 
from unknown[221.198.249.174]: 554 Service unavailable; Client host 
[221.198.249.174] blocked using sbl-xbl.spamhaus.org; 
http://www.spamhaus.org/query/bl?ip=221.198.249.174; 
from=<996laborslavebln at btinternet.com> to=<6stlunger at provinz.bz.it> 
proto=ESMTP helo=<[221.198.249.174]>
Aug 30 00:11:27 artemide-b postfix/smtpd[20636]: lost connection after 
DATA from unknown[221.198.249.174]
Aug 30 00:11:27 artemide-b postfix/smtpd[20636]: disconnect from 
unknown[221.198.249.174]


Wie ist es möglich, dass die Clients die Verbindung nicht abbauen bwz. 
muss Postfix warten bis der Client die Meldung 554 erhalten hat,
damit die Verbindung abgebaut wird?

Wie kann man dem Problem am besten entegenwirken?

Auszug main.cf

smtpd_recipient_restrictions =
                reject_non_fqdn_recipient,
                reject_non_fqdn_sender,
                reject_unknown_sender_domain,
                reject_unknown_recipient_domain,
                permit_mynetworks,
                reject_unauth_destination,
                check_recipient_access hash:/etc/postfix/recipient_checks,
                check_sender_access hash:/etc/postfix/sender_checks,
                reject_rbl_client sbl-xbl.spamhaus.org,
                reject_rbl_client korea.services.net,
                reject_rbl_client zen.spamhaus.org,
                check_sender_access    
hash:/etc/postfix/rhsbl_sender_domain_exceptions,
                reject_rhsbl_sender dsn.rfc-ignorant.org,

Servus,
Egon