Gdzie trafia wiadomość e-mail na adres *@example.com? [Zamknięte]


88

Zastanawiałem się przez długi czas.

Gdzie wysyłany jest e-mail *@example.com? Gdybym przypadkowo wysłał poufne informacje, *@example.comczy jakaś zła osoba (potencjalnie na IANA) mogłaby je kiedyś odzyskać?


2
Jeśli korzystasz z Postfix jako serwera SMTP, możesz użyć opcji discard ( postfix.org/discard.8.html ), aby wyrzucać wiadomości e-mail do domen RFC 2606 (zamiast odrzuceń).
HTTP500

4
Czy ktoś może wyjaśnić, dlaczego migrowano tutaj, a następnie zamknięto? Zacząłem pytanie na temat przepełnienia stosu, ponieważ myślałem, że jest to bardziej ogólny problem, ale myślę, że ma sens, aby był tutaj związany z pocztą elektroniczną i siecią. Ale oczywiście niektórzy doświadczeni ludzie się nie zgadzali. Jak i gdzie mogę ponownie otworzyć to pytanie?
bryan kennedy

Jeśli jest to poza tematem tutaj, jestem pewien, że byłoby dobrze u profesjonalnych webmasterów.
Disgruntled Goo

Jest to prawdopodobnie najlepsze rozwiązanie dla superużytkownika .
MDMarra,

1
Jeśli odwiedzasz example.com, jest napisane, że jest zarezerwowane w celach ilustracyjnych i linki do iana.org/domains/reserved
użytkownik

Odpowiedzi:


48

Jeśli spróbujesz wysłać wiadomość e-mail na adres *@example.com

  1. Twój SMTP sprawdzi, czy domena istnieje.
  2. Twój serwer SMTP wyszuka MXrekord pod adresem example.com.
  3. Nie ma żadnego: Twój SMTP wróci do Arekordu. Adres IP to 174.137.125.92 (na dzień dzisiejszy)
  4. IANA zarejestrowała domenę, ale nie skonfigurowała serwera SMTP nasłuchującego na porcie 25 na 174.137.125.92.
  5. To zachowanie zależy od Twojego SMTP. Większość serwerów wyśle ​​ostrzeżenie i spróbuj ponownie później. W końcu (zwykle za 3 dni) SMTP odrzuci wiadomość i wyśle ​​Ci powiadomienie o niepowodzeniu.

Konkluzja : To zależy od twojej konfiguracji. Ale jeśli IANA skonfiguruje dziś serwer, być może będą w stanie odbierać wiadomości, które próbujesz wysłać 3 dni temu.


58

Jeśli nie ma rekordu MX, serwery pocztowe podejmą próbę dostarczenia do rekordu A.

Serwery example.com nie nasłuchują na porcie 25, więc serwer pocztowy nie nawiąże połączenia TCP i nawet nie rozpocznie dostarczania.


50

example.com nie ma rekordu MX, więc serwer SMTP w domenie wysyłającej powinien odesłać wiadomość, jeśli jest skonfigurowany tak, jak większość serwerów SMTP.

EDYCJA: dla jasności dla tych, którzy znajdą tę odpowiedź w przyszłości, oto wyjaśnienie, czym jest rekord MX: (z http://en.wikipedia.org/wiki/Mx_record 21 listopada 2011)

Rekord wymieniacza poczty (rekord MX) jest rodzajem rekordu zasobów w systemie nazw domen, który określa serwer pocztowy odpowiedzialny za przyjmowanie wiadomości e-mail w imieniu domeny odbiorcy oraz wartość preferencji używaną do priorytetyzacji dostarczania poczty, jeśli dostępnych jest wiele serwerów poczty . Zestaw rekordów MX nazwy domeny określa, w jaki sposób poczta e-mail powinna być kierowana za pomocą protokołu Simple Mail Transfer Protocol.

Zasadniczo więc example.com, example.net i example.org nie mają wyznaczonego serwera do obsługi poczty przychodzącej, dlatego każda poczta wysłana do nich powinna zostać zwrócona nadawcy jako „niemożliwa do dostarczenia” (może się różnić w zależności od konfiguracji serwera SMTP , ale powrót do nadawcy jako „niemożliwy do dostarczenia” to bardzo częste zachowanie w tej sytuacji).

EDYCJA 2: Ktoś przywołał zdefiniowane zachowanie RFC 5321 polegające na powrocie do używania rekordu A w przypadku braku rekordu MX. Przeszukałem to RFC ( http://tools.ietf.org/html/rfc5321 ) i nie znalazłem czegoś takiego, ale możliwe jest, że niektóre MTA (Mail Transfer Agent, takie jak exim, postfix, sendmail i Microsoft Exchange Server, między inni) mogą próbować dostarczyć pocztę za pośrednictwem SMTP na adres zdefiniowany w rekordzie A. Dla potomnych, oto co dzieje się, gdy próbujesz nawiązać połączenie SMTP ze zdefiniowanym adresem rekordu A na przykład.com (192.0.43.10 w momencie pisania):

$ telnet 192.0.43.10 25
Trying 192.0.43.10...
telnet: Unable to connect to remote host: Connection timed out

EDYCJA 3: patrz odpowiedzi poniżej, aby uzyskać wyjaśnienia dotyczące odpowiednich RFC i zachowania awaryjnego.


16
Twoja odpowiedź jest nieprawidłowa - RFC 5321 określa, że ​​rozdzielczość wraca do Arekordów, gdy nie MXistnieje żaden rekord („domyślna reguła MX”); patrz punkt 5.1 . Jeśli zwrócona zostanie pusta lista MX, adres jest traktowany tak, jakby był powiązany z niejawną RR RR, z preferencją 0, wskazując na ten host.
josh3736,

1
Ponadto, SMTP ma zawsze miał funkcję powrotu do Aorzekania - nie została wprowadzona w 5321.
josh3736

1
Z RFC 974 (973 i 974 wprowadzili rekord 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).
Chris S

2
@ josh3736 SMTP nigdy nie określił, że wycofał się z rekordów MD i MF do RR. W rzeczywistości RFC 821 nie wspomina o tym, jak dokładnie użyć pliku HOSTS (w tym czasie DNS nie istniał) do wyszukiwania zdalnego serwera. Masz jednak rację, że MX musi wrócić do rekordów A, zgodnie z RFC 974. Zostało to skodyfikowane, ponieważ było to już powszechną praktyką, ponieważ rekordy MD i MF są zbyt skomplikowane i zwykle nieużywane.
Chris S

Dziękuję wszystkim za wyjaśnienia - wiele się z tego nauczyłem.
seanp2k

19

Internetowy organ przypisany do numeru:

Przykładowe domeny

Jak opisano w RFC 2606 , utrzymujemy wiele domen, takich jak EXAMPLE.COM i EXAMPLE.ORG do celów dokumentacji. Domeny te można wykorzystać jako ilustracyjne przykłady w dokumentach bez uprzedniej koordynacji z nami. Nie są dostępne do rejestracji.


15
Twoja odpowiedź nie odpowiada na pytanie.

7
@George Dlaczego nie? IANA jest właścicielem domen, więc nawet jeśli na dzień dzisiejszy nie ma MX, IANA może skonfigurować ją w przyszłości i zacząć otrzymywać e-maile na przykład. * Domeny. To jest najlepsza odpowiedź moim zdaniem.
eduardocereto
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.