Ist es möglich, eine E-Mail von einer IP-Adresse anstatt von einer Domain zu senden und zu empfangen?

Normalerweise hat eine E-Mail einen Domainnamen auf der rechten Seite des @, sodass Sie eine Organisation oder ein Unternehmen identifizieren können. Diese Domain ist in der Tat nichts anderes als ein "Name" oder ein "Alias" für eine IP-Adresse, die vom Nameserver aufgelöst wird.

Ich denke, dies könnte zum Beispiel für das Internet der Dinge verwendet werden, da es im Vergleich zu POST und GET viel mehr Möglichkeiten gibt, wie zum Beispiel "viele zu eins" oder "eins zu viele".

Gibt es eine Möglichkeit, E-Mails direkt an und von einer IP-Adresse zu senden und zu empfangen, z. B. user@xxx.xxx.xx.xxx?

email smtp email-server

— Peter Mortensen
quelle

Nebenbei: Wenn Sie der Meinung sind, dass HTTP für das Internet der Dinge zu restriktiv ist, schauen Sie sich MQTT oder XMPP an.

— Roger Lipscombe

Eine Domain ist mehr als ein Name für eine IP-Adresse. Eine Domain kann viel mehr Informationen über ihren Mail-Dienst veröffentlichen (über ihre DNS-Einträge), einschließlich mehrerer IP-Adressen für mehrere Mail-Server (z. B. zum Lastenausgleich oder zu Fallback-Zwecken).

— jjmontes

E-Mail ist auch nicht eins zu viele, sondern eins zu eins, und dann verbreitet der Server die Nachricht möglicherweise an viele. Sie können einen HTTP-Post an einen Server senden und dann viele Clients von diesem Server lesen lassen, die genau dasselbe Modell für E-Mails verwenden.

— djsmiley2k - CoW

Als jemand, der regelmäßig Netzwerkarchäologie betreiben muss, sollten Sie IPs nicht hart codieren. DNS ist nicht schwierig, und DNS-Server wie dnsmasq sind leichtgewichtig und erlauben Host-Überschreibungen. Internet-IPs ändern sich mit der Zeit.

— Criggie

Die Domain ist kein Alias für eine IP-Adresse. Insbesondere enthält E-Mail MX-Einträge, bei denen der Domänenname einem oder mehreren Tupeln zugeordnet ist, die sowohl eine Priorität als auch einen Hostnamen enthalten (an den die E-Mail zugestellt wird). Sie mischen zwei verschiedene Konzepte: Benennen (wer es auch senden soll) und Adressieren (wohin es senden soll).

— Patrick Mevzek

Antworten:

Bei E-Mails ist eine Domain nicht nur ein Alias oder eine für den Menschen lesbare Form für eine IP-Adresse. In den Mail Exchanger- MX Einträgen werden Mailserver angegeben, die für das Annehmen von E-Mail-Nachrichten im Namen der Domain eines Empfängers verantwortlich sind. Es können mehrere Server vorhanden sein, die E-Mails für die Domäne akzeptieren, und sie haben nicht unbedingt dieselbe IP, die im ADatensatz für die Domäne enthalten ist. Ein Mailsystem kann mehrere Server haben: Eingangsserver können von Ausgangsservern und Mailspeicherservern usw. getrennt sein. Der ADatensatz wird nur verwendet, wenn MXfür den Hostnamen keine Datensätze angegeben sind.

Es gibt jedoch keine (andere) Beschränkung im E-Mail-Adressformat, an die Sie keine E-Mails direkt senden können, <user@hostname.example.com>oder sogar <user@[198.51.100.10]>(IP mit den eckigen Klammern). Wenn es einen Mailserver gäbe, der E-Mails unter Verwendung des normalen Hostnamens oder sogar der IP-Adresse akzeptiert, würde dies funktionieren. Aber was Sie vorschlagen, funktioniert in der Praxis nicht global:

Die meisten E-Mail-Systeme haben mehrere Domänen und müssen E-Mails für alle separat verarbeiten. Der Benutzername selbst ist möglicherweise nicht an ein tatsächliches Postfach gebunden, da es sich <user@example.com>möglicherweise um eine andere Person handelt als<user@example.net>
Während dies vor einigen Jahrzehnten üblich war, hat der Kampf gegen Spam die Dinge komplizierter gemacht und das Akzeptieren von E-Mails hat strenge Grenzen.
Die Nutzung des SMTP-Ports 25ist bei Internetverbindungen für Endverbraucher aufgrund von Missbrauch (Spambots) sehr begrenzt. SMTP wird für IoT-Geräte nicht so häufig verwendet.

— Esa Jokinen
quelle

Wenn jedoch kein MX-DNS-Eintrag für eine Domain (oder eine IP-Adresse) vorhanden ist, wird die Mail an den Domain-Teil der E-Mail-Adresse (Hostname oder IP-Adresse) zugestellt (oder zugestellt zu werden versucht). Der empfangende Server muss so konfiguriert sein, dass er E-Mails für diesen Hostnamen / diese IP-Adresse verarbeitet.

— Ivanivan

