Mesmo que seja apenas uma breve olhada no protocolo SMTP, você notará que além do HELO usual, há também o EHLO, que faz Estendido O servidor SMTP anuncia seus recursos além do padrão original. Um deles é o DSN. DSN? DNA e DDT não são suficientes?
Para argumentar que o email não é confiável, esse alguém deveria " … alimentar melhor o servidor deles; ele comeu meu e-mail … "não é incomum. No entanto, não há muitas razões para apoiar essas suspeitas.
Entrega S tatus N A otificação existe desde a RFC 821 (de 1982). Assim que a parte DATA do protocolo SMTP for concluída e o servidor aceitar o email para entrega, ele será responsável por ele. Se por algum motivo não conseguir passar para o destinatário, deverá enviá-lo de volta com a notificação do erro ao remetente original. Isso resultou em algum e-mail obscuro.
Além disso, essa antiga convenção significava que ou você recebeu uma mensagem de erro ou nada Nesse caso, você sabia nada : o email pode ter chegado ou não. As mensagens de erro em muitos casos foram tão úteis quanto nenhuma mensagem de erro. Com o e-mail se tornando cada vez mais importante, isso não é mais satisfatório (como se fosse antes).
Extensões de DSN para SMTP
A RFC 1891 propõe algumas extensões para o protocolo SMTP que devem resultar em um sistema DSN mais confiável e mais utilizável. É um conjunto de extensões para os comandos MAIL e RCPT.
Sem EHLO, sem diversão
Primeiro, temos que ter certeza de que o servidor suporta DSN. Assim, temos que dizer EHLO para ele e ouvir atentamente. Se responder com o DSN em algum lugar da lista de recursos, podemos supor que ele poderá atender às nossas solicitações. Se não, então não: podemos tentar outro servidor ou simplesmente voltar para o e-mail sem DSN. Por exemplo:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Dom, 24 ago 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Olá localhost 127.0.0.1, prazer em conhecê-lo250-EXPN250-VERBO250-8BITMIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 AJUDA Felizmente, entre outras coisas, encontramos DSN. O próximo comando normalmente é MAIL FROM. Com o DSN, isso não é diferente. Mas há duas opções adicionais que você pode emitir: RET e ENVID. A opção RET foi colocada arbitrariamente no comando MAIL, mas cabe aqui tão bem quanto em qualquer outro lugar. O objetivo é especificar quanto de sua mensagem original deve ser retornada em caso de falha na entrega. Os argumentos válidos são FULL e HDRS. O primeiro significa que a mensagem completa deve ser incluída na mensagem de erro, o HDRS instrui o servidor a retornar apenas os cabeçalhos do email com falha. Se o RET não for especificado, cabe ao servidor o que fazer. Na maioria dos casos, o HDRS será o valor padrão. ENVID realmente pertence ao remetente como ela ou (em vez disso) seu cliente de e-mail será o único que faz uso deste identificador de envelope . Sua finalidade é informar ao remetente para o qual o email corresponde a uma mensagem de erro possivelmente emitida. O formato deste ID é basicamente deixado para a imaginação do remetente. Nós não usaremos ENVID no nosso exemplo: CORREIO DE: [email protected] RET = HDRS250 [email protected] … remetente ok Aparentemente, só queremos recuperar os cabeçalhos no nosso DSN. O RCPT TO: também recebe seu quinhão de extensões: NOTIFY e ORCPT. NOTIFY é o verdadeiro coração do DSN. Diz ao servidor quando para enviar uma notificação de status de entrega. O primeiro valor possível é NUNCA, o que significa que sob nenhuma circunstância um DSN deve ser devolvido ao remetente. Isso não foi possível sem o DSN. Em seguida, há sucesso, que irá notificá-lo quando seu e-mail chegou ao seu destino. FALHA é a contrapartida do SUCESSO: um DSN chegará se ocorrer um erro durante a entrega. A última opção é DELAY: você será notificado se houver um atraso incomum na entrega, mas o resultado da entrega real (sucesso ou falha) ainda não tiver sido decidido. NUNCA devo ser o único argumento, se especificado, os outros três podem aparecer em uma lista, delimitada por uma vírgula. SUCESSO e FRACASSO compõem uma equipe muito forte, dizendo em (quase) qualquer caso o que aconteceu com o seu e-mail. O objetivo do ORCPT é preservar a original destinatário de uma mensagem de e-mail, por exemplo, se ela for encaminhada para outro endereço. O argumento para essa opção é o endereço de e-mail do destinatário original junto com o tipo de endereço. O tipo de endereço vem primeiro, seguido por um ponto e vírgula e, finalmente, o endereço. Por exemplo: RCPT TO: [email protected] NOTIFY = FALHA, DELAY ORCPT = rfc822; [email protected]250 [email protected] … Destinatário ok (será enfileirado) Isto é seguido pelos dados como nós o conhecemos e, eventualmente, esperamos, uma notificação de status de entrega notificando-o de um sucesso. Claro, toda essa beleza e isso só vai funcionar se os agentes de transporte de email do remetente ao destinatário suportam DSN. Algum dia eles irão. Extensões de remetente DSN
Extensões de Destinatário DSN
O DSN funciona?
