Resumo

  • O DELIVERBY colocou no envelope SMTP um prazo em segundos e duas políticas de expiração: Return encerrava as tentativas e devolvia falha; Notify informava o atraso e deixava a fila continuar.
  • Um relé compatível precisava descontar o tempo gasto e transmitir apenas o saldo. A extensão não comprava prioridade, não garantia entrega, não ampliava a retenção comum e não acelerava necessariamente a DSN de retorno.

Imagine a mensagem ainda dentro da fila quando o prazo termina. Nada novo aconteceu com o endereço, com o conteúdo ou com a conexão. Mesmo assim, uma decisão operacional precisa mudar. Em uma aplicação, insistir depois daquele instante é errado. Em outra, desistir seria pior do que chegar tarde.

O SMTP tradicional tinha políticas locais para essa escolha, mas não conhecia a intenção externa do remetente. O exemplo de RFC 2852 era um correio que acionaria um pager: útil antes das 17 horas, indesejado depois. Uma nova tentativa na manhã seguinte poderia obedecer perfeitamente à política da fila e trair completamente o propósito da mensagem.

O Deliver By SMTP Service Extension, publicado em junho de 2000, fez a intenção atravessar a rede. Não criou uma faixa expressa. Criou um prazo recusável e duas consequências explícitas, que cada relé compatível teria de herdar com menos tempo.

Return encerrava; Notify expunha

O parâmetro BY leva segundos, um modo e, opcionalmente, o marcador de rastreamento T. R significa Return. N significa Notify.

No modo R, zero e valores negativos são inválidos. Se o deliver-by-time chegar antes de entrega ou retransmissão, o MTA não pode tentar novamente. Deve gerar para os destinatários aplicáveis uma DSN failed com código 5.4.7, delivery time expired. O prazo encerra a custódia.

No modo N, a expiração não encerra a custódia. O MTA deve continuar conforme sua política e emitir uma DSN delayed com 4.4.7 para os destinatários sujeitos ao aviso. Zero e números negativos são permitidos, porque o fato de o prazo já ter passado continua útil como evidência.

Essa divisão é mais precisa do que “urgente”. Um comando temporário pode precisar desaparecer se chegar tarde. Um relatório pode continuar valioso, desde que alguém saiba que o objetivo de tempo falhou. Return decide se a mensagem pode permanecer viva. Notify decide se o atraso precisa se tornar visível.

O restante do SMTP continua valendo. Falha permanente pode encerrar antes. Falha temporária pode justificar novas tentativas antes do limite. Uma retenção local menor pode devolver a mensagem antes. O DELIVERBY não substitui a fila; adiciona uma fronteira que o remetente conhece e o operador aceita.

O servidor podia recusar antes de assumir

O suporte aparece como DELIVERBY em EHLO. O servidor pode anunciar um min-by-time fixo para Return: o menor intervalo que aceita. O cliente acrescenta BY a MAIL FROM. Não há verbo novo.

O mínimo evita uma promessa teatral. Se o servidor precisa de pelo menos 240 segundos e restam 98, ele não herda a obrigação. O relé pode avaliar outra rota legítima; não pode fingir que a incompatibilidade desapareceu.

Mesmo uma resposta positiva a MAIL FROM não decide tudo. Informações sobre destinatários chegam em RCPT TO; limites de conteúdo ou recurso podem surgir em DATA ou no fim dos dados. O servidor pode rejeitar mais tarde no mesmo diálogo. A aceitação inicial prova apenas o estágio que já foi avaliado.

E aceitar não obriga prioridade especial. RFC 2852 deixa o MTA livre para ordenar sua fila. O remetente propõe a consequência temporal; o operador mantém controle dos recursos. A autoridade existe porque a parte que suporta o custo pode dizer não.

O tempo era um delta localmente convertido

