Probleme beim Mailversandt.

[Roger Wilco]

Wie schon gesagt, wenn man eine Mail, an einen auf dem Server befindlichen Benutzer schreibt, klappt es tadellos.
Also an der Anmeldung kann es nicht liegen.

Und wieder einer, der SMTP nicht ganz verstanden hat. Du kannst immer Mails an Benutzer einer Domain senden, für die der MTA zuständig ist. Sonst könntest du nie Mails empfangen...

Hat jemand von euch eine Idee woran es liegen kann?

Code: Select all

Oct 6 15:39:58 myhost postfix/smtpd[2774]: generic_checks: name=permit_sasl_authenticated status=0 

Authentifiziere dich an deinem Postfix mit SMTP-Auth. Dann klappts auch mit dem Relaying.

BTW: Der CODE-Tag existiert...

[m.c.s.]

Spassvogel.
Genau das tun wir.
Wir melden uns entsprechend an.

Genau das scheint euer Postfix aber anders zu sehen, ansonsten würde er ja gemäß euren Einstellungen das Relayen erlauben. Was sagt "postconf -n" bzw. was steht in deiner smtpd.conf im Unterverzeichnis "sasl"?

Das wäre aber ein schön unsicheres System, wenn man ohne authentifizierung einfach so mal jedem Benutzer auf dem gkleichen System per smtp mails versenden könnte. *hahaha*
Wer hat da jetzt etwas von Sicherheit nicht verstanden?
Im übrigen ist er mit den gleichen POP3 / SMTP Benutzereinstellungen in der Lage die Mails abzurufen.

Ich würde sagen, dass DU hier SMTP definitiv nicht verstanden hast, denn genau das funktioniert, sofern du den Absender nicht mittels Blacklisten aussperrst (was aber in deiner Config nicht der Fall ist) :roll:

Und nur weil der POP3-Abruf funktioniert, heißt das nicht, dass deswegen auch SMTP-Versand funktioniert - das sind zwei völlig verschiedene Programme

[Roger Wilco]

Das wäre aber ein schön unsicheres System, wenn man ohne authentifizierung einfach so mal jedem Benutzer auf dem gkleichen System per smtp mails versenden könnte. *hahaha*

Ich weiß jetzt ehrlichgesagt nicht, ob du mich nur falsch verstanden hast, oder ob du es wirklich nicht kapiert hast.
Machen wir mal ein Experiment. Du hast sicher einen generischen TCP-Client wie `telnet` oder `netcat` installiert.
Führ mal "$TCP-CLIENT mx-ha01.web.de 25" (mx-ha01.web.de ist ein MX-Host von web.de) aus.

Code: Select all

% nc6 mx-ha01.web.de 25 <<ENTER>>
220 mx04.web.de ESMTP WEB.DE V4.105#323 Thu, 06 Oct 2005 22:14:55 +0200
EHLO there <<ENTER>>
250-mx04.web.de Hello there [123.456.789.123]
250-SIZE 70254592
250-PIPELINING
250 HELP
MAIL FROM:info@example.org <<ENTER>>
250 <info@example.org> is syntactically correct
RCPT TO:deine-adresse@web.de <<ENTER>>
250 <deine-adresse@web.de> verified
DATA <<ENTER>>
354 Enter message, ending with "." on a line by itself
Subject: Test <<ENTER>>
 <<ENTER>>
Test <<ENTER>>
. <<ENTER>>
250 OK id=1ENc9A-0001vq-00
QUIT <<ENTER>>
221 mx04.web.de closing connection

Die Zeile mit " <<ENTER>>" dahinter gibst du ein. Hast du dabei irgendwas von einer Authentifizierung gesehen? Nein? Ich auch nicht. Als Bettlektüre empfehle ich dir RFC2821.

Im übrigen ist er mit den gleichen POP3 / SMTP Benutzereinstellungen in der Lage die Mails abzurufen.

POP3 != SMTP.

Wenn ich mit dem entsprechenden Benutzer und Passwort auf meinem Apple und Entourage ("Outlook für den Mac") kann ich wunderprächtig über z.B. Arcor DSL oder T-online DSL mails an die Problemadresse senden.

Ja, weil die Mailserver von Arcor und T-Online richtig konfiguriert sind.

[m.c.s.]

Sorry, ich klinke mich dann mal aus:
Wenn mehrere Leute unabhängig voneinander dasselbe sagen, könnten die durchaus recht haben. Ich behaupte nämlich mal, dein Problem sehr wohl verstanden zu haben...

[Roger Wilco]

Schliesse ich meinen Rechner ans System des Endkunden an. Gehe per smtp über dessen netz auf meinen Server tritt genau dieses Problem auf.

Dein Log sagt, dass du dich nicht authentifiziert hast. Punkt.

<< EOD

[captaincrunch]

Auch das Versenden nur nicht über dieses Globeville.de.
Woebi hier das Problem besteht, dass eine Rückverfolgung per z.B. helo etc. nicht möglich ist.

Schon mal daran gedacht, dass der Provider zur Spamvermeidung ausgehenden Traffic mit Zielport 25 blocken könnte? Kommt überhaupt irgend etwas auf dem Server an, wenn du es von dort aus mitsniffst?

[flo]

Hat der Kunde irgend eine Security Appliance in seinem Netz laufen, die eventuell SMTP filtert? Das wäre eine Möglichkeit, wie von Deinem Rechner zum Server die Authentifizierung verloren gehen könnte.

flo.

[flo]

http://support.microsoft.com/?kbid=8958 ... 0121120120

Lesen bildet ...

flo.

[flo]

Das "Raptor"-Ding scheint SMTP zu filtern, wenn keine Ausnahmen angelegt sind. Davon abgesehen benutzen einige Provider noch POP-before-SMTP, also wäre jetzt ein Headervergleich von mindestens vier Mails relevant, in denen Du die Auth unter die Lupe nimmst.

Das einfachste wäre gewesen, von Anfang an das Netz auseinanderzunehmen und festzustellen, welche Daten wie manipuliert werden.

flo.