Чи можна надсилати та отримувати електронний лист із IP-адреси замість домену?


18

Зазвичай електронний лист має доменне ім’я праворуч від сторінки @, тож ви можете визначити організацію чи компанію. Цей домен насправді є не що інше, як "ім'я" або "псевдонім" для IP-адреси, вирішений сервером імен.

Я думаю, що це можна використати, наприклад, для Інтернету речей, тому що існує набагато більше можливостей порівняно з POST та GET, як "багато до одного" або "один до багатьох".

Чи є спосіб надсилати та отримувати електронні листи безпосередньо до та з IP-адреси, як, наприклад, user@xxx.xxx.xx.xxx?


6
Убік: Якщо ви вважаєте, що HTTP є занадто обмежувальним для IoT, подивіться на MQTT або XMPP.
Роджер Ліпскомб

3
Домен - це більше ніж "ім'я для IP-адреси". Домен може публікувати набагато більше інформації щодо своєї поштової служби (через свої записи DNS), яка може включати декілька IP-адрес для декількох поштових серверів (тобто для цілей балансування або резервного завантаження).
jjmontes

4
Електронна пошта - це не один для багатьох, це один до одного, і тоді сервер може поширити повідомлення для багатьох. Ви можете зробити http-повідомлення на сервері, а потім багато клієнтів зачитують цей сервер у такій самій моделі електронної пошти.
djsmiley2k у темряві

2
Оскільки хтось, кому періодично доводиться займатися мережевою археологією, будь ласка, не жорстко кодуйте IP-адреси. DNS не є складним, і DNS-сервери, такі як dnsmasq, мають невелику вагу, дозволяючи переосмислити хост. Інтернет-адреси змінюватимуться з часом.
Criggie

1
Домен не є псевдонімом для IP-адреси. Зокрема, електронна пошта має записи MX, де доменне ім’я відображається на один або кілька кортежів, що містять як пріоритет, так і ім’я хоста (куди буде доставлено електронний лист). Ви змішуєте два різних поняття: іменування (кому його теж надіслати) та адресація (куди його надіслати).
Патрік Мевзек

Відповіді:


17

Для електронної пошти, домен не просто псевдонім або формі, що дозволяє людей для IP - адреси: поштову обмінник MX запис існує , щоб вказати поштові сервера , відповідальні за прийом повідомлень електронної пошти від імені домена одержувача. Може бути декілька серверів, які приймають пошту для домену, і вони не обов'язково знаходяться на одному IP-адресі, який Aзаписаний для домену. Поштова система може мати декілька серверів: вхідні сервери можуть бути відокремлені від вихідних серверів та серверів зберігання пошти тощо. AЗапис використовується лише тоді, коли MXдля імені хоста не вказано записів.

Тим НЕ менше, немає (інших) обмежень в форматі електронної пошти , який ви не могли відправляти електронну пошту безпосередньо <user@hostname.example.com>або навіть <user@[198.51.100.10]>(IP з квадратними дужками). Якби був поштовий сервер, який приймає електронну пошту, використовуючи звичайне ім’я хоста або навіть IP-адресу, це зробить це. Але те, що ви пропонуєте, на практиці не працює в усьому світі:

  • Більшість систем електронної пошти мають декілька доменів, і для них потрібно обробляти пошту окремо. Саме ім'я користувача не може бути прив’язане до жодної фактичної поштової скриньки, оскільки це <user@example.com>може бути інша особа, ніж<user@example.net>
  • Хоча це було поширено пару десятиліть тому, боротьба зі спамом ускладнила справи, а прийняття електронної пошти має суворі межі.
  • Використання порту SMTP 25дуже обмежене на споживчих підключеннях до Інтернету через зловживання (спам-боти). Насправді не так багато використання SMTP для пристроїв IoT.

