Was machen mit Spam Hinweisen an Postmaster?


NM78

NM78

New Member
Hallo, seit einem Serverumzug bekomme ich ständig Hinweise weil E-Mails wegen Spam von dritten gelöscht wurden.

Ich habe einen Kunden auf meinem Server der seine E-Mails vom Server an seinen T-Online E-Mailaccount umleiten lässt. Falls der Kunde Spam bekommen, dann blockiert T-Online die E-Mails und sendet sie an [email protected] mit einem entsprechenden Hinweis zurück.

Auf Dauer nervt das natürlich. Was sollte man da am besten machen?
 
Dem Kunden sagen, er soll seinen Spamfilter in T-Home ausmachen
oder die Mails sauber vorfiltern, damit die Weiterleitungen nicht mehr schiefgehen.
 
NM78 said:
... sendet sie an [email protected] mit einem entsprechenden Hinweis zurück.
Click to expand...

T-Online sendet die E-Mails nicht zurück, sondern lehnt die E-Mail direkt ab, woraufhin dein MTA den Hinweis sendet.

NM78 said:
Was sollte man da am besten machen?
Click to expand...

Ich habe das gleiche Problem und bin auch noch am überlegen.

Theoretisch dürfte es möglich sein, den MTA anzuweisen, die eingehende E-Mail nur dann anzunehmen, falls sie sich sofort weiterleiten lässt, also von T-Onlines MX nicht abgewiesen wird. Das läuft aber dem sonst üblichen asynchronen Charakter der E-Mail Zustellung zuwider, kommt daher also nicht wirklich in Betracht.

Besser wäre es, die E-Mails, die der eigene MTA als Spam erkennt, gar nicht erst weiterleiten zu lassen. Allerdings stellt sich dann die Frage, was man mit den E-Mails machen soll, falls man keine externe (außerhalb des Postfachs) Quarantäne hat. Löschen ist halt nur dann eine Option, falls die von T-Online abgelehnten E-Mails eine sehr hohe Score erzielen und demnach fast sicher Spam sind und daher gefahrlos gelöscht werden können.
 
Schon mal die abgelehnten Mails gecheckt? Wenn es sich wirklich um Spam handelt solltest du eher bei deinem Server ansetzen anstatt dem Kunden zu sagen dass er Spam annehmen soll weil dich die Bounces nerven.
Bei andauernder Weiterleitung von Spam ist es nämlich nur eine Frage der Zeit bis Provider dich als Spammer einstufen und Mails von deinem Server komplett ablehnen.

Hast du überhaupt Maßnahmen ergriffen um deine Kunden vor Spam zu schützen? Greylisting wäre z.B. sehr zu empfehlen, hat bei mir Wunder gewirkt (bei meinem Hauptaccount von 100-200 Spam Mails/Tag runter auf etwa 5-10/Woche). Des Weiteren wäre der Einsatz von DNSBLs/RBLs sehr sinnvoll (die von spamcop.net und spamhaus.org z.B.).
 
Vielen Dank für Eure Hilfe. Ich habe jetzt seit einem halben Tag Graylisting für den gesamten Server aktiviert und es scheint wirklich den gewünschten Effekt zu bringen.

Bin schon sehr gespannt wie es sich in den nächsten Tagen auswirkt. Bisher Spam=0, Fehlermeldungen wegen Spam=0.

:)
 
killerbees19 said:
Egal welche RBL, nur nicht spamhaus.org! ;)
Click to expand...

Hm, also mit XBL und DBL fahre ich eigentlich ganz gut, noch keinerlei Probleme aufgetreten. Muss dir allerdings bei der SBL Recht geben, wenn ich diese verwende kann ich keine Mails mehr versenden weil meine IP einer dynamischen Range angehört....was schon sehr unpraktikabel ist.
 
Sagt mal kann es sein, dass E-Mails die von PHP Scripten automatisch verschickt werden (z.B. ein Statusscript, das Nachts durchläuft) durch das Graylisting nicht mehr ankommen?
 
Eigentlich nNur, wenn das PHP-Script die Mails per SMTP verschickt und nicht per mail()-Funktion über das lokale sendmail-(Wrapper-)Binary
 
Oder das "sendmail-(Wrapper-)Binary" gehört zu einem MTA, der keine Queue hat. Beispiele dafür dürften ssmtp und esmtp sein. Dann müsste das PHP-Skript allerdings auf einem anderen Server laufen. Auf deinem Mailserver hast du ja sicher einen vollwertigen MTA mit Queue laufen.

Falls das Skript auf dem gleichen Server läuft, dann solltest du dir vielleicht die Konfiguration deines MTA nochmals anschauen. Bei der sollte man es so einstellen können, dass lokal kein Greylisting gemacht wird. Beispielsweise bei postfix:

Code: 
mynetworks = 127.0.0.0/8, .......
smtpd_recipient_restrictions =
        permit_mynetworks,
        ............
        #Greylisting
        check_policy_service inet:127.0.0.1:60000
 
You must log in or register to reply here.

Back
Top