# Rate limiting outgoing emails



## Wh1sper (20. Feb. 2013)

Einer der Hauptgründe in letzter Zeit, irgendwelche Server zu hacken, ist die einfache Möglichkeit via php mailer spamm Nachrichten zu verschicken.
Hat man sich so einen ungebetenen Gast eingefangen klettern binn weniger Stunden die bounce emails in die Höhe und man landet mit seiner Serverip auf Blocklisten.
Eine Idee, die Attraktiviät für die Spammer erheblich zu verringern ist, die Zeit zu verlängern, die zwischen den einzelnen zu sendenden emails zu verlängern.
Eine Möglichkeit das umzusetzen ist hier Rate limit outgoing emails from PHP web applications using postfix and policyd | Into.the.Void.
beschrieben.
Man setzt einen zweiten postfix auf, der nur auf eingehen localhost Verbindungen lauscht und die langsam in Häppchen an den eigentlichen site postfix weitergibt.
*Meine Fragen*, hat das jemand erfolgreich umgesetzt?
Oder gibt es eine einfache Möglichkeit es nur mit dem site postfix zu bewerkstelligen?
Bei uns würde eine generelle Begrenzung auch  funktionieren, weil wir nicht so viele email nutzer haben.


----------



## Till (21. Feb. 2013)

Ich finde das setup recht aufwändig für diesen Zweck. Du kannst ja in der php.ini den Pfad zum sendmail binary angeben, das muss aber nicht sendmail sein sondern kann ein beliebiges anderes script sein, z.B. ein email logging script wie ich es vor längerem mal für debugging Zwecke auf einem Kunden server geschrieben hatte:

How To Log Emails Sent With PHP's mail() Function To Detect Form Spam | HowtoForge - Linux Howtos and Tutorials

Du könntest also dieses oder ein ähnliches script nehmen und es so erweitern dass es Emails mit Verzögerung oder Mengenbegrenzung weiter gibt. Z.b. so in der Art dass Du die die Anzahl der Emails die von einer Seite pro Stunde gesendet werden zählst und aus diesem Wert dann eine Verzögerung bei der weitergabe an sendmail berechnest.


----------



## Wh1sper (21. Feb. 2013)

Ja, die Idee gefällt mir 
Werde ich gleich mal heute Abend umsetzen.
Hat noch den charme, das man unerwünschte Nutzer gleich automatisch erkennen könnte.


----------



## Wh1sper (21. Feb. 2013)

Merkwürdig.
Ohne ispconfig im standard wheezy funktioniert funktioniert die Lösung.

Auf meine produktiven Umgebung mit ipc 3.046 nicht.
Mail geht weiterhin, das wrapperscript wird nicht gezogen.
Aufruf auf terminal mit php geht.
apache ist restartet, alle in Frage kommenden php.ini sind angepasst.

In den Vhost Einträgen ist zum Teil sendmail_path auf /usr/bin/sendmail gesetzt. Das würde ich verstehen, wenn es nicht ginge, auf es geht auch auf sites nicht, die keinen solchen Eintrag haben.

Ich habe jetzt einfach einen wrapper für sendmail geschrieben, das geht dann auch, wenn der direkte pfad genommen wird. 
Edith sagt: Nee, keine Dauerlösung, es gibt zuviele Nebenschauplätze, also nur im K-Fall einsetzbar


----------



## Till (21. Feb. 2013)

Dann steht der Eintrag möglicherweise in der falschen php.ini Datei bzw. Du verwendest custom php.ini settings und dast die webseite nicht aktualisiert, so dass Deine Änderungen in der globalen php.ini nicht auf die custom php.ini der Webseite übertragen wurden.


----------



## Wh1sper (21. Feb. 2013)

Nee, so einfach ist das nicht.
Ich habe im Blog (serendipity) einen Kommntar geschrieben, die Benachrichtigung kommt über den Wrapper rein.
aus gpEasy heraus (hatte ich eben immer als Test genutzt), funkioniert es nicht, der benutzt mail über eine php class.
Bei meinem Debian ist mail auf /usr/bin/heirloom-mailx gelinkt (über alternatives)
Das binary benutzt /usr/lib/sendmail welches wiederum ein Link auf /usr/sbin/sendmail ist
[CODEcd ]/usr/lib#
 ll sendmail 
lrwxrwxrwx 1 root root 16 Jul 29  2012 sendmail -> ../sbin/sendmail
# rm sendmail 
# ln -s /usr/local/bin/phpsendmail sendmail
# ll sendmail 
lrwxrwxrwx 1 root root 26 Feb 21 19:47 sendmail -> /usr/local/bin/phpsendmail
[/code]
Leider half das auch nicht, die 



> Software: PHPMailer - PHP email class                                    |
> |   Version: 5.2.1                                                          |
> |      Site: https://code.google.com/a/apache-extras.org/p/phpmailer/       |
> | ------------------------------------------------------------------------- |
> ...


Unternimmt allerlei Versuche die Mail loszuwerden und schafft es irgendwie um die Wrapper rumzukommen.
(Für weitergehende Untersuchungen habe ich nicht das php Wissen und auch nicht so richtig Zeit und Lust.)
Denn eigentlich ist der Wrapper zwar ganz gut, aber ein böses Script, --wenn man ein Script untergeschoben bekommen hat -- hat ja alle Möglichkeiten und könnte vor der Spam Lawine erst untersuchen, welche Methoden denn möglich ist.

Aber vielen Dank für die Unterstützung, ich habe auch im Master und allen vhosts übrigens die sendmail_path angepasst, aber wie man sieht ist es nicht 100%
Vielleicht probiere ic doch mal die verlinkte postfix * 2 Lösung


----------