O valor usa segundos decimais com sinal. O módulo máximo é de novecentos e noventa e nove milhões, novecentos e noventa e nove mil, novecentos e noventa e nove segundos, tanto no sentido negativo quanto no positivo. Não é uma data absoluta. Ao receber, o servidor soma o delta ao próprio relógio e cria um deliver-by-time local.

Antes de retransmitir, calcula os segundos restantes tão perto quanto possível do próximo MAIL FROM. O desenho evita depender de relógios perfeitamente sincronizados entre organizações. Não elimina a latência: a especificação reconhece que o trânsito de cada comando amplia um pouco o prazo efetivo e que o erro se acumula.

Também não é “entregar depois de”. O valor define o máximo, não um horário de liberação. E não estende a retenção normal; uma fila que abandonaria antes não precisa guardar a mensagem artificialmente até a data solicitada.

Cada salto recebia saldo, não crédito novo

Quando o próximo servidor também anuncia DELIVERBY, o relé mantém o modo e envia um novo BY com o tempo restante. O RFC mostra 120 segundos tornando-se 98 depois de 22 segundos consumidos. Reiniciar em 120 esconderia o desempenho do primeiro domínio e tornaria o prazo infinito por composição.

Em Return, a continuidade é obrigatória. O relé não pode entregar a um servidor sem DELIVERBY nem a um servidor cujo mínimo declarado exceda o saldo. Se não existir rota compatível, a mensagem é não entregável. Preservar os bytes e descartar o prazo não preservaria a intenção.

Em Notify, uma fronteira incapaz pode ser atravessada porque novas tentativas ainda são autorizadas. Mas o relé precisa gerar uma DSN relayed para os destinatários aplicáveis e, quando o próximo sistema entende DSN, manter a solicitação de aviso de atraso. A mensagem continua; a perda da semântica fica registrada.

O resultado é coordenação fina. O padrão não administra filas nem impõe uma política global. Ele exige que o pequeno estado compartilhado — saldo, modo e limite de observação — seja verdadeiro em cada passagem.

A DSN tinha outro caminho

O DELIVERBY usa os resultados de Delivery Status Notification e adiciona Deliver-By-Date ao relatório. O T pode solicitar DSNs de retransmissão em cada salto; elas não são terminais e podem preceder outras notificações.

Isso aproxima esta história da DSN, mas não as torna iguais. A DSN organiza a evidência sobre uma ação. O DELIVERBY decide qual ação a expiração produz. R retira a autorização de continuar; N mantém a autorização e exige evidência de atraso.

O retorno também pode atrasar. Uma mensagem com BY=60;R pode vencer em sessenta segundos sem que a DSN chegue ao remetente nesse intervalo. O relatório é outro correio, com outras filas. A extensão limita o destino da mensagem original, não promete conhecimento instantâneo de todos os efeitos.

O relógio abriu uma superfície de sondagem

O rastreamento explícito mostra retransmissões. Uma série de mensagens com prazos curtos e crescentes também pode revelar, de forma aproximada, limiares ou latências. RFC 2852 inclui essa possibilidade entre os riscos de segurança.

Os resultados não autorizam conclusões amplas. Um valor negativo em Notify mostra que um prazo local passou, não qual relé causou a demora. 5.4.7 mostra que a obrigação Return expirou, não negligência. relayed confirma uma passagem, não a caixa postal final.

O registro SMTP atual da IANA mantém DELIVERBY com referência a RFC 2852 e nível MAY. O registro confirma a padronização, não o uso por provedores atuais.

O legado do DELIVERBY é uma regra de responsabilidade. Quem sabe quando a mensagem perde valor pode declarar a consequência. Quem opera a fila pode rejeitar. Quem aceita não pode devolver ao orçamento os segundos já consumidos. E quem perde a capacidade no próximo salto precisa mostrar o limite ou encerrar a tentativa.

O prazo viajou sem virar poder central. Ele funcionou como estado mínimo que cada operador podia aceitar, descontar e transmitir com honestidade.

Fontes