Para onde vai o email enviado para *@example.com? [fechadas]

88

Então, eu me pergunto isso há muito tempo.

Para onde o email é enviado *@example.com? Se eu enviasse informações confidenciais acidentalmente *@example.com, alguma pessoa má (potencialmente na IANA) seria capaz de recuperá-las algum dia?

email domain

— bryan kennedy
fonte

2

Se você estiver executando o Postfix como seu servidor SMTP, poderá usar o descarte ( postfix.org/discard.8.html ) para jogar fora os emails nos domínios do RFC 2606 (em vez de rejeitar).

— HTTP500 22/11/11

4

Alguém pode explicar por que isso foi migrado aqui e depois fechado? Comecei a pergunta no Stack Overflow, pois achava que era uma questão mais geral, mas acho que faz sentido que ela deva estar aqui relacionada a email e redes. Mas, obviamente, algumas pessoas experientes discordaram. Como e onde posso reabrir esta pergunta?

— Bryan kennedy

Se estiver fora do tópico aqui, tenho certeza que seria bom para os webmasters profissionais.

— usar o seguinte

Provavelmente, isso é melhor para Superusuários .

— MDMarra

1

Se você visitar example.com, ele diz que está reservado para fins ilustrativos e links para iana.org/domains/reserved

— usuário

48

Se você tentar enviar um email para *@example.com

Seu SMTP verificará se o domínio existe.
Seu servidor SMTP procurará um MXregistro em example.com.
Não existe: o seu SMTP voltará ao Aregistro. O IP é 174.137.125.92 (a partir de hoje)
A IANA registrou o domínio, mas não configurou um servidor SMTP que atende na porta 25 em 174.137.125.92.
Então o comportamento depende do seu SMTP. A maioria dos servidores enviará um aviso e tente novamente mais tarde. Eventualmente (geralmente em três dias), o SMTP descartará a mensagem e enviará uma notificação de falha.

Conclusão : Depende da sua própria configuração. Porém, se a IANA configurar um servidor hoje, eles poderão receber mensagens que você tentou enviar três dias atrás.

— rds
fonte

58

Se não houver registro MX, os servidores de correio tentarão enviar para o registro A.

Os servidores da example.com não escutam na porta 25; portanto, o servidor de email não estabelece uma conexão TCP e nem inicia a entrega.

50

example.com não possui registro MX, portanto, seu servidor SMTP no domínio de envio deve devolver a mensagem se configurado como a maioria dos servidores SMTP.

EDIT: para maior clareza para quem encontrar esta resposta no futuro, aqui está uma explicação do que é um registro MX: (em http://en.wikipedia.org/wiki/Mx_record recuperado em 21 de novembro de 2011)

Um registro de trocador de mensagens (registro MX) é um tipo de registro de recurso no Sistema de Nomes de Domínio que especifica um servidor de email responsável por aceitar mensagens de email em nome do domínio de um destinatário e um valor de preferência usado para priorizar a entrega de mensagens se vários servidores de email estiverem disponíveis . O conjunto de registros MX de um nome de domínio especifica como o email deve ser roteado com o Simple Mail Transfer Protocol.

Portanto, basicamente, example.com, example.net e example.org não têm um servidor designado para lidar com as mensagens recebidas e, portanto, todas as mensagens enviadas a eles devem ser devolvidas ao remetente como "não entregues" (podem variar de acordo com a configuração do servidor SMTP , mas retornar ao remetente como "não entregue" é um comportamento muito comum para essa situação).

EDIT 2: Alguém trouxe o comportamento definido pela RFC 5321 de voltar a usar o registro A no caso de um registro MX ausente. Eu procurei neste RFC ( http://tools.ietf.org/html/rfc5321 ) e não encontrei tal coisa, mas é possível que alguns MTAs (Mail Transfer Agent, como exim, postfix, sendmail e Microsoft Exchange Server, entre outros) podem tentar enviar email via SMTP para o endereço definido no registro A. Para a posteridade, eis o que acontece quando você tenta estabelecer uma conexão SMTP com o endereço de registro A definido para example.com (192.0.43.10 no momento da redação):

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

EDIT 3: veja as respostas abaixo para esclarecimentos sobre RFCs relevantes e comportamento de fallback.

— seanp2k
fonte

16

Sua resposta está incorreta - o RFC 5321 especifica que a resolução retorna aos Aregistros quando nenhum MXregistro existe (a "regra implícita do MX"); veja a seção 5.1 . Se uma lista vazia de MXs for retornada, o endereço será tratado como se estivesse associado a um RR MX implícito, com uma preferência de 0, apontando para esse host.

— josh3736

1

Além disso, SMTP tem sempre teve um retorno para Agovernar - não foi introduzido com 5321.

— josh3736

1

De RFC 974 (973 e 974 introduziu o registro 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 O SMTP nunca especificou que recuou dos registros MD e MF para A RRs. De fato, o RFC 821 não menciona exatamente como usar o arquivo HOSTS (o DNS não existia no momento) para procurar o servidor remoto. No entanto, você está certo de que o MX deve retornar aos registros A, de acordo com a RFC 974. Isso foi codificado porque já era uma prática comum, sendo os registros MD e MF excessivamente complicados e geralmente não utilizados.

— Chris S

Obrigado a todos por seus esclarecimentos - eu aprendi bastante com isso.

— seanp2k

19

A autoridade de número atribuído à Internet:

Domínios de exemplo

Conforme descrito na RFC 2606 , mantemos vários domínios como EXAMPLE.COM e EXAMPLE.ORG para fins de documentação. Esses domínios podem ser usados como exemplos ilustrativos em documentos sem coordenação prévia conosco. Eles não estão disponíveis para registro.

— Hot Licks
fonte

15

Sua resposta não responde à pergunta.

7

@ George Por que não? A IANA é proprietária dos domínios, portanto, mesmo que não exista MX a partir de hoje, a IANA poderá configurar um no futuro e começar a receber e-mails, por exemplo. * Domínios. Esta é a melhor resposta na minha opinião.

— Eduardocereto