RootForum Community

tach,

Und wieder ein freche Frage (wobei ich in den Howtos nichts fand ...)
Ein Kunde sendet uns eine Mail zum einen an unsere Firmenadresse (Route geht über Strato(Qmail) an uns ). Dies kommt nicht an. In der /var/log/warn steht dann

smtp_auth: SMTP connect from unknown@metabuoy.domain.net [xxx.xxx.xxx.xxx]

An eine gmx- Adresse kann aber gesendet werden. Im Envelope steht dann:

Received: (qmail invoked by alias); 16 Oct 2006 13:04:02 -0000
Received: from metabuoy.domain.net (EHLO metabuoy.domain.net) [xxx.xxx.xxx.xxx]
by mx0.gmx.net (mx091) with SMTP; 16 Oct 2006 15:04:02 +0200
Received: from styx.domain.net ([217.91.29.71])
by metabuoy.domain.net with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32)
(Exim 4.50)
id 1GZS8D-000309-3w
for ich@gmx.de; Mon, 16 Oct 2006 15:03:49 +0200

Weiß jemand, wie man Qmail dazu bekommt, die Mail ebenfalls zu akzeptieren ? Jegliche Hilfe wäre nochmals nett Danke !

Gruß

poc

BEST GUESS:
metabuoy.domain.net ist nicht in rcpthosts

edit:natürlich schmarren, der "TO" Host muß da hin
.... das ist gmx.de? häää?
Jetzt verstehe ich es aber nicht mehr:
Du willst, das Xbeliebig über deinen Mailserver Mails an xbeliebig@gmx.de schicken kann? Verstehe ich nicht!

zwei Ideen:
1. Empfänger ist nicht beliebig@gmx.tld sondern was anderes -> ab in die rcpthosts mit dem Host und gut.
2. Sender ist ein User mit Login und Password -> der User muß clientseitig ein richtiges Login angeben.

Wenn das nicht hilft, versuche vielleicht mal zu beschreiben, was Dein Ziel ist. Von wem kommt die Mail und wo soll die hin. Das kann immer sein [vertrauenswürdiger Host|nicht vertrauenswürdiger Host|User mit Login|me] - da kommen wir vielleicht weiter.

Hi lucki2,

Problem ist, dass ein sender XY an GMX senden kann aber nicht an uns.
Wenn er an uns sendet, kommt eine Fehlermail, die folgendermaßen anfängt, an ihn zurück:

-----Ursprüngliche Nachricht-----
Von: Mail Delivery System [mailto:Mailer-Daemon@metabuoy.domain.net]
Gesendet: Freitag, 20. Oktober 2006 17:16
An: Hans Wurst (= ursprünglicher Absender)
Betreff: Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

ich@unseredoamin.de
SMTP error from remote mailer after MAIL
FROM:<hwurst@domain.net>:
host mail.unseredoamin.de [85.214.53.247]: 535 auth failure

------ This is a copy of the message, including all the headers. ------

Return-path: <hwurst@domain.net>
Received: from styx.domain.net ([213.91.29.71])
by metabuoy.domain.net with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32)
(Exim 4.50)
id 1Gaw61-0000Xc-F1
for ich@munseredoamin.de; Fri, 20 Oct 2006 17:15:41 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: 123
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C6F45A.5EF3C6CA"
Date: Fri, 20 Oct 2006 17:13:20 +0200
Message-ID: <1867DA556814F64190BB03351FE3932434D2B1@METAMASTER.metaship.office>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 123
Thread-Index: Acb0Wkczbc3T2oXaREOpbP238MmEnA==
From: "Hans Wurst" <hwurst@domain.net>
To: <ich@munseredoamin.de>
-------weiter mit Mailtext

die Zeile mit "535 auth failure" deutet auf ein Authentifizierungsproblem hin. Mir leuchtet nicht ein, warum gmx die nachricht empfangen kann.

Wenn es noch eine Leuchte gibt, die einem Dummen weiterhelfen kann.
Immer her damit.

Gruß

Poc

*g* Entschuldigung ich komme immer noch nicht ganz weiter.
wenn das der RCPTO ich@munseredoamin.de ist an euch ..

for ich@munseredoamin.de
...
To: <ich@munseredoamin.de>

dann: in die /control/rcpthosts

wenn das

host mail.unseredoamin.de

dann und dann glaube ich, sehe ich noch das für alle hosts, die so vorkommen, untereinander alle in die rcpthost ...

PS: So wie ich qmail-auth kenne setzt das bei authentifizierung einfach die RELAYHOST Umgebungsvariable und sonst eben nicht ... dann müsste das hinhauen ... die Bounce irritiert mich aber ...
Jetzt erstmal die Hosts(s.o) in die rcpthosts , dass ist auf jeden Fall richtig, dann schauen wir weiter, ob da noch was anderes ist ...

Ich hab mich zu entschuldigen, falls es zu unklar war...
Alle Hosts standen jedoch bei absetzen der Mail in der "/var/qmail/control/rcpthosts" eingetragen.