Es kann E-Mails für den Hostnamen verarbeiten. Nicht jeder Server auf der Welt verarbeitet E-Mails. Die meisten Unix / Linux-basierten Server verfügen zwar über einen SMTP-Server für die Verarbeitung interner E-Mails (von Cron usw.), können jedoch auch ohne Server problemlos funktionieren.

— Esa Jokinen

Esa - Wenn Sie Ihren MX-Eintrag auf meine Postfix-Server verweisen, wird eine SMTP-Verbindung hergestellt, ABER meine Server sind nicht für die Verarbeitung von E-Mails für Ihre Domain in irgendeiner Form konfiguriert, sodass Sie einen Bounce erhalten. ABER meine Server sind für mehrere bestimmte Domänen und Benutzer eingerichtet, die alle von einem MySQL-Server stammen. Es hängt alles davon ab, 1) ob ein Mail-Server tatsächlich mit der IP-Adresse ausgeführt wird, an die Sie E-Mails senden, und 2) ob der Mail-Server so konfiguriert ist, dass er E-Mails für diese IP-Adresse oder nur für eine bestimmte Domain / Domains oder für eine Domain überhaupt (nur) akzeptiert mit dem benutzerteil der adresse übereinstimmen)

— ivanivan

Viele SMTP-Server (zB sendmail) verarbeiten user@[aaa.bbb.ccc.ddd]E-Mail-Adressen, ABER

Einige SMTP-Server können dies nicht verarbeiten / erkennen.
Sie können die Annahme dieser Absenderadresse verweigern oder nicht an diese Adresse senden.
Solche Adressen können bei einigen Antispamprogrammen zu Problemen führen

RFC-5322: 3.4.1. Addr-Spec Spezifikation

Wikipedia: E-Mail-Adresse - Domain-Teil

... , Außerdem kann die Domäne von eckigen Klammern [], wie jsmith @ [192.168.2.1] oder jsmith @ [:: 2001 db8 :: 1 IPv6] eine IP - Adresse wörtliche, umgeben sein , obwohl dies selten außer gesehen wird in E-Mail-Spam . …

— AnFi
quelle

Beachten Sie, dass E-Mail-Adressen wie z. B. user@[aaa.bbb.ccc.ddd]gemäß der Spezifikation korrekt sind und die Verarbeitung ordnungsgemäß definiert wurde.

— Daher

@Ferrybig: Stimmt, da das Ablehnen auch technisch geht.

— Esa Jokinen

Beachten Sie, dass "E-Mails an eine bestimmte IP-Adresse anstatt an einen Host gesendet wurden" in der Kategorie der "wahrscheinlich Spam" -Rotflaggen ziemlich hoch eingestuft ist und viele AVAS-Programme möglicherweise beschließen, sie stillschweigend zu verwerfen.

— Shadur

Es sollte funktionieren, wenn alle Beteiligten wirklich moderne Software verwenden.

Während SMTP auf TCP gut geschichtet arbeitet, ist es zumindest in seiner ursprünglichen Form kein auf TCP / IP basierendes Protokoll. Wenn Sie sich den Original-RFC 821 ansehen, wird in einem Anhang ein "TCP-Transport" definiert.

RFC 2821 (von 1989) erwägt die Verwendung von numerischen Adressen "entmutigt".

Noch weitaus modernere Versionen der Spezifikationen bestätigen diese Philosophie in gewissem Maße, und zwar in Bezug auf RFC5321: "SMTP ist unabhängig vom jeweiligen Übertragungssubsystem und erfordert nur einen zuverlässigen bestellten Datenstromkanal. Während dieses Dokument speziell den Transport über TCP beschreibt, sind andere Transporte möglich Die Anhänge zu RFC 821 [1] beschreiben einige von ihnen. "

In diesem RFC aus dem Jahr 2008, der es tatsächlich sehr NEU macht, wird die Verwendung von "Adressliteralen" als "zulässig" gebilligt ("Um diese Barriere zu umgehen, ist eine spezielle wörtliche Form der Adresse als Alternative zu einer Domäne zulässig name. ") in Abschnitt 4.1.3, rät jedoch davon ab," NICHT "in 2.1.4 zu sein.

SMTP und ein Großteil der darauf basierenden Software verwenden Hosts und keine IP-Adressen als "native Währung" - wenn ein "Adressliteral" als "Host" verwendet werden kann, sollte es so sein. Ebenso die (meist veralteten) Nicht-SMTP-Protokolle (z. B. UUCP-Mail), die in früheren E-Mail-Systemen zusammen mit SMTP-basierten Systemen verwendet wurden.

Es könnte riskanter sein, sich darauf zu verlassen, dass jedes beteiligte System den 2008er-Standards vollständig entspricht, als es scheint.

— Rackandboneman
quelle

RFC 5321 # 2.1.4 sanktioniert nicht die Verwendung von Adressliteralen: Es heißt NICHT (und verweist dann auf den falschen Abschnitt). Und RFC 2821 ist nicht ganz so alt - es war 2001.

— Rup

Ich würde sagen, das beweist meinen zwischen den Zeilen liegenden Punkt :) .. integrierte eine Klarstellung über diese "Mikrosanktion", danke

— rackandboneman