Можно ли отправлять и получать электронную почту с 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, легки и позволяют переопределять хосты. Интернет-IP будут меняться со временем.
Кригги

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-адреса.
ivanivan

1
Он может обрабатывать почту для имени хоста. Не каждый сервер в мире обрабатывает почту вообще. Большинство серверов на базе Unix / Linux имеют SMTP-сервер для обработки внутренней почты (из cron и т. Д.), Но они также могут нормально работать и без.
Эса Йокинен

1
Esa - если вы укажете свою запись MX на мои постфиксные серверы, будет установлено 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]являются правильными в соответствии со спецификацией, а обработка должным образом определена, поэтому серверы, которые не обрабатывают его, технически «сломаны»
Ferrybig

4
@Ferrybig: Верно, так как отклонение - это тоже техническая обработка.
Эса Йокинен,

Обратите внимание, что «электронное письмо было отправлено на определенный IP-адрес, а не на хост», занимает довольно высокое место в категории «вероятно, спам», и многие программы AVAS могут принять решение об их скрытом отбрасывании.
Шадур

3

Это должно работать, если все вовлеченные стороны используют действительно современное программное обеспечение.

Хотя SMTP хорошо работает на TCP, он, по крайней мере в своем первоначальном виде, сам по себе не является протоколом, основанным на TCP / IP. Если вы посмотрите на оригинальный RFC 821, в приложении определен «транспорт TCP» ....

RFC 2821 (от 1989 г.) считает использование числовых адресов «обескураженным».

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

Однако этот RFC - начиная с 2008 года, который фактически делает его НОВЫМ, разрешает использование «литералов адреса» как «разрешенных» («Чтобы обойти этот барьер, специальная литеральная форма адреса разрешена в качестве альтернативы домену»). name. ") в Разделе 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.