in der "/var/log/warn" steht dann

warn-20061018:Oct 22 12:23:07 h931780 relaylock: /var/qmail/bin/relaylock: mail from 211.12.114.188:35578 (metabuoy.domain.net)
warn-20061018:Oct 22 12:23:07 h931780 smtp_auth: SMTP connect from unknown@metabuoy.domain.net [211.12.114.188]
warn-20061018:Oct 22 12:23:07 h931780 smtp_auth: smtp_auth: FAILED: - no such user from unknown@metabuoy.domain.net [211.12.114.188]

Vielleicht hast Du noch einen gloreichen Gedanken.
Auf jeden Fall Dank Dir bis hierhin!

Gruß

Poc

warn-20061018:Oct 22 12:23:07 h931780 relaylock: /var/qmail/bin/relaylock:

Du hast Plesk laufen?
Wenn mußt Du leider warten, bis da jemand mit Plesk Erfahrung kommt(ganz einfach, weil bis wir darauf kommen, was die da machen werden wir alt).

Wenn nein, schau ich noch mal, brauche aber leider noch infos um da ranzukommen.

Ich war zunächst von einem normal qmail-auth gepachten qmail ausgegangen. Du hast da irgend was anderes. Einerseits ein smtp-auth, von dem ich mittlerweile nicht mehr glaube, daß es qmail-auth ist und andererseits poplock?. Imho müsste ein ungepatchtes(Ja, der patch zum patch...) qmail-auth ein poplock wieder zunichte machen.


Also: welches auth, wofür nutzt Du poplock und was läuft da noch. Wenn Du qmail gepatched hast: mit was? So in der Richtung. Es geht mir darum, was da mit der mail passiert, welche Programme da ineinanderspielen.

(Plesk habe ich nicht - leider.).
... und sag noch dazu welchen tcpwrapper Du nutzt ... den brauchen wir, wenn wir rundrum arbeiten müssen ...