2
Але якщо немає запису MX dns для домену (або IP), пошта доставляється (або намагається бути доставлена) доменній частині адреси електронної пошти (ім'я хоста або IP-адреса). І сервер прийому повинен бути налаштований для обробки пошти для цього імені хоста / IP-адреси.
іваніван

1
Він може обробляти пошту для імені хоста. Не кожен сервер у світі взагалі обробляє пошту. Більшість серверів на базі Unix / Linux мають SMTP-сервер для обробки внутрішньої пошти (від cron тощо), але вони також можуть добре функціонувати і без них.
Еса Йокінен

1
Esa - якщо ви вкажете ваш запис MX на мої сервери Postfix, буде встановлено SMTP-з'єднання, АЛЕ мої сервери не налаштовані на обробку пошти для вашого домену в будь-якій формі та формі, тому ви отримуєте відмов. АЛЕ мої сервери налаштовані для декількох конкретних доменів та користувачів, які походять з сервера mysql. Все залежить від 1) Чи дійсно поштовий сервер працює під час IP-адреси, на яку ви надсилаєте пошту, і 2) Чи налаштований вказаний поштовий сервер, щоб приймати пошту, призначену для цього IP-адреси, або просто певний домен / домени, або будь-який домен взагалі (тільки що відповідає користувацькій частині адреси)
ivanivan

13

Багато SMTP-серверів (наприклад, sendmail) обробляють user@[aaa.bbb.ccc.ddd]адреси електронної пошти, АЛЕ

  1. Деякі SMTP-сервери не обробляють / не розпізнають їх.
    Вони можуть відмовитись прийняти таку адресу відправника або не зможуть надіслати таку адресу.
  2. Такі адреси можуть спричинити проблеми з деяким анти-спам-програмним забезпеченням

RFC-5322: 3.4.1. Специфікація Addr-Spec


Вікіпедія: Адреса електронної пошти - частина домену

... Крім того, домен може бути буквальним для IP-адреси, оточеним квадратними дужками [], такими як jsmith @ [192.168.2.1] або jsmith @ [IPv6: 2001: db8 :: 1], хоча це рідко можна побачити, крім електронний спам .


9
Зауважте, що такі адреси електронної пошти user@[aaa.bbb.ccc.ddd]є правильними відповідно до специфікації, а обробка правильно визначена, тому сервери, які не обробляють її, технічно "порушені"
Феррібіг

4
@Ferrybig: Правда, оскільки відхилення також технічно поводиться.
Еса Йокінен

Зауважте, що "електронний лист був надісланий на конкретну IP-адресу, а не на хост" досить високо входить до категорії "ймовірно спаму" червоних прапорів, і багато програмного забезпечення AVAS можуть вирішити мовчки відкинути його.
Шадур

3

Це має спрацювати, якщо всі залучені сторони використовують дійсно сучасне програмне забезпечення.

Хоча SMTP працює на багатошаровому шарі TCP, він, принаймні, у первісному вигляді, сам по собі не є протоколом, заснованим на TCP / IP. Якщо ви подивитеся на оригінальний RFC 821, "транспорт TCP" визначений .... у додатку.

RFC 2821 (з 1989 р.) Вважає використання числових адрес "неприборканими".

Навіть набагато сучасніші версії специфікацій певною мірою підтверджують цю філософію від RFC5321: "SMTP не залежить від конкретної підсистеми передачі і вимагає лише надійного упорядкованого каналу потоку даних. Хоча в цьому документі конкретно обговорюється транспорт через TCP, можливі й інші транспортні засоби. . Додатки до RFC 821 [1] описують деякі з них ".

Однак цей RFC - з 2008 року, що насправді робить його НОВОЮ, але санкціонує використання "адресних літералів" як "дозволених" ("Щоб обійти цей бар'єр, спеціальна буквальна форма адреси дозволена як альтернатива домену назва. ") у Розділі 4.1.3, але все-таки відбиває це як" ПОТРІБНО "у 2.1.4.

SMTP та велика частина програмного забезпечення, побудованого навколо нього, використовує хости , а не ip адреси як свою "рідну валюту" - якщо "адресна буква" може бути використана як "хост", так і нехай буде. Так само зробили (здебільшого застарілі) протоколи, що не належать до SMTP (наприклад, пошта UUCP), які використовувались у екосистемі електронної пошти старої системи разом із системами на основі SMTP.

Покладатися на те, що вся система, що займається повною мірою, відповідає стандарту 2008 року, може бути більш ризикованою, ніж здається.


2
RFC 5321 # 2.1.4 не санкціонує використання літералів адреси: він говорить ДОЛЖЕНО (а потім посилається на неправильний розділ). І RFC 2821 не зовсім такий старий - це було 2001.
Rup

1
Я б сказав, це підтверджує мою між точками рядків :) .. інтегрував роз'яснення щодо того, що "мікро санкція", thx
rackandboneman
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.