Куда отправляется электронная почта, отправленная на *@example.com? [закрыто]
88
Так что я долго думал об этом.
Куда отправляется электронная почта *@example.com? Если бы я случайно отправил конфиденциальную информацию *@example.comкому-нибудь, возможно, когда-нибудь злой человек (возможно, в IANA) сможет ее получить?
Если вы используете Postfix в качестве SMTP-сервера, вы можете использовать discard ( postfix.org/discard.8.html ), чтобы выбрасывать электронные письма в домены RFC 2606 (а не отказов).
HTTP500
4
Может кто-нибудь объяснить, почему это было перенесено сюда, а затем закрыто? Я начал вопрос о переполнении стека, так как думал, что это более общая проблема, но я думаю, что в этом есть смысл, связанный с электронной почтой и сетями. Но очевидно, что некоторые опытные люди не согласны. Как и где я могу получить этот вопрос снова?
Брайан Кеннеди
Если это не по теме здесь, я уверен, что это будет хорошо для профессиональных веб-мастеров.
Рассерженная шлюха
Это, вероятно, лучше всего подходит для Super User .
MDMarra
1
Если вы посещаете сайт example.com, он говорит, что он зарезервирован для иллюстративных целей и содержит
пользователь
Ответы:
48
Если вы пытаетесь отправить письмо на *@example.com
Ваш SMTP проверит, существует ли домен.
Ваш SMTP-сервер будет искать MXзапись в example.com.
Там нет ничего: ваш SMTP откатится на Aзапись. IP 174.137.125.92 (на сегодняшний день)
IANA зарегистрировала домен, но не настроила SMTP-сервер, прослушивающий порт 25 174.137.125.92.
Тогда поведение зависит от вашего SMTP. Большинство серверов отправят вам предупреждение, и повторите попытку позже. В конце концов (обычно через 3 дня) SMTP отклонит сообщение и отправит вам уведомление о сбое.
Итог : это зависит от вашей собственной конфигурации. Но если IANA настроит сервер сегодня, они могут получать сообщения, которые вы пытались отправить 3 дня назад.
На example.com нет записи MX, поэтому ваш SMTP-сервер в отправляющем домене должен отослать сообщение, если настроено большинство SMTP-серверов.
РЕДАКТИРОВАТЬ: для ясности тем, кто найдет этот ответ в будущем, вот объяснение того, что такое запись MX: (из http://en.wikipedia.org/wiki/Mx_record, полученной 21 ноября 2011 г.)
Запись почтового обменника (запись MX) - это тип записи ресурса в системе доменных имен, который указывает почтовый сервер, отвечающий за прием сообщений электронной почты от имени домена получателя, и значение предпочтения, используемое для определения приоритетов доставки почты, если доступно несколько почтовых серверов. , Набор MX-записей доменного имени указывает, как следует направлять электронную почту по протоколу Simple Mail Transfer Protocol.
Таким образом, в основном, у example.com, example.net и example.org нет сервера, назначенного для обработки входящей почты, и поэтому любая отправленная им почта должна быть возвращена отправителю как «недоставленная» (может варьироваться в зависимости от конфигурации сервера SMTP , но возвращение отправителю как «невозможности доставки» является очень распространенным поведением в этой ситуации).
РЕДАКТИРОВАТЬ 2: Кто-то поднял определенное в RFC 5321 поведение возврата к использованию записи A в случае отсутствия записи MX. Я искал этот RFC ( http://tools.ietf.org/html/rfc5321 ) и не нашел ничего подобного, но возможно, что некоторые MTA (Mail Transfer Agent, такие как exim, postfix, sendmail и Microsoft Exchange Server, среди другие) могут попытаться доставить почту через SMTP на адрес, указанный в записи A. Что касается потомков, то вот что происходит, когда вы пытаетесь установить SMTP-соединение с определенным адресом записи A для example.com (192.0.43.10 на момент написания):
$ telnet 192.0.43.10 25
Trying 192.0.43.10...
telnet: Unable to connect to remote host: Connection timed out
РЕДАКТИРОВАТЬ 3: см. Ответы ниже для разъяснений по соответствующим RFC и аварийному поведению.
Ваш ответ неверен - RFC 5321 указывает, что разрешение возвращается к Aзаписям, когда записи не MXсуществует («неявное правило MX»); см. раздел 5.1 . Если возвращается пустой список MX, адрес обрабатывается так, как если бы он был связан с неявным MX RR с предпочтением 0, указывающим на этот хост.
Из RFC 974 (973 и 974 представили запись MX)It is possible that the list of MXs in the response to the query will be empty. This is a special case. If the list is empty, mailers should treat it as if it contained one RR, an MX RR with a preference value of 0, and a host name of REMOTE. (I.e., REMOTE is its only MX).
Крис С
2
@ josh3736 SMTP никогда не указывал, что он возвращался от записей MD & MF к A RR. Фактически, RFC 821 не упоминает, как именно использовать файл HOSTS (DNS не существовал в то время) для поиска удаленного сервера. Однако вы правы в том, что MX должен возвращаться к записям A согласно RFC 974. Это было кодифицировано, потому что это уже стало обычной практикой, записи MD и MF чрезмерно сложны и обычно не используются.
Крис С
Спасибо всем за разъяснения - я многому научился из этого.
Как описано в RFC 2606 , мы поддерживаем несколько доменов, таких как EXAMPLE.COM и EXAMPLE.ORG для целей документирования. Эти домены могут использоваться в качестве иллюстративных примеров в документах без предварительного согласования с нами. Они не доступны для регистрации.
@ Джордж почему бы и нет? IANA владеет доменами, поэтому даже если на сегодняшний день MX не существует, IANA может создать его в будущем и начать получать электронные письма, например. * Domains. Это лучший ответ на мой взгляд.
Ответы:
Если вы пытаетесь отправить письмо на
*@example.com
MX
запись вexample.com
.A
запись. IP 174.137.125.92 (на сегодняшний день)Итог : это зависит от вашей собственной конфигурации. Но если IANA настроит сервер сегодня, они могут получать сообщения, которые вы пытались отправить 3 дня назад.
источник
Если запись MX отсутствует, почтовые серверы будут пытаться доставить запись A.
Серверы example.com не прослушивают порт 25, поэтому почтовый сервер не установит TCP-соединение и даже не начнет доставку.
источник
На example.com нет записи MX, поэтому ваш SMTP-сервер в отправляющем домене должен отослать сообщение, если настроено большинство SMTP-серверов.
РЕДАКТИРОВАТЬ: для ясности тем, кто найдет этот ответ в будущем, вот объяснение того, что такое запись MX: (из http://en.wikipedia.org/wiki/Mx_record, полученной 21 ноября 2011 г.)
Таким образом, в основном, у example.com, example.net и example.org нет сервера, назначенного для обработки входящей почты, и поэтому любая отправленная им почта должна быть возвращена отправителю как «недоставленная» (может варьироваться в зависимости от конфигурации сервера SMTP , но возвращение отправителю как «невозможности доставки» является очень распространенным поведением в этой ситуации).
РЕДАКТИРОВАТЬ 2: Кто-то поднял определенное в RFC 5321 поведение возврата к использованию записи A в случае отсутствия записи MX. Я искал этот RFC ( http://tools.ietf.org/html/rfc5321 ) и не нашел ничего подобного, но возможно, что некоторые MTA (Mail Transfer Agent, такие как exim, postfix, sendmail и Microsoft Exchange Server, среди другие) могут попытаться доставить почту через SMTP на адрес, указанный в записи A. Что касается потомков, то вот что происходит, когда вы пытаетесь установить SMTP-соединение с определенным адресом записи A для example.com (192.0.43.10 на момент написания):
РЕДАКТИРОВАТЬ 3: см. Ответы ниже для разъяснений по соответствующим RFC и аварийному поведению.
источник
A
записям, когда записи неMX
существует («неявное правило MX»); см. раздел 5.1 . Если возвращается пустой список MX, адрес обрабатывается так, как если бы он был связан с неявным MX RR с предпочтением 0, указывающим на этот хост.A
правилу - он не был представлен с 5321.It is possible that the list of MXs in the response to the query will be empty. This is a special case. If the list is empty, mailers should treat it as if it contained one RR, an MX RR with a preference value of 0, and a host name of REMOTE. (I.e., REMOTE is its only MX).
Управление по присвоению номеров в Интернете:
Примеры доменов
Как описано в RFC 2606 , мы поддерживаем несколько доменов, таких как EXAMPLE.COM и EXAMPLE.ORG для целей документирования. Эти домены могут использоваться в качестве иллюстративных примеров в документах без предварительного согласования с нами. Они не доступны для регистрации.
источник