Ach ich erklär Dir noch was dazu, damit Du weißt wo es noch hapert ...
qmail-smtp-auth ist uralt, war eigentlich eher genial. Einfach ein Hook in den Du ein beliebiges Passwortprogramm oder was auch immer Dir beliebt einhängen kannst, auch zb Beispiel die NIS anfragen oder .. dazu konntest Du noch ein weiteres Program angeben, daß den Returncoden interpretiert - denn manche Programme gaben 0 bei Erfolg und andere bei Mißerfolg zurück. Das ist der Klassiker.
Kam in die Jahre und wurde von jemand Anderen übernommen - unbrauchbar Buggie. Wurde zwar gewarted aber ... Dann kammen wieder andere, die haben den Patch einfach wieder gepatched und daraus sind unzählige Varianten entstanden.
Die meisten sind am Ende im Prinzip gleich: "RELAYCLIENT" wird in Abhängigkeit von der Paswortabfrage gesetzt. Die meisten - aber eben nicht alle. Dazu gibt es dann noch Patches die Patches kombinieren und auch noch eigenständige Sachen.
Das müssen wir jetzt klären, sonst kann ich nur in raten .... wenn Du aber Plesk hast wird`s das wahrscheinlich ganz schwierig.
OK?

Hallo,

Erstmal Danke für die Vorschläge aber wir benutzen PLESK. Habe versucht mich an den Support von Strato zu wenden. Falls ich was in Richtung Lösung habe sag, kann ich das gerne posten.
Ist bei PLESK das qmail standardmäßig gepached ?
In der mail.info kommt neuerdings manchmal:

Oct 25 16:30:02 h931780 qmail: 1161786602.106993 delivery 17800: failure: Sorry._Although_I'm_listed_as_a_best-preference_MX_or_A_for_that_host,/it_isn't_in_my_control/locals_file,_so_I_don't_treat_it_as_local._(#5.4.6)/

Weißt Du was das heißt ?

Dank Dir nochmal für die Ansätze.

Gruß

Poc

pocopelli wrote:Ist bei PLESK das qmail standardmäßig gepached ?

Ja.

pocopelli wrote:Sorry._Although_I'm_listed_as_a_best-preference_MX_or_A_for_that_host,/it_isn't_in_my_control/locals_file,_so_I_don't_treat_it_as_local._(#5.4.6)/

Weißt Du was das heißt ?

Es heißt genau das, was da steht: Dein Server ist als primärer MX für die betreffende Domain eingetragen, weiß davon aber laut $QMAIL_ROOT/control/locals nichts...

Ich kann dir zu Plesk nichts sagen. Aber ungepachte qmail gibt es so gut wie nie. Das ist DJB's Sicherheitsvorstellung.
Ich kann mal gaaanz grob ins Blaue schießen was Plesk macht - aber mehr ist das nicht.
a) ein smtpauth gepatchtes qmail, bei dem smtpauth mindestens mit requireaut gepatcht wurde - wahrscheinlich selber gepatched und in Verbindung mit gepatchtem TLS patch. [Willkommen bei QMail!]

b) Wird das poplock wahrscheinlich als Hook mißbraucht und wurde dafür gepatched. Das damit in Plesk Relayhosts, User o.ä. konfiguriert werden können.

Das ist die Kristalkugel poliert und geraten, was das für Schatten sein könnten. Was soll ich anderes tun?

Jetzt noch so ein paar Sachen, die ich versuchen würde um Produktivität zu gewährleisten. Zeitrahmen: 30min.

a) hätte requireauth den Effekt solche Fehler zu Produzieren aber auch eine vorherige "RELAYCLIENT" zu übernehmen - mit poplock(/var/qmail/bin/relaylock) davor zu 99%. Wenn das so ist kann um Dein Problem rumgearbeitet werden indem über tcpwraper "RELAYCLIENT" für die Ralayhosts gesetzt wird. (also nochmal eine Instanz davor ... )

b) poplock würde normal keinen Ärger machen. Ich nehme aber an, daß es für Plesk gepatched wurde. Wenn dem so ist müsste irgendwo eine Konfiguration rumfliegen, wo Du Deine Hosts eintragen kannst - evtl als ip.
c) Ansonsten kannst Du, wenn requireauth läuft poplock über den tcpwrapper in Abhängigkeit ausführen.
d)Außerden kannst Du poplock patchen. Ich weiß nicht wie es bei Dir um Perl steht? - Das wären ein oder zwei Zeilen die in Abhängigkeit von einer Hostprüfung das "RELAYCLIENT" in ENV setzten wird und dann abbrechen(in den Code schauen).

e) braucht imho ein smtpauth immer den richtigen Host um die Challange rauszuschicken(den der Client erwarted) - sonst funktioniert bei bestimmten Hosts die Authentifizierung nicht. Das solltest Du auch checken.

Hinweise:
a) Requireauth(oder ähnliches) ist eigentlich der größte Unsinn bei einer Konfiguration wie der Deinen. Das heißt nämlich zuerst etwas einbauen, daß eine Konfiguration wie Deine verunmöglichen soll und das danach wieder über einen WA außer Kraft setzen.

b) requireauth(und ähnliches) wirft eine Sicherheitsfrage auf. Das Szenario ist eine (große)Liste mit Usern an den Mailserver schicken und die Bounces auswerten. Ein solcher "Angriff" würde Deine User preisgeben - aber strittig wie gefährlich das im Vergleich zur gewonnen Klarheit für die User ist.

Viel Text ich weiß aber so ist das eben.

Ich habe gerade gesehen, daß das von RW ein Link ist. Wenn ich die Nacht Nerven habe schaue ich mir das durch. Aber Plesk hat sein eigenes smtp-auth (und tls) habe ich schon gesehen....

hab's schon...
bingo: ist ein qmail-smtp-auth drübergepatched, deutlich an den Kommentaren des ur-auth zu erkennen aber zumindest mit dem hier:

relayclient = env_get("RELAYCLIENT");

+#ifdef USE_SMTPAUTH
+ if(relayclient)
+ authenticated = 1;

Das bedeuted Du kannst auf alle Fälle drumrumarbeiten indem Du vor dem Aufruf von QMail für Deine im TCPWRAPPER für deine Hosts setzt. Wenn du es sicher haben willst, mache es über die IP - Namen können gefaked werden.
[ D.h. a,c und d der Kristallkugelversuche oben waren treffer ]

... um Dir folgenden zu können. gibt es Howtos / Einführungen in denen tdpwrapper, relevante ConfigDateien von Qmail für Anfänger erklärt werden ?

Gruß

poc

UI
google nach

xinetd
inetd
ucspi-tcp

weiß ich nicht was Du hast? Für Qmail wird gerne DJB's ucspi-tcp genutzt. Inetd ist etwas in die jahre gekommen, der Nachfolger ist xinetd. xinetd und inetd nebeneinander ist problematisch aber einen von denen gekoppelt mit ucspi-tcp ist möglich.
Bei ucspi-tcp: in eine Datei(z.b. /etc/tcp.smtp) und mit bauen...
oder inetd xinetd
Alle IP's vom Speziellen zum Allgemeinen(oder mit Wrapper um sich behelfen, wenn tcp-env für mehrere Programme genutzt wird)..
in /etc/hosts.allow für alle. die Relayen sollen am Ende den catch-all qmail dann entsprechend aufrufen(wenn das nicht schon so eingerichtet ist).
Das ist aber alles auch FAQ. Bei qmail, tcprules, xinetd,tcpserver,tcpd ... da steht bestimmt überall ein Hinweis auf QMail und RELAYCLIENT.

Daneben kann es wie erwähnt noch eine Plesk-builtin Methode geben. Das genannte ist eine Standartvorgehensweise

Empfehlung: ucspi-tcp lohnt sich anzuschauen.