È possibile inviare e ricevere un'e-mail da un indirizzo IP anziché da un dominio?

Di solito un'e-mail ha un nome di dominio sul lato destro di @, quindi è possibile identificare un'organizzazione o un'azienda. Questo dominio non è altro che un "nome" o un "alias" per un indirizzo IP, risolto dal server dei nomi.

Penso che questo potrebbe essere usato ad esempio per l'Internet of Things, perché ci sono molte più possibilità rispetto a POST e GET come "many to one" o "one to many".

Esiste un modo per inviare e ricevere e-mail direttamente da e verso un indirizzo IP, ad esempio user@xxx.xxx.xx.xxx?

email smtp email-server

— Peter Mortensen
fonte

A parte: se ritieni che HTTP sia troppo restrittivo per l'IoT, dai un'occhiata a MQTT o XMPP.

— Roger Lipscombe,

Un dominio è più di "un nome per un indirizzo IP". Un dominio può pubblicare molte più informazioni relative al suo servizio di posta (tramite le sue voci DNS), che possono includere diversi indirizzi IP per diversi server di posta (ad esempio per bilanciamento del carico o scopi di fallback).

— jjmontes,

Neanche l'e-mail è una a molte, è una a una e quindi il server può diffondere il messaggio a molte. È possibile eseguire un post http su un server, quindi fare in modo che molti client leggano quel server nello stesso identico modello utilizzato dall'email.

— djsmiley2k - CoW

Come qualcuno che deve periodicamente fare archeologia di rete, per favore non codificare gli IP. Il DNS non è difficile e i server DNS come dnsmasq sono leggeri e consentono l'override dell'host. Gli IP Internet cambieranno nel tempo.

— Criggie,

Il dominio non è un alias per un indirizzo IP. In particolare, l'e-mail contiene record MX in cui il nome di dominio è associato a una o più tuple contenenti sia una priorità che un nome host (dove verrà recapitata l'e-mail). Stai mescolando due concetti diversi: denominazione (anche a chi inviarlo) e indirizzo (dove inviarlo).

— Patrick Mevzek,

Risposte:

Per le e-mail, un dominio non è semplicemente un alias o un modulo leggibile dall'uomo per un indirizzo IP: esistono record di scambiatori di posta MX per specificare i server di posta responsabili dell'accettazione dei messaggi di posta elettronica per conto del dominio di un destinatario. Potrebbero esserci diversi server che accettano posta per il dominio e non sono necessariamente sullo stesso IP presente nel Arecord per il dominio. Un sistema di posta può avere diversi server: i server in entrata potrebbero essere separati dai server in uscita e dai server di archiviazione della posta ecc. Il Arecord viene utilizzato solo quando non sono stati MXspecificati record per il nome host.

Tuttavia, non esiste un (altro) limite nel formato dell'indirizzo e-mail a cui non è possibile inviare e-mail direttamente <user@hostname.example.com>o addirittura <user@[198.51.100.10]>(IP con parentesi quadre). Se esistesse un mailserver che accetta e-mail utilizzando il semplice nome host o anche l'indirizzo IP, lo farebbe. Ma ciò che stai suggerendo non funziona a livello globale nella pratica:

La maggior parte dei sistemi di posta elettronica ha diversi domini e deve gestire la posta separatamente per tutti. Lo stesso nome utente potrebbe non essere stato associato a nessuna casella di posta reale in quanto <user@example.com>potrebbe essere una persona diversa da<user@example.net>
Mentre questo era comune un paio di decenni fa, la lotta contro lo spam ha reso le cose più complicate e accettare e-mail ha limiti rigorosi.
L'uso della porta SMTP 25è molto limitato sulle connessioni Internet di livello consumer a causa di abusi (spambots). Non c'è davvero molto uso di SMTP per dispositivi IoT.

— Esa Jokinen
fonte

Ma se non è presente alcun record DNS dns per un dominio (o un IP), la posta viene recapitata (o tentata di essere consegnata) alla parte del dominio dell'indirizzo e-mail (nome host o indirizzo IP). E il server di ricezione deve essere configurato per gestire la posta per quel nome host / indirizzo IP.

— ivanivan,

E ' in grado di gestire la posta per il nome host. Non tutti i server al mondo gestiscono affatto la posta. La maggior parte dei server basati su Unix / Linux hanno un server SMTP per gestire la posta interna (da cron ecc.), Ma possono funzionare anche senza.

