<html>
<head />
<body>
Erstmal Danke an Kai, dass Du Dir die Mühe gemacht hast, dich dem Ganzen so ausführlich zu widmen. Bin derzeit unterwegs und hatte zu Beginn nichtmal die Stelle im RFC gefunden...<br /><br /><blockquote type="cite">
<p>-------- Original-Nachricht --------<br />Datum: Tue, 18 Oct 2011 12:50:00 +0200<br />Von: "Kai Fürstenberg" <kai_postfix@fuerstenberg.ws><br />An: "Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein." <postfixbuch-users@listen.jpberlin.de><br />Betreff: Re: [Postfixbuch-users] Postfix fehlerhaft implementiert?<br /><br /></p>
Am 16.10.2011 22:00, schrieb meinemailings@gmx.net:<br />> ... das wir zumindest kürzlich hier behauptet.<br />> <br />> http://www.axigenmailgate.de/forum/axigen-8-0-fehlersuche-und-probleme/812-axigen-und-postfix-als-smtp-client.html<br />> <br />> Ist Postfix da wirklich nicht RFC-Konform und was hat es mit diesem AUTH<br />> im MAIL FROM auf sich?<br /></blockquote><br /><blockquote type="cite">Ich bin mir jetzt nicht so ganz sicher, ob ich das richtig verstanden<br />habe, aber das stellt sich für mich folgendermaßen dar:<br /><br />Genau handelt es sich um RFC 2554 (SMTP Service Extension for<br />Authentication). Darunter findet sich unter Punkt 5 "The AUTH parameter<br />to the MAIL FROM command". Der ist optional, und soll eine zusätzliche<br />Sicherheit darstellen, indem der Urheber der Mail nochmals irgendwie<br />angegeben wird, und weitergegeben werden muss, wenn der empfangende<br />Server den AUTH-Parameter unterstützt (oder so ähnlich).<br /><br />Postfix arbeitet, soweit ich weiß, nicht mit dem AUTH-Parameter, sendet<br />aber ein "AUTH=<>", wenn der empfangende Server den AUTH-Parameter<br />unterstützt. Das darf er auch, der Parameter ist optional und ist<br />entweder eine Absender-ID oder eben "<>". Postfix verhält sich somit<br />Regelkonform. Er könnte den Parameter auch einfach weglassen, evtl. ist<br />das für eine spätere Implementation schon vorbereitet.<br /><br />Der empfangende Server (Axigen) muss aber (SHOULD) im Falle eines<br />vorherigen AUTH-Kommandos (SMTP AUTH) das AUTH= selbst entsprechend<br />setzen. Dem einliefernden Client also vertrauen und den Parameter<br />vervollständigen.<br /><br />"If the server trusts the authenticated identity of the client to<br /> assert that the message was originally submitted by the supplied<br /> addr-spec, then the server SHOULD supply the same addr-spec in an<br /> AUTH parameter when relaying the message to any server which<br /> supports the AUTH extension."</blockquote>Ich glaube, das Setzen des Parameters durch Axigen geschieht dann nur, wenn dieser die Mail an einen externen Server weiterreicht. Aber auch hier SHOULD, ob axigen die Info weitergibt ist wieder Auslegungssache. Und ich meine, dass dies für diesen Fall nicht relevant ist.<br /><blockquote type="cite"><br />Zudem darf er aber im Falle von AUTH=<> die Mail nicht als authentisch<br />betrachten.<br /><br />"A MAIL FROM parameter of AUTH=<> indicates that the original<br /> submitter of the message is not known. The server MUST NOT treat<br /> the message as having been originally submitted by the client."<br /></blockquote><blockquote type="cite"><br />Es liegt die Vermutung nahe, dass das obige "SHOULD" von Axigen als<br />"sollte, aber muss nicht" interpretiert wird, und somit der zweite Punkt<br />zum tragen kommt. Andererseits ist das AUTH= aber auch bereits vorhanden.<br /><br />Evtl. misst Axigen dem AUTH-Parameter höhere Bedeutung bei, als dem<br />SMTP-Auth. Wahrscheinlich geht er davon aus, dass das AUTH= fehlt, wenn<br />SMTP-AUTH verwendet wird. In gewisser Weise ist das auch verständlich,<br />denn das "MUST NOT" aus dem zweiten Zitat ist stärker als das "SHOULD"<br />aus dem ersten.<br /></blockquote>Meine Befürchtung ist, dass der Axigen Admin damit irgendwie recht hat bzw. zurecht sagen könnte: Wenn postfix meint, diesen Wert (zwar RFC Konform) mit <> zu belegen, darf ich (MUST laut RFC) ihm nicht glauben, dass er derjenige ist, der sich zuvor authentifiziert hat. Und weil ich (axigen) in diesem Punkt besonders sicherheitsbewußt bin, lehne ich diese Mail ab.<br /><br />@Liste: Bitte bitte widerlegen!<br /><blockquote type="cite"><br />Es kann sein, dass ich etwas daneben liege, aber so ungefähr stellt sich<br />das für mich dar. Die Bestimmungen finde ich persönlich etwas<br />unübersichtlich.<br /></blockquote>Sehe ich genauso bzw. das Schlimmste für mich ist, dass sich mir nichtmal der Sinn dieser (zweiten) AUTH Option erschliesst.<br />Wenn sich ein Client im ersten AUTH korrekt authentifiziert, dann kann dieser doch im zweiten AUTH angeben was man will, oder? <br />Letzlich scheint es Auslegungssache zu sein, ob und wie diese Option verwendet/verarbeitet wird. <br />Da würde ich mir mehr Klarheit wünschen oder falls ich es falsch verstanden habe eine Erleuchtung... vielleicht auch einfach nur ein Beispiel, wo diese Option Sinn machen könnte.<br /><br />Gruß Robert<br /><blockquote type="cite"><br />-- <br />Kai Fürstenberg<br /></blockquote>
<div class="signature"><br /><br /><br />-- <br />NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! <br />Jetzt informieren: http://www.gmx.net/de/go/freephone</div></body>
</html>