Descubra como DSN tiña como obxectivo introducir o estado da entrega no correo electrónico SMTP.
Xa se preguntas o que pasou a un correo electrónico enviado?
Incluso unha pequena ollada ao protocolo SMTP terá que notar que, ademais do habitual HELO, tamén hai EHLO, o que fai que o servidor SMTP prolongado anuncie as súas capacidades máis alá do estándar orixinal. Un destes é DSN. DSN? Son o ADN eo DDT non o suficiente?
Para argumentar que o correo electrónico non é fiable, que alguén debería " ... alimentar o seu servidor mellor; comeu o meu correo ... " non é raro. Fago a min mesmo. Non obstante, non hai moita razón para apoiar estas sospeitas.
Entrega S tatus N otification estivo en torno desde a RFC 821 (desde 1982). Axiña que a parte DATA do protocolo SMTP sexa rematada e o servidor aceptase o correo electrónico para a súa entrega, encárgase dela. Se, por algún motivo, non pode acceder ao destinatario, deberá devolvelo de novo coa notificación do erro ao remitente orixinal. Isto deu lugar a un escuro correo electrónico .
Separadamente diso, esta vella convención significou que xa recibiu unha mensaxe de erro ou non obtivo nada no caso de que non soubese nada : o correo electrónico pode chegar ou non. As mensaxes de erro en moitos casos foron tan útiles como as mensaxes de erro. Cando o correo electrónico sexa cada vez máis importante, isto xa non é satisfactorio (coma se fose antes).
Extensións de DSN a SMTP
O RFC 1891 propón algunhas extensións ao protocolo SMTP que debería dar lugar a un sistema DSN máis fiable e máis útil. É un conxunto de extensións aos comandos MAIL e RCPT (se isto non significa nada para vostede, lea como funciona SMTP e despois regresa aquí).
Non hai EHLO, Non Fun
En primeiro lugar, temos que asegurarnos de que o servidor admita DSN. Deste xeito, temos que dicir a EHLO e escoitar atentamente. Se responde con DSN algunha vez na lista de funcións, podemos supoñer que poderá cumprir as nosas solicitudes. Se non, entón non: podemos tentar outro servidor ou simplemente voltar ao correo electrónico sen DSN. Por exemplo (a miña entrada é azul, a saída do servidor negro):
220 larose.magnet.at Sendmail ESMTP 8.8.6 / 8.8.6; Domingo, 24 de agosto de 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Hola localhost [127.0.0.1], satisfeito coñecerche
250-EXPN
250-VERB
250-8BITMIME
TAMAÑO 250
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 AXUDA
Afortunadamente, entre outras cousas atopamos DSN.
Extensións do remitente DSN
O seguinte comando normalmente é MAIL FROM :. Con DSN, isto non é diferente. Pero hai dúas opcións adicionais que pode emitir: RET e ENVID.
A opción RET foi colocada de forma arbitraria no comando MAIL, pero encaixa aquí, así como noutro lugar. O obxectivo é especificar canto devolver a mensaxe orixinal en caso de fallo de entrega. Os argumentos válidos son FULL e HDRS. O primeiro significa que a mensaxe completa debe incluírse na mensaxe de erro; HDRS instruirá ao servidor para que só devolva os encabezados do correo non válido. Se RET non se especifica, corresponde ao servidor o que facer. Na maioría dos casos HDRS será o valor por defecto.
ENVID realmente pertence ao remitente como ou (máis ben) o seu cliente de correo electrónico será o único que nos converte neste identificador do sobre . O seu propósito é indicarlle ao remitente o correo electrónico que corresponde a mensaxe de erro emitida. O formato desta ID é basicamente deixado á imaxinación do remitente. Non imos usar ENVID no noso exemplo (imaxinación!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... Sender ok
Ao parecer, só queremos que volvan os encabezados no noso DSN.
Extensións de destinatarios de DSN
O RCPT TO: tamén obtén a súa boa parte das extensións: NOTIFY e ORCPT.
NOTIFY é o verdadeiro corazón de DSN. Indica ao servidor cando enviar unha notificación de estado de entrega. O primeiro valor posible NUNCA é NEVER o que significa que en ningún caso un DSN debe ser devolto ao remitente. Isto non foi posible sen DSN. Despois hai ÉXITO, que notificarache cando o teu correo chegue ao seu destino. O FALLO é a contrapartida de SUCCESS (!): Un DSN chegará se un erro ocorreu durante a entrega. A última opción é RETARDO: notificaráselle se hai un atraso inusual na entrega, pero o resultado real (éxito ou fracaso) aínda non está decidido. NUNCA debe ser o único argumento se se especificou, os outros tres poden aparecer nunha lista, delimitada por unha coma. SUCCESS e FAILURE compoñen un equipo moi forte (!), Contándoche (case) calquera caso o que pasou co seu correo electrónico.
O obxectivo da ORCPT é preservar o destinatario orixinal dunha mensaxe de correo electrónico, por exemplo, se se envía a outro enderezo. O argumento a esta opción é o enderezo de correo electrónico do destinatario orixinal xunto co tipo de enderezo. O tipo de enderezo aparece primeiro, seguido dun punto e coma e finalmente o enderezo. Por exemplo:
RCPT TO: support@example.com NOTIFY = FALLO, RETARDO ORCPT = rfc822; support@example.com
250 support@example.com ... Receptor ok (será cola)
A continuación, segue os DATOS como a coñecemos e, eventualmente, con sorte, unha notificación de estado de entrega notificándolle dun éxito.
¿Funciona DSN?
Por suposto, toda esta beleza e sagacidade só funcionará se os axentes de transporte de correo do remitente ao soporte DSN de destinatarios. Algún día van.