SMTP: Was muss nach EHLO vom Client gesendet werden?

[GwenDragon]

Ist es nach RFC nötig im SMTP-Dialog bei EHLO den FQDN eines lokalen Rechners druch den Client zu senden, also den echten Hostnamen?
Der nach EHLO wird ja bei Postfix verwendet und in den Header Received: from gesetzt
Aber relevant für den Transpost ist doch eigentlich die Remote-IP/FQDN oder?

Es gibt Mailclients, die pusten da sämtliche internen Hostnames der PCs raus je nachdem wer Mails sendet, andere schreiben localhost bei Claws Mail oder [192.168.0.100] bei Thunderbird rein.

Geht halt darum, dass in Mails nach dem from: sonst steht:

Received: from support.fritz.box (p5dcf13c8.dip0.t-ipconnect.de [93.207.19.200])
  (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
  (No client certificate requested)
  by mail2.meine-servers.de (Postfix) with ESMTPSA id C2D01C02F1
  for <sup-level2@meine-servers.de>; Tue, 28 Jul 2020 19:25:18 +0200 (CEST)

 

[d4f]

Ist es nach RFC nötig im SMTP-Dialog bei EHLO den FQDN eines lokalen Rechners druch den Client zu senden, also den echten Hostnamen?

Jein - das ist ein WTF-Punkt des RFC 5321.
De EHLO muss entweder ein gültiger FQDN sein welcher auf die IP des Clients auflöst, oder eine IP-Adresse in Brackets sein (Siehe RFC 5321 Sektionen 2.3.5 und 4.1.3). Jetzt kommt aber die Krux; sogar wenn es nicht stimmt darf er laut RFC dies ausschliesslich zu Logging-Zwecken und nicht zur Ablehnung der Email verwenden.

An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis. Information captured in the
verification attempt is for logging and tracing purposes

In der Realität geben die meisten Email-Clients ihren lokalen Hostnamen, eine beliebige generierte ID, den Namen der Email-Box auf dem Clientrechner, ... an. Also generell absolut nicht das was die RFC vorschreibt. In deinen Beispielen ist nur Thunderbird RFC-konform wobei ich die (ungewollte) Herausgabe interner IP-Adressen kritisch wenngleich nicht hochgefährlich sehe - zumal es ja im Email Header verewigt wird und die Gesprächspartner diese Information damit auch erhalten.

 

[GwenDragon]

De EHLO muss entweder ein gültiger FQDN sein welcher auf die IP des Clients auflöst, oder eine IP-Adresse in Brackets

Der FQDN: lokale IP des Clients (aus der internen Netzwerrange) oder die remote IP? Das ist ja das, was ich versuche bei manchen Clients zu verstehen.
Oder wolltest du mir sagen, dass es jedes Programm chaotisch handhabt?

Ich frage nur, weil ich Leute kenne, die meinen, die lokalen Hostnamen der Geräte gingen niemand etwas an. Zu paranoid?

Na ja, kann auch warten bis morgen. Schöne Nacht noch

 

[d4f]

Bei fqdn ist es schön definiert dass die IP Adresse des Clients dem lookup des forward-dns entsprechen muss, also die öffentliche IP ADRESSE. Im "Ansonsten" Fall mit der reinen IP Adresse ist dies aber nicht definiert und sollte meines Erachtens der IP Adresse des Clientrechners entsprechen, bei mehreren IPs derjenigen über welche die Verbindung auch tatsächlich abläuft.

Mit dem Hostnamen und anderen Header-Einträgen kann man meist analysieren wann der Benutzer wo welches Gerät verwendet, mit der IP wären xss oder xfs Attacken auf verwundbar Router möglich.

Persönlich bin ich absolut für Datenminimierung - also entweder generische Elo-Daten oder zb [127.0.0.1], alternativ "hey-geht-dich-nix-an.bnd.local" . Mir wäre jedenfalls kein normal konfigurierter Mailserver bekannt welcher dabei zicken würde, an deinen Beispielen sieht man ja wie rfc-nonconform sich die meisten Clients generell verhalten.

Schöne Nacht noch

Ah stimmt, ist schon dunkel. Gute Nacht

 

[Joe User]

Du suchst vermutlich https://tools.ietf.org/html/rfc5321 -> 2.3.10 und 3.7 -> gateway
Als gateway darfst/kannst Du "ungestraft" aka RFC-konform an einigen Headern rumfrickeln und sie so nach Aussen hin "anonymisieren" (aber nicht entsorgen). Als nicht-gateway ist das Ganze aber absolut Tabu. Und auch aus Debugging-Gründen ist es nicht zu empfehlen an Headern rumzufrickeln.

Ansonsten gelten für Clients immer die gleichen Regeln, egal wie tief im privaten oder öffentlichen Netzwerk der Client vergraben liegt.
Ein FQDN des Client muss nicht öffentlich auflösbar sein, es reicht intern (Beispiel host.intern.lan), wenn ein Gateway im Spiel ist. Der FQDN des Gateway muss hingegen öffentlich (und intern) auflösbar sein. Zudem muss ein FQDN, egal ob öffentlich oder intern, immer zur IP des jeweiligen Host auflösen. Gleiches gilt auch für die jeweiligen PTR.

Den HELO/EHLO zu fälschen ist keine gute Idee, da nicht RFC-konform (RFC 5321 -> 4.1.1.1).

 

[d4f]

Ein FQDN des Client muss nicht öffentlich auflösbar sein, es reicht intern (Beispiel host.intern.lan), wenn ein Gateway im Spiel ist.

Hier geht es ja, meiner Auffassung, um die direkte Verbindung Client->ausgehender Mailserver ohne Lan-Gateway. Nach RFC muss der Hostname für den Mailserver resolvable sein UND der IP-Adresse der Client-Verbindung entsprechen (RFC5321 4.1.4 Abs.6 ) wie du ja auch benennst. Dadurch bleibt dann nur eine DynDNS welche auf die öffentliche (potentiell dynamic shared) IP-Adresse zeigt - was funktional und technisch inpraktikabel ist.

Der EHLO wird (wenn auch nicht rfc-konform) gerne für Checks auf unauthentifiziertem Port25-Verkehr verwendet, aber für Clients wäre mir eine so strikte Konfiguration neu und nicht praxis-tauglich.


Ein kleiner Widerspruch im RFC übrigens:

The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a primary host name as specified for this
command in Section 2.3.5. If this is not possible (e.g., when the
client's address is dynamically assigned and the client does not have
an obvious name), an address literal SHOULD be substituted for the
domain name.

Dank "must, if possible" und "should" darfst du RFC-konform einen nicht-auflösbaren nicht-öffentlichen Hostnamen verwenden.

Only resolvable, fully-qualified domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be
resolved, in turn, to MX or address RRs. Local nicknames or
unqualified names MUST NOT be used. [...]

Ja was denn jetzt