Spamdyke Problem

[piloly]

Hallo,
nach dem ich das Problem selber nicht löschen kann, versuche ich es hier. Ein Kunde hat mir berichtet ein Mail von einer bestimmten Person nicht zu erhalten. Ich habe anhand der Absender Adresse das Mail auch in den Logs mit folgender Ablehnung gefunden:

Absender: [email protected]
Bewertung: DENIED_OTHER
Absender IP: 213.165.64.20
Reverse DNS: mail.gmx.net

Als erstes habe ich im Spamdyke Docu nach geschaut und für DENIED_OTHER folgendes gefunden

The connection was rejected by qmail (or another downstream filter), not spamdyke.

Also scheint nicht Spamdyke das Mail nicht zu mögen sondern was anderes. Ich habe kein SPF Check oder Domainkeys laufen, keine Blocklisten aktiv also kann es daran schon mal nicht liegen.
Weiters habe ich versucht in Spamdyke alle Blacklists zu deaktivieren und auch Spamassassin für das Konto ausgeschaltet. Kein Erflog. Das Mail kommt nach wie vor nicht durch.
In /var/log/mail.info hab ich mit der E-Mail Adresse auch nichts weiter gefunden. Komisch ist auch, dass von der selben IP und RDNS andere Mails durch gekommen sind auf dem Server.

Irgendwie weiß ich nicht in welchen Logs ich noch nachsehen könnte bzw. welche Tests ich machen kann. Einfach die E-Mail Adresse auf die Whitelist setzen nenne ich nicht das Problem finden.

Hoffe jemand kann mir Impulse geben.

 

[der-merlin]

Hallo,
ist qmail mit uservalidierung gepatcht? Dann habe ich auch diese Meldung wenn der Empfänger nicht existiert. In meiner log-Datei steht dann aber VOR dieser Fehlermeldung der Fehler von qmail (ich hab die Logs in var/log/qmail/smtpd) cu

 

[piloly]

Also vorweg ich bin kein Experte in diesem Bereich. Ich glaube jedoch, dass qmail mit uservalidierung arbeitet. Jedenfalls lass ich über SMPT nur Authentifizierte Zugriffe zu falls das das selbe ist. Vor dem Logeintrag von Spamdyke habe ich auch noch einen weitere dazu. Hier noch mal beide Zeilen:

Oct 28 15:22:59 xxx relaylock: /var/qmail/bin/relaylock: mail from 213.165.64.20:51980 (mail.gmx.net)
Oct 28 15:22:59 xxx spamdyke[20393]: DENIED_OTHER from: [email protected] to: [email protected] origin_ip: 213.165.64.20 origin_rdns: mail.gmx.net auth: (unknown)

Die Empfängeradresse ist in diesem Fall aber definitiv richtig. Weiters hatte ich nun versucht die Absenderadresse auf die Whitelist zu setzen aber das Mail wird immer noch gleich geblockt. Irgendwie auch verständlich weil ja angeblich nicht Spamdyke das Mail blockt.

 

[piloly]

Ich habe nun noch in meiner /etc/inetd.conf nachgesehen und dort habe ich folgendes in den Spamdyke relevanten Zeilen stehen:

smtp stream tcp nowait.1000 root /var/qmail/bin/tcp-env tcp-env -Rt0 /usr/bin/env SMTPAUTH=1 END=1 /var/qmail/bin/relaylock /usr/local/bin/spamdyke -f /etc/spamdyke.conf /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
smtps stream tcp nowait.1000 root /var/qmail/bin/tcp-env tcp-env -Rt0 /usr/bin/env SMTPAUTH=1 END=1 /var/qmail/bin/relaylock /var/qmail/bin/relaylock /usr/local/bin/spamdyke -f /etc/spamdyke.conf /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true

So wie ich das sehe läuft also vor Spamdyke lediglich relaylock. Ist relaylock nicht nur bei ausgehenden Mails für die SMTP Authentifizierung zuständig? Kann es sein, dass das Mail von relaylock geblockt wird?

EDIT: Mir ist gerade aufgefallen, dass ich beim smtps stream 2 mal "/var/qmail/bin/relaylock" stehen habe. Eventuell ist das für den Fehler verantwortlich. Habe das nun richtig gestellt und erneut ein Testmail angefordert.

 

[piloly]

Mir ist gerade aufgefallen, dass ich beim smtps stream 2 mal "/var/qmail/bin/relaylock" stehen habe. Eventuell ist das für den Fehler verantwortlich. Habe das nun richtig gestellt und erneut ein Testmail angefordert.

Auch das hat keine Lösung gebracht

 

[der-merlin]

Uservalidierung ist bei mir, dass auf smtp-Ebene nur für vorhandenen Mailkonten die Mails angenommen werden, alles andere wird noch vor Posteinlieferung geblockt. Das bringt dann den Fehler DENIED_ OTHER

