Zusammenfassung

  • SMTP AUTH setzte einen SASL-Austausch vor die Mailtransaktion. Ein Submission-Server konnte Relay-Rechte einer authentisierten und autorisierten Identität geben, statt sie allein von der Netzadresse abhängig zu machen.
  • Der Erfolg blieb auf die Sitzung begrenzt: Authentisierungsidentität, Autorisierungsidentität, Envelope-Absender, sichtbarer Autor, Inhalt und späterer Transport waren weiterhin verschiedene Aussagen.

Ein erreichbarer Server kannte noch keinen Reisenden

SMTP transportierte ursprünglich Mail zwischen kooperierenden Rechnern. Ein Server nahm Nachrichten für lokale Domains an und leitete andere nach lokalen Regeln weiter. Wurde die bloße Erreichbarkeit eines öffentlichen Servers zur Berechtigung, an jedes Ziel zu relayen, entstand ein offenes Relay.

Auch eine Freigabe nach Quell-IP taugte schlecht für mobile Nutzer. Ein berechtigter Kunde verlor unterwegs den Zugang, während ein Gerät im zugelassenen Netz nicht automatisch die Person war, die eine bestimmte Absenderidentität verwenden durfte. POP-before-SMTP lieh sich eine kürzlich erfolgte Anmeldung aus einem anderen Protokoll. Es verband zwei Sitzungen über Adresse und Zeitfenster, nicht über die konkrete Einlieferung.

Die 1999 veröffentlichte und später durch RFC 4954 ersetzte SMTP-Erweiterung verlagerte die Entscheidung in die SMTP-Sitzung. Der Server kündigt in seiner EHLO-Antwort AUTH und eine Liste von SASL-Mechanismen an. Der Client wählt einen Mechanismus und schließt den Austausch vor MAIL FROM ab. Erfolg erzeugt keine Signatur, sondern eine engere Tatsache: Der Server hat eine Authentisierung akzeptiert und unter seiner lokalen Policy eine Autorisierungsidentität bestimmt.

Diese Tatsache kann ein Relay-Tor öffnen. Sie sagt nicht, wer die Nachricht geschrieben hat.

SASL stellte zwei Identitätsfragen

Die Authentisierungsidentität gehört zu den geprüften Zugangsdaten. Die Autorisierungsidentität bezeichnet die Rolle, in deren Namen der Client handeln möchte. Selbst nach korrekter Prüfung muss der Server entscheiden, ob die erste Identität die zweite annehmen darf.

Eine Queue kann sich als Dienstkonto anmelden und Nachrichten vieler Nutzer einliefern. Eine Assistenz kann für ein Postfach delegiert sein, aber nicht für ein anderes. Kompromittierte Zugangsdaten können technisch gültig sein und dennoch einen nie gewährten Umfang verlangen. Deshalb wird der Loginname weder automatisch zu MAIL FROM noch zum sichtbaren From-Header oder zum menschlichen Autor.

Authentisierung beantwortet: „Wer hat diese Sitzung mit diesem Mechanismus aufgebaut?“ Autorisierung beantwortet: „Was darf diese Identität hier tun?“ Envelope und Inhalt stellen spätere Fragen. Ein Log, das alle Werte in einem Feld „Benutzer“ zusammenzieht, beseitigt genau die Grenze, die das Protokoll sichtbar gemacht hat.

Submission und Transport wurden getrennte Dienste

RFC 6409 ordnete die Einlieferung eines Mail User Agent bei einem Message Submission Agent anders ein als den Transport zwischen MTAs. Auf Port 587 nimmt der MSA eine neue Nachricht entgegen, weist bestimmte lokale Fehler zurück oder korrigiert sie und übergibt sie dann an das Transportnetz.

Fehlen SMTP AUTH und eine andere unabhängige Autorisierung wie ein geschütztes Subnetz, soll ein MSA den Befehl MAIL standardmäßig mit einer Authentisierungsanforderung ablehnen. Die Regel verlangt nicht, dass sich alle Internet-Relays gegenseitig als Endnutzer authentisieren. Sie setzt strenge Zulassung dort an, wo Provider und einliefernder Client eine direkte Beziehung haben.

Ein reisender Nutzer muss daher nicht aus dem Zugangsnetz seines Providers kommen. Er authentisiert sich am Submission-Dienst und erhält nur die Relay-Rechte seines Kontos. Das eingehende MTA kann weiter Mail für eigene Domains annehmen, ohne beliebige fremde Ziele zu bedienen. IANA koordiniert den Namen AUTH und SASL-Mechanismen; ob ein Konto für eine Finanzadresse, Mailingliste oder Domain senden darf, entscheidet die lokale MSA-Policy.

Nach TLS kann der Server andere Fähigkeiten zeigen

Ein Authentisierungsmechanismus schützt sein Geheimnis nicht von selbst. RFC 4954 beschränkt die Ankündigung passwortoffenlegender Mechanismen auf ausreichend geschützte Sitzungen und erlaubt nach STARTTLS eine veränderte Mechanismenliste im erneuten EHLO. „AUTH unterstützt“ ist daher kein statisches Ja oder Nein. TLS-Zustand, Zertifikat, Mechanismus und die Downgrade-Reaktion des Clients bestimmen die sichere Auswahl.

RFC 8314 erklärte Klartext bei Mail Submission und Access später für überholt und ordnete STARTTLS auf Port 587 sowie implizites TLS auf Port 465 ein. Verschlüsselung schützt den Austausch der Zugangsdaten und die Sitzung dieses Hops. Sie macht daraus keine Ende-zu-Ende-Signatur der Urheberschaft.

AUTH=<> bewahrte das Nichtwissen

RFC 4954 ergänzte MAIL FROM um den Parameter AUTH=, mit dem die behauptete ursprüngliche Einlieferungsidentität weitergegeben werden kann. Kann ein Server sie nicht vertrauenswürdig bestimmen, verwendet er AUTH=<>. Er soll die Leerstelle nicht mit seinem eigenen Namen füllen.

Nur innerhalb einer passenden Vertrauensbeziehung gehört diese Aussage an den nächsten Server. Die von RFC 3848 registrierten Übertragungstypen ESMTPA und ESMTPSA belegen ebenfalls nur, dass am empfangenden Hop Authentisierung beziehungsweise Authentisierung plus TLS verwendet wurde. Sie beweisen weder die ganze Route noch den Autor.

SMTP AUTH ist stark, weil ein erfolgreicher Login kleiner bleibt als eine Signatur. Er kann Zugang gewähren, eine Policy auswählen und nachvollziehbare Hop-Evidenz schaffen. Er kann nicht jedes Absenderfeld, menschliche Absicht, Inhaltsbyte und spätere Relay beglaubigen.

Quellen