SPAM Verdacht

[harv]

kein problem ;)

ok also wenn du jetzt die mail.info beobachtest

tail -f /var/log/mail.info

wird dir auffallen das wenn jemand eine mail versendet folgende zeile auftaucht

Nov 19 15:57:07 delta spamdyke[18814]: ALLOWED from: harv@domain.tld to: irgdwo@insnetz.tld origin_ip: 8X.1X3.1X6.X0 origin_rdns: i5XXX7e50.XXXXXXXXX.tld auth: harv

habe mal die relevanten teile hervorgehoben

damit kannst du dann genau sehen wer mit welchem absender an wen sendet und so hinterher anhand dieser daten auch feststellen wer hier spamt

(ich hab mir für diese meldungen zusätzlich noch ein separates log angelet, wenn du das auch möchtest sag bescheid dann sag ich dir wie das geht)

[ALADIN1]

Also ich habe in der mail.info noch nichts verdächtiges finden können. Es sind viele Meldungen wie "DENIED_RDNS_MATCH" oder "DENIED_IP_IN_CC_RDNS".

Aber nach einem Tag Funktionslauf habe ich ein Problem festgestellt. Über einer Domain hängt ein MS Exchange-Server drann und ruft die Mails ab. Jetzt können aber keine Mails mehr verschickt werden. Folgende Fehlermeldung hat man mir weitergeleitet :

hxxxxxxx.stratoserver.net #554 Refused. Your reverse DNS entry contains your IP address and a country code. ##

Ursprüngliche Nachrichtenkopfzeilen:

Received: from server.EVERYONE.local ([192.168.178.1]) by
server.EVERYONE.local ([192.168.178.1]) with mapi; Fri, 20 Nov 2009 10:50:06
+0100
From: Beate Mustermann <Beate.Mustermann@Domain1.de>
To: "'heidemann@Domain2.de'" <heidemann@Domain2.de>
Date: Fri, 20 Nov 2009 10:50:04 +0100
Subject:
Thread-Index: AcppxtW+tUiWTM7ESOaE5VGhf2+t8Q==
Message-ID: <9DD372FF3280B342B820A6C4D6E064699A6BB2FD@server.E VERYONE.local>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: multipart/alternative;
boundary="_000_9DD372FF3280B342B820A6C4D6E064699A6 BB2FDserverEVERYONEl_"
MIME-Version: 1.0

[harv]

und von solchen servern hast du zuvor mails angenommen? (Windows Server und mailen mit der aussen welt....naja)

ich behaupte jetzt mal ganz frech der könnte der verdächtige sein (da wenn die nichtmal wissen wie man einen mailserver korrekt konfiguriert ist warscheinlich mit der firewall auch nicht so doll....)

aber ok, genug "aufgeregt".

Lösung ist ganz einfach:
Die Lösung ist für den fall das es ein externer Kontakt ist und kein versand über den Server stattfindet sondern nur von der domain eingeht

wenn du meine spamdyke.conf genommen hast dann solltest du eine whitelist für sender haben

sender-whitelist-file=/var/qmail/spamdyke/whitelist_senders

wenn nicht einfach die zeile mit einfügen und die datei anlegen (rechte wie spamdyke.conf) in der datei schreibst du nun einfach

@domain.tld
@domain2.tld

somit sind die beiden domains auf der whitelist und werden von spamdyke ignoriert


Wenn das jedoch kunden von dir sein sollten und die einen account bei dir haben dann sag denen die sollen ihren server so konfigurieren das er sich mit smtp-auth bei deinem server anmeldet. (kannst natürlich auch die whitelist Lösung benutzen aber eigendlich sollten die schon in der lage sein ihre server richtig zu konfigurieren und falls das wirklich die spammer sein sollten dann ist das die beste lösung weil du dann eindeutig und anhand vom verwendeten benutzernamen nachweisen kannst das bei denen was nicht ok ist und ich denk mal nicht das du große lust hast auf einer der großen spamlisten zu landen...ausserdem kann wenn dein server vermieter das mitbekommt deinen vertrag FRISTLOS kündigen!![steht eigendlich bei jedem in den AGBs])

*KOPFSCHÜTTEL*

[ALADIN1]

... hab die gleiche Meinung wie du zu Windows-Servern.

Ich hab die Domain in die Whitelist mal eingetragen, hab aber noch keine Rückmeldung erhalten ob`s jetzt funktioniert. Werde mich mit dem Administrator nochmal unterhalten, wegen den ihrer Servereinstellungen.

Ich hab aber nochmal einen Auszug der Logfiles mit gepostet (mail.info).
@harv: Es wäre nett, wenn du nochmal ein Auge drauf werfen könntest.
Danke im voraus.

Gruß Markus

Edit: Logfile gelöscht !

[harv]

also das logfile sieht soweit ok aus habe aber noch eine frage

info@domain13 ist das eine weiterleitung an irgendwas@t-online.de ?

und dann macht mich folgendes noch stutzig

Nov 21 13:04:03 h1385255 qmail: 1258805043.562470 starting delivery 35903: msg 2262414 to remote synopticdg@worldatlas.com
Nov 21 13:04:03 h1385255 qmail: 1258805043.562695 status: local 0/10 remote 1/20
Nov 21 13:04:03 h1385255 qmail-remote-handlers[10455]: Handlers Filter before-remote for qmail started ...
Nov 21 13:04:03 h1385255 qmail-remote-handlers[10455]: from=
Nov 21 13:04:03 h1385255 qmail-remote-handlers[10455]: to=synopticdg@worldatlas.com
Nov 21 13:04:03 h1385255 qmail: 1258805043.749401 delivery 35903: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/
Nov 21 13:04:03 h1385255 qmail: 1258805043.749506 status: local 0/10 remote 0/20

da ist kein passendes allowed zuvor gelaufen, das sieht nach einem script auf dem server aus, vorallem ist es ohne absender was eigendlich ein bounce wäre, es ist aber nichts von der domain eigegangen also dürfte auch kein bounce zurückgehen.

Das gleiche hier

Nov 21 13:04:35 h1385255 qmail: 1258805075.748214 starting delivery 35904: msg 2262333 to remote augustbetts@fds.com
Nov 21 13:04:35 h1385255 qmail: 1258805075.748335 status: local 0/10 remote 1/20
Nov 21 13:04:35 h1385255 qmail-remote-handlers[10490]: Handlers Filter before-remote for qmail started ...
Nov 21 13:04:35 h1385255 qmail-remote-handlers[10490]: from=
Nov 21 13:04:35 h1385255 qmail-remote-handlers[10490]: to=augustbetts@fds.com

und das hier ist noch merkwürdiger

Nov 21 13:06:42 h1385255 qmail-remote-handlers[10652]: Handlers Filter before-remote for qmail started ...
Nov 21 13:06:42 h1385255 qmail-remote-handlers[10652]: from=
Nov 21 13:06:42 h1385255 qmail-remote-handlers[10652]: to=alex_075@210-84-63-239.dyn.iinet.net.au

aber sonst soweit ok. Dein server (bzw. deine User) wurde aber ganz schön zugespammt! Ich denke mal das deine kunden sich wundern werden warum plötzlich nur noch wenig bis gar kein spam mehr durchkommt....

[ALADIN1]

info@domain13.de ist tatsächlich eine Weiterleitung an eine t-online eMail-Adresse

Ich selbst habe viel spam an meine eMail-Adressen bis vor kurzem bekommen, hab das aber local ausgefiltert. Was mich noch wundert, in den Logfiles erscheinen eMail-Adressen (als Absender oder Empfänger), die schon nicht mehr existieren und ich vielleicht schon vor einem Jahr auf dem Server gelöscht habe.

Bei den eigenartigen Einträgen kann es sich vielleicht um php-Formulare handeln, da habe ich einige einfache laufen. Die werde ich mal bei Gelegenheit durch ein besseres Script ersetzen.

Hoffe ich kann mich bei sorbs.net jetzt wieder austragen lassen.

Danke nochmal für Deine Hilfe :-)

[harv]

Was mich noch wundert, in den Logfiles erscheinen eMail-Adressen (als Absender oder Empfänger), die schon nicht mehr existieren und ich vielleicht schon vor einem Jahr auf dem Server gelöscht habe.

Das liegt daran das die Spammer diese noch auf ihren listen haben. (und als trick benutzen sie auch ab und zu solche absender adressen)

Hoffe ich kann mich bei sorbs.net jetzt wieder austragen lassen.

Dann chec sicherheits halber aber auch die anderen listen

[ALADIN1]

Sorbs.net will für das austragen aus ihrer Liste 50US$ und das empfinde ich als etwas unverschämt.

Nun habe ich gesehen, das ich ja noch eine zweite IP-Adresse in meinem Serverpaket bei Strato habe. Wenn ich nun einfach die IP-Adresse des Servers wechsle, muss ich dabei noch was beachten ? Also das ändern/eintragen in Plesk und den Nameservern ist klar, aber müssen irgendwelche Sachen über die Konsole geändert werden ? - hab im Forum nichts dazu gefunden, und bevor ich wieder unheil anrichte :-)

[harv]

hmm wäre eine Idee.

(ich gehe jetzt mal davon aus das die zweite IP soweit eingerichtet ist)

Also zunächst würde ich dir zum umbennen des Servernamens raten (nicht das du dadürch wieder auf der Blacklist landest). Dann musst du den PTR richtig auf den neuen Server namen setzten und kontrollieren, sowie einen entsprechenden A Eintrag im DNS vornehmen so das der Server in beide Richtungen aufgelöst werden kann.

So jetzt kommt der lässtige Teil du musst alle MX Einträge (wenn du nicht einen zentralen MX Eintrag eingerichtet hast, wovon ich fasst ausgehe, das würde ich dir raten in dem zuge gleich mit zu machen) auf die neue IP ändern (also den entsprechenden A Eintrag ändern).

So nun sieht es zumindest nach aussenhin nach einem neuen Server aus, jetzt musst du noch Qmail davon überzeugen nur noch die 2. Adresse zum versenden zu benutzen.


Zunächst musst du dir die Qmail-Sourcen, z. B. von qmail mirror selection herunterladen.
Danach die Plesk-Patches von Parallels (auf die richtige Version achten!) und dann den outgoingip.patch von qmail.

Qmail downloaden

cd /usr/local/src
wget http://www.qmail.org/qmail-1.03.tar.gz

Die Patches für Plesk 9.2 downloaden, falls du eine andere Version hast eine Liste mit den Patches findest du hier KB Parallels: Parallels Plesk Panel uses patched Qmail. How do I compile Qmail with my own patches? (ganz am Ende)

wget http://kb.parallels.com/Attachments/806/Attachments/plesk92_qmail_patches.tgz

Dann die Pakete entpacken

tar xvfz qmail-1.03.tar.gz
tar xvfz plesk92_qmail_patches.tgz

Outgoing-IP-Patch downloaden

wget http://qmail.org/outgoingip.patch /usr/local/src/files/

So nun die Plesk-Patches anwenden

cd qmail-1.03
for d in ../files/patch*; do patch <”$d”; done

outgoingip.patch anwenden

for d in ../files/outgoingip.patch; do patch <”$d”; done

Edit der conf-spawn
Danach die Datei conf-spawn editieren (theroretisch muss hier eine 509 oder weniger eingeben werden – falls das bei dir nicht so sein sollte und due etwas anderes eingeben musst, wird dir das im Kompilierungsvorgang mitgeteilt).

Datei conf-spawn mit einem Editor (hier vi du kannst auch einen anderen nehmen) öffnen und anpassen

vi conf-spawn

So nun hast du es fasst geschaft jetzt noch das SSL-File erstellen

echo “-lssl -lcrypto” >> ssl.lib

conf-users und conf-groups editieren
Die Dateien conf-users und conf-groups müssen editiert werden. Das machen die folgenden Befehle für dich

grep -E ‘^(qmail|alias)’ /etc/passwd | awk ‘BEGIN {FS=”:”; OFS=” “;} {if ($1 == “qmaill”) {print $1,$3,”\nroot 0″} else {print$1,$3}}’ > conf-users
grep -E ‘^(qmail|nofiles)’ /etc/group | awk ‘BEGIN {FS=”:”; OFS=” “;} {print $1,$3}’ > conf-groups

So nun Kompilieren (nur make, kein ./configure und auch kein make install!)
make


Als nächstes AUF KEINEN FALL `make install`ausführen, da bereits installierte Konfigurationsdateien und init-Skripte unangerührt bleiben sollten.

Nach dem Kompilieren von Qmail und DrWeb musst du vom Plesk-Panel aus die beiden stoppen (nicht von der shell).
xinitd stoppen (diemal über die shell).

So jetzt die benötigten Dateien in das qmail-Verzeichnis kopieren (und ein Backup von den originalen anlegen):

cp /var/qmail/bin/qmail-remote.origin /var/qmail/bin/qmail-remote.origin_
cp /var/qmail/bin/qmail-remote /var/qmail/bin/qmail-remote_

cp /var/qmail/bin/qmail-remote /var/qmail/bin/qmail-remote.origin
cp qmail-remote /var/qmail/bin/qmail-remote

Dann noch den benutzer / gruppe entsprechend der vorher vorhandenen qmail-remote anpassen.

chown mhandlers-user.popuser /var/qmail/bin/qmail-remote

Jetzt noch die Outgoing IP festlegen

echo GEWÜNSCHTE_IP > /var/qmail/control/outgoingip

Qmail, DrWeb und xinitd neustarten und alles sollte vernünftig laufen.

Du darfst nicht vergessen nach jedem Plesk update zu kontrollieren ob deine veränderten dateien ersetzt wurden (anhand des änderungs Datum, eventuell auch einen Hash erzeugen und dann vergleichen) und dann den Vorgang erneut zu wiederholen (dann darauf achten das du die richtigen Qmail-Plesk-Patches nimmst^^).

So nachdem ich jetzt 30min daran geschrieben habe hoffe ich nicht das du mir sagst das ist dir zu viel aufwand und du zahlst lieber die 50$.

Dann solltest du auf jeden Fall kontrollieren egal ob du es machst oder nicht ob rausbekommst wer der verantwortliche Spammer ist. (Von dem kannst du dann die 50$ [würde ich mindestens Netto und in €] zurückverlangen und die ip wieder freischalten lassen.

[ALADIN1]

danke Dir erstmal für die ausführliche Beschreibung - und keine Angst, ich habe nicht vor die 50US$ an sorbs zu zahlen :-).

Soweit ich aus deiner Beschreibung aber herausgelesen habe, ändere ich ja "nur" die IP-Adresse für das versenden von Mails - also in den Einstellungen in Qmail. Ich wollte eigentlich das der Server komplett über die neue IP erreichbar ist. Ich denke das müßte (sorry, aber) wesentlich einfacher sein ?! Den vollen Zugriff auf den bzw. die DNS-Server habe ich (sind nicht bei STRATO). Dort kann ich über ein Templete die IP-Adressen für alle Domains auf einmal ändern.

[harv]

naja das ist an sich ganz einfach nur halt lästige handarbeit weil du jedem kunden die neue ip zuordnen musst (ist natürlich auch ne variante) einfach die neue ip per plesk einfügen alle domains umziehen (im Plesk und per dns) und die andere anscliessend im plesk löschen

achso das mit dem ptr und dem server namen würde ich dir trotzdem anraten

[ALADIN1]

Es ist langsam zum Wahnsinnig werden :-(

Ein user hat Mailkontakt mit einer amerikanischen Firma. Leider verarbeiten die (oder ihr Provider) keine rDNS-Anfragen. Dadurch stehen die ankommenden Mails im Logfile mit der Fehlermeldung "DENIED_RDNS_RESOLVE" und werden zurück gewiesen. Ich habe in der whitelist_rdns schon den Eintrag "@domain.com" gemacht, aber die Mails gehen trotzdem nicht durch ?

[harv]

dann geh mal in die spamdyke.conf und lösch den entsprechenden eintrag (obwohl mich wundert das die nicht mit allen großen providern probleme haben)

[ALADIN1]

das wollte ich eigentlich vermeiden, aber wenn`s gar nicht anders geht.
Aber warum funktioniert das mit der whitelist nicht ? Die Domain hab ich eingetragen.
Muss ich vielleicht irgendwas noch neu starten ?

Hab noch einen Fehler gefunden: in der mail.err kam die Meldung das die Datei recipient-whitelist nicht existiert. Da hatte ich einen Schreibfehler (recipient_whitelist) in der spamdyke.conf.
Jetzt hab ich in dieser whitelist nochmal die Domain eingetragen und werde das morgen mal testen ob´s doch noch so funktioniert.

[harv]

An deiner stelle würde ich denen miteilen das ein PTR einzurichten keine 5min dauert und das für den Mailverkehr zwingend erforderlich ist. (lass mich raten die haben auch einen Win server ;) )

Steht auch in der RFC 1912: http://www.ietf.org/rfc/rfc1912.txt?number=1912