[Postfixbuch-users] Postfix fehlerhaft implementiert?

[meinemailings at gmx.net]

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...


>             
> -------- Original-Nachricht --------
> Datum: Tue, 18 Oct 2011 12:50:00 +0200
> Von: "Kai Fürstenberg" <kai_postfix at fuerstenberg.ws>
> An: "Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein." 
> <postfixbuch-users at listen.jpberlin.de>
> Betreff: Re: [Postfixbuch-users] Postfix fehlerhaft implementiert?
> 
>             Am 16.10.2011 22:00, schrieb meinemailings at gmx.net:
> > ... das wir zumindest kürzlich hier behauptet.
> > 
> > 
> http://www.axigenmailgate.de/forum/axigen-8-0-fehlersuche-und-probleme/812-axigen-und-postfix-als-smtp-client.html
> > 
> > Ist Postfix da wirklich nicht RFC-Konform und was hat es mit diesem 
> AUTH
> > im MAIL FROM auf sich?
> 


> Ich bin mir jetzt nicht so ganz sicher, ob ich das richtig verstanden
> habe, aber das stellt sich für mich folgendermaßen dar:
> 
> Genau handelt es sich um RFC 2554 (SMTP Service Extension for
> Authentication). Darunter findet sich unter Punkt 5 "The AUTH parameter
> to the MAIL FROM command". Der ist optional, und soll eine zusätzliche
> Sicherheit darstellen, indem der Urheber der Mail nochmals irgendwie
> angegeben wird, und weitergegeben werden muss, wenn der empfangende
> Server den AUTH-Parameter unterstützt (oder so ähnlich).
> 
> Postfix arbeitet, soweit ich weiß, nicht mit dem AUTH-Parameter, sendet
> aber ein "AUTH=<>", wenn der empfangende Server den AUTH-Parameter
> unterstützt. Das darf er auch, der Parameter ist optional und ist
> entweder eine Absender-ID oder eben "<>". Postfix verhält sich somit
> Regelkonform. Er könnte den Parameter auch einfach weglassen, evtl. ist
> das für eine spätere Implementation schon vorbereitet.
> 
> Der empfangende Server (Axigen) muss aber (SHOULD) im Falle eines
> vorherigen AUTH-Kommandos (SMTP AUTH) das AUTH= selbst entsprechend
> setzen. Dem einliefernden Client also vertrauen und den Parameter
> vervollständigen.
> 
> "If the server trusts the authenticated identity of the client to
>        assert that the message was originally submitted by the supplied
>        addr-spec, then the server SHOULD supply the same addr-spec in an
>        AUTH parameter when relaying the message to any server which
>        supports the AUTH extension."
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.

> 
> Zudem darf er aber im Falle von AUTH=<> die Mail nicht als authentisch
> betrachten.
> 
> "A MAIL FROM parameter of AUTH=<> indicates that the original
>        submitter of the message is not known.  The server MUST NOT treat
>        the message as having been originally submitted by the client."
> 

> 
> Es liegt die Vermutung nahe, dass das obige "SHOULD" von Axigen als
> "sollte, aber muss nicht" interpretiert wird, und somit der zweite Punkt
> zum tragen kommt. Andererseits ist das AUTH= aber auch bereits vorhanden.
> 
> Evtl. misst Axigen dem AUTH-Parameter höhere Bedeutung bei, als dem
> SMTP-Auth. Wahrscheinlich geht er davon aus, dass das AUTH= fehlt, wenn
> SMTP-AUTH verwendet wird. In gewisser Weise ist das auch verständlich,
> denn das "MUST NOT" aus dem zweiten Zitat ist stärker als das "SHOULD"
> aus dem ersten.
> 
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.

@Liste: Bitte bitte widerlegen!

> 
> Es kann sein, dass ich etwas daneben liege, aber so ungefähr stellt sich
> das für mich dar. Die Bestimmungen finde ich persönlich etwas
> unübersichtlich.
> 
Sehe ich genauso bzw. das Schlimmste für mich ist, dass sich mir nichtmal 
der Sinn dieser (zweiten) AUTH Option erschliesst.
Wenn sich ein Client im ersten AUTH korrekt authentifiziert, dann kann 
dieser doch im zweiten AUTH angeben was man will, oder? 
Letzlich scheint es Auslegungssache zu sein, ob und wie diese Option 
verwendet/verarbeitet wird. 
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.

Gruß Robert

> 
> -- 
> Kai Fürstenberg
> 
        
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20111018/e8ee9253/attachment.html>