— Esa Jokinen,

Esa - se punti i tuoi record MX sui miei server postfix, verrà stabilita una connessione SMTP MA i miei server non sono configurati per gestire la posta per il tuo dominio in qualsiasi forma o forma, in modo da ottenere un rimbalzo. MA i miei server sono impostati per più domini e utenti specifici, tutti provenienti da un server mysql. Tutto dipende da 1) È un server di posta effettivamente in esecuzione sull'IP a cui si sta inviando la posta e 2) È detto server di posta configurato per accettare la posta destinata a quell'IP o solo un dominio / domini specifici o qualsiasi dominio (solo corrispondente alla parte dell'utente dell'indirizzo)

— ivanivan

Molti server SMTP (ad esempio sendmail) gestiscono user@[aaa.bbb.ccc.ddd]gli indirizzi e-mail MA

Alcuni server SMTP non lo gestiscono / non riconoscono
Potrebbero rifiutare di accettare tale indirizzo del mittente o non essere in grado di inviare a tale indirizzo.
Tali indirizzi possono causare problemi con alcuni software anti-spam

RFC-5322: 3.4.1. Specifiche specifiche addr

Wikipedia: indirizzo e-mail - parte del dominio

... Inoltre, il dominio può essere un indirizzo IP letterale, racchiuso tra parentesi quadre [], come jsmith @ [192.168.2.1] o jsmith @ [IPv6: 2001: db8 :: 1], sebbene ciò sia visto raramente tranne che in email spam . ...

— ANFI
fonte

Si noti che gli indirizzi di posta elettronica come user@[aaa.bbb.ccc.ddd]sono corretti in base alle specifiche e che la gestione è definita in modo appropriato, quindi i server che non lo gestiscono sono tecnicamente "rotti"

— Ferrybig

@Ferrybig: Vero, poiché anche il rifiuto è tecnicamente gestibile.

— Esa Jokinen,

Si noti che "la posta elettronica è stata inviata a un indirizzo IP specifico anziché a un host" si colloca piuttosto in alto nella categoria delle bandiere rosse "probabilmente spam" e molti software AVAS potrebbero decidere di scartarla silenziosamente.

— Shadur,

Dovrebbe funzionare se tutte le parti interessate utilizzano un software davvero moderno.

Mentre SMTP funziona bene a strati su TCP, è, almeno nella sua forma originale, non in sé un protocollo BASATO su TCP / IP. Se si osserva la RFC 821 originale, viene definito un "trasporto TCP" .... in un'appendice.

RFC 2821 (dal 1989) considera l'uso di indirizzi numerici "scoraggiato".

Anche le versioni molto più moderne delle specifiche sostengono in una certa misura questa filosofia, da RFC5321: "SMTP è indipendente dal particolare sottosistema di trasmissione e richiede solo un canale di flusso di dati ordinato affidabile. Mentre questo documento tratta specificamente il trasporto su TCP, sono possibili altri trasporti Le appendici a RFC 821 [1] ne descrivono alcune. "

Tuttavia, questo RFC - dal 2008, che in realtà lo rende NUOVO, sanziona l'uso di "indirizzi letterali" come "consentiti" ("Per aggirare questa barriera, è consentita una speciale forma letterale dell'indirizzo come alternativa a un dominio nome ") nella Sezione 4.1.3 ma lo scoraggia ancora come" NON DOVREBBE "in 2.1.4.

SMTP, e gran parte del software costruito attorno ad esso, utilizza gli host , non gli indirizzi IP , come "valuta nativa" - se un "indirizzo letterale" è utilizzabile come "host", così sia. E così hanno fatto i protocolli (non più obsoleti) non SMTP (ad esempio la posta UUCP) che sono stati utilizzati nell'ecosistema di posta elettronica di vecchia data insieme ai sistemi basati su SMTP.

Affidarsi a tutti i sistemi coinvolti nel pieno rispetto di uno standard del 2008 potrebbe essere più rischioso di quanto sembri.

— rackandboneman
fonte

RFC 5321 # 2.1.4 non sanziona usando i letterali degli indirizzi: dice NON DOVREBBE (e quindi collegamenti alla sezione sbagliata). E RFC 2821 non è poi così vecchio - era il 2001.

— Rup

Direi che questo dimostra il mio punto tra le righe :) .. integrato un chiarimento su quella "micro-sanzione", grazie

— rackandboneman,