"/var/qmail/bin/relaylock"(

ich habe hier ja kein PLESK, aber wenn ich nicht irre, ist relaylock nicht notwendig wenn man smtp_auth benutzt... steht bestimmt irgendwo bei huschi.net
Frage: hast Du smtp_auth auch in spamdyke.conf aktiviert? Wäre dann ja doppelt gemoppelt. Hat vielleicht nichts mit diesem Problem zu tun, aber Murphy lauert überall

 

[piloly]

Ja ich habe smtp_auth aktiv. Folgende Werte sind gesetzt:

smtp-auth-command=/var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
smtp-auth-level=ondemand-encrypted

Dann könnte ich relaylock auch aus meiner /etc/inetd.conf nehmen da ich ja über nur über smtp-auth arbeite?

Hier noch mein eintrag in /etc/inetd.conf ohne smtps

smtp stream tcp nowait.1000 root /var/qmail/bin/tcp-env tcp-env -Rt0 /usr/bin/env SMTPAUTH=1 END=1 /var/qmail/bin/relaylock /usr/local/bin/spamdyke -f /etc/spamdyke.conf /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true

Eine Unklarheit hier ist auch noch wegen der Zeilenlänge. Glaube gelesen zu haben dass die Zeile maximal länger als 255 Zeichen sein darf. Bei mir (Debian4) ist sie länger es scheint aber doch zu gehen.

 

[der-merlin]

hallo,
ich sag mal so: viel hilft nicht immer viel

Mein qmail kann auch smtp-auth, deshalb hab ich das in spamdyke AUS!!!
wegen relaylock : mal hier rumsuchen oder hoffen, das ein Admin antwortet, ich hab meinen eigen Server, nicht mit Plesk und relaylock.
ich muss jetzt los...

 

[Huschi]

Ich habe nun noch in meiner /etc/inetd.conf nachgesehen

Hier stellt sich immer die übliche Frage:
Nutzt Du auch wirklich den inetd oder evtl doch den xinetd.
Zu bemerken wäre, daß SWsoft/Parallels grundsätzlich den xinetd für Ihren gepatchten Qmail empfiehlt.

Glaube gelesen zu haben dass die Zeile maximal länger als 255 Zeichen
sein darf.

Jupp, das ist auch korrekt.
Aber ggf. wird lediglich der Cram5-Teil abgeschnitten.

huschi.

 

[piloly]

Hier stellt sich immer die übliche Frage:
Nutzt Du auch wirklich den inetd oder evtl doch den xinetd.
Zu bemerken wäre, daß SWsoft/Parallels grundsätzlich den xinetd für Ihren gepatchten Qmail empfiehlt.

Ja ich nutze inetd da xinetd bei mir überhaupt nicht zu finden ist. Auch Spamdyke habe ich in der inetd angelegt und funktioniert soweit. Bei mir war das mit Plesk bereits so eingerichtet.

 

[Huschi]

Du solltest mal den Umstieg auf xinetd erwägen. Denn aufkommende Probleme sind fast vorprogrammiert. Spätestens wenn sich mal jemand per Cram authentifizieren möchte.

Da es Spamdyke nicht ist und danach nur der qmail-smtpd in der Reihe steht, kann nur er es abgelehnt haben. Warum auch immer (evtl. wegen fehlenden Parametern ), eins steht fest: Er wird es Dir nicht verraten. Denn dieser Teil von Qmail schreibt nicht ins Logfile.
Dies kann man nur ändern, wenn man selber ein Logging einbaut.
(siehe Plesk/Qmail: Qmail selber kompilieren - huschi.net)

Evtl. wäre es sinnvoll nachzuhaken, wo die Email denn hin verschollen ist. Hat der Absender bei GMX eine Bounce-Mail erhalten? Wenn ja, was steht drin?
Oder wurde die Email zu einem anderen Zeitpunkt erneut zugestellt? Wenn ja, wurde sie wieder abgelehnt und wenn wie oft?

huschi.

 

[piloly]

Du solltest mal den Umstieg auf xinetd erwägen.

Wenn es von dir empfohlen wird ist es sicher sinnvoll. Generell greife ich jedoch immer so wenig wie möglich in das vorkonfigurierte System ein. Ersten da ich so bei Updates sicherer bin und zweitens weil ich nicht der Linux Profi bin. Die Installation von Spamdyke (laut deiner Anleitung) war für mich schon ein Abenteuer.

Evtl. wäre es sinnvoll nachzuhaken, wo die Email denn hin verschollen ist. Hat der Absender bei GMX eine Bounce-Mail erhalten? Wenn ja, was steht drin?
Oder wurde die Email zu einem anderen Zeitpunkt erneut zugestellt? Wenn ja, wurde sie wieder abgelehnt und wenn wie oft?

Leider habe ich hier noch kaum Feedback erhalten. Du kennst das sicher selber wenn der Fehler nicht reproduzierbar ist und man auf einen normalen Internet User angewiesen ist, ist es relativ schwierig vernünftig zu Testen bzw. ein korrektes Feedback zu erhalten (Bounce Mails werden als Spam angesehen usw.)
Was ich sicher sagen kann ist dass das Mail laut meinen Logs nicht erneut zugestellt wird. Es wird also gesendet, abgelehnt und das war's.