Hallo,
exakt, an diesem Punkt ist es zu spät, bzw. wir sehen nur den
Benutzernamen und können nicht in den Header eingreifen.
Bei uns ist Webhosting so mit Wordpress, Joomla und Co verdichtet, dass
unser Standpunkt darauf basiert, auch die Mails von den eigenen
Kundenseiten nur noch über SMTP-Auth eingeliefert zu bekommen. Dies
erschlägt tatsächlich auch viele Spam-Versuche durch schnell
hochgeladene PHP-Bots oder ähnlich veranlagte Skripte und wir können
dank Logfile-Monitoring die Webseiten semi-automatisch bereits sperren
und den Kunden kontaktieren.
Das Limit muss natürlich so angepasst sein, so dass der einfache
perl-mailer oder der Cron-Report seine Mails durchbekommt, der dritte,
vierte, … Aufruf aber stecken bleibt. Ich habe auch unser sendmail
abgeändert, so dass es seine Einstellungen aus einer anderen
Konfigurationsdatei liest und wir die globalen Lese-Rechte von main.cf
entfernen können.
Über SMTP-Auth haben wir einen eigenen PolicyD in der
recipient_restrictions, der dann die Verbindung zwischen
Kunde(n)-Domains, Accounts und dem SASL-Benutzernamen herstellt und auch
entsprechend - hier nach Anzahl der Empfänger - individuell limitieren
kann. So können Newsletter ohne Probleme verschickt werden, das 100
mal gehackte Friseurstudio hingegen wird nach 15 Mails erstmal ein paar
Minuten aussetzen müssen.
Eine Zeitlang war übrigens dann der Spam-Klassiker, die Emails über
localhost:25 einzureichen. Seitdem schmeissen wir mynetworks
(127.0.0.0/8 und ::1 default) bzw. permit_mynetworks auch ganz raus.
Massen-Webhosting ist ein echter Spam-Schauplatz.
Grüße
Jörg
On 28 Jun 2016, at 11:47, [email protected] wrote:
Message: 3
Date: Tue, 28 Jun 2016 10:41:56 +0200
From: Florian Streibelt <[email protected]>
To: [email protected]
Subject: Re: Sendmail bei Massenmails blockieren
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Hmm,
ablehnen ist schon drastisch, zumal einige webtools Emails nur einmal
einliefern. Links zum Account aktivieren z.B. - ausserdem kann man
ohne diese Mails dem Kunden nicht sagen was da schief läuft, ob es
wirklich das WordPress ist oder nen anderes Script.
Ich würde ja als Vorstufe vor dem rejecten die Mails auf hold in der
Queue halten und erst nach einem weiteren Limit ablehnen...
Wird vermutlich in dem Stage aber nicht gehen in dem du bist?
Florian