Resumo

  • A RFC4865 permite transferir para o servidor de submissão a espera antes da liberação de uma mensagem. A regra impede a saída antecipada; não assegura saída no instante exato, chegada ao destinatário ou leitura.
  • Quando o pedido também usa DELIVERBY, o cliente deve deixar o limite de entrega estritamente depois da liberação. O servidor compatível deve rejeitar o conflito descrito pela norma, sem escolher silenciosamente qual condição abandonar.

Um botão de agendamento parece vender tempo: escolha o dia, escolha a hora e encerre a tarefa. Por trás dessa simplicidade, o serviço assume algo menos abstrato. Ele recebe conteúdo, ocupa armazenamento agora e aceita uma obrigação que só poderá executar mais tarde. A utilidade para o usuário nasce da transferência dessa espera.

Isso não significa reservar a viagem inteira da mensagem. O servidor de submissão não controla todas as filas posteriores, nem o momento em que uma pessoa consultará sua caixa. A precisão do calendário exibido pode ser muito maior que a extensão real do compromisso técnico.

Considere uma situação hipotética, não um incidente observado: uma mensagem apresentada pela manhã só pode ser liberada ao meio-dia, mas não deve continuar sendo entregue depois das onze. Aumentar o número de trabalhadores da fila não resolve. A tarefa exige que a mensagem use um intervalo que não existe.

Se o serviço aceitar e modificar uma das condições por conta própria, poderá produzir uma entrega e ainda assim descumprir o pedido. A taxa de sucesso fica melhor; a responsabilidade fica pior definida. A pergunta correta é quem tinha autorização para fazer aquela escolha.

O limite inferior de uma saída

Publicada em maio de2007, a RFC4865 define Future Message Release para submissão SMTP. A ideia atende clientes que não dispõem de armazenamento local adequado ou não conseguem permanecer disponíveis no momento desejado. O servidor passa a guardar a mensagem até a liberação futura.

A capacidade é anunciada por FUTURERELEASE na resposta EHLO, com dois máximos: um intervalo de espera e uma data e hora futuras. O cliente precisa verificar o suporte antes de usar a extensão e incluir exatamente um parâmetro de espera no comando MAIL.

HOLDFOR fornece uma duração. HOLDUNTIL fornece uma data e hora. Cada valor deve respeitar seu limite correspondente. O fato de não haver parâmetro não implica uma espera padrão; o servidor não recebe uma autorização genérica de agendamento só porque oferece a função.

As duas formas acomodam equipamentos com capacidades temporais diferentes. Um cliente pode conhecer uma hora local sem ter informação apropriada de fuso; outro pode não ter relógio suficientemente preciso. A norma reconhece o valor prático de não obrigar todos a fornecer a mesma representação.

Aceita a mensagem com o pedido, o servidor não deve liberá-la antes de transcorrer o intervalo ou chegar o instante indicado. Essa é uma proibição de antecipação. Não é uma afirmação de que a execução acontecerá exatamente no primeiro segundo permitido.

Depois de encerrada a espera obrigatória, ainda é preciso observar a tentativa efetiva, a aceitação pela etapa seguinte e a entrega final. A chegada do horário muda uma condição de elegibilidade, não produz automaticamente todos esses eventos. Uma interface que apresenta apenas “enviado” perde a oportunidade de mostrar a diferença.

O relógio do servidor continua relevante mesmo com HOLDFOR. A RFC4865 adverte que horários inexatos ou mudanças no relógio podem causar liberação prematura ou tardia nos dois mecanismos. Uma duração relativa pode facilitar a vida do cliente sem tornar o sistema imune a falhas de tempo.

Quando esperar e entregar deixam de caber juntos

A segunda extensão, DELIVERBY, foi definida pela RFC2852. Ela permite indicar um intervalo para entrega e o tratamento desejado caso a entrega não ocorra a tempo. Não exige prioridade de processamento. O servidor pode concedê-la, mas o parâmetro não cria esse direito por si só.

DELIVERBY também não equivale a uma ordem de saída adiada e não estende o prazo normal de retenção de mensagens que não podem ser entregues. Um limite de entrega e uma proibição de liberação antecipada têm papéis diferentes, ainda que apareçam lado a lado no produto.

Ao combinar as duas extensões, o cliente deve, conforme a seção5.2.1 da RFC4865, garantir que o limite de entrega esteja estritamente depois do horário de liberação especificado ou calculado. Colocar duas datas no futuro não basta: sua ordem tem que ser coerente.

A seção5.2.2 impõe outra formulação ao servidor que oferece ambas. Se ele determinar que a liberação fica depois do limite de entrega, deve rejeitar MAIL. A norma recomenda resposta501 e código de estado aprimorado5.5.4.

Não convém uniformizar essas frases. A condição de rejeição expressamente escrita para o servidor é liberação posterior ao limite, não posterior ou igual. Isso, porém, não transforma a igualdade em uma solicitação válida do cliente. Ele continua obrigado a deixar o prazo estritamente depois da liberação.

Uma avaliação de implementação deve manter dois registros: se o cliente cumpre sua própria obrigação e como o servidor responde aos casos de borda. Se a igualdade importa ao serviço, cabe observá-la num teste controlado. Não se deve inventar uma regra universal a partir do silêncio de uma comparação específica. Este artigo não realizou esse teste.

No caso inequivocamente contraditório, rejeitar preserva a decisão onde ela pertence. Talvez o remetente dê mais valor à confidencialidade antes de uma hora. Talvez o essencial seja impedir a chegada de um lembrete depois que perdeu sentido. O servidor não deveria escolher uma preferência de negócio para conseguir aceitar mais trabalho.

O que fazer depois do prazo depende do modo

Return e Notify, previstos em DELIVERBY, levam a consequências diferentes. Se a mensagem não tiver sido entregue ou retransmitida antes do limite no modo Return, não se permitem novas tentativas de entrega. É devida a notificação de falha correspondente para os destinatários abrangidos pelas condições de notificação.

No modo Notify, a passagem do limite não exige abandonar o trabalho. A especificação recomenda continuar as tentativas conforme a política local, com a notificação de atraso prevista para os destinatários pertinentes. “Passou da hora” não constitui, sozinho, uma instrução de descarte.

Uma rotina de recuperação que trate todo item vencido da mesma maneira pode errar nas duas direções. Continuar sempre pode violar Return. Interromper sempre pode abandonar uma solicitação Notify que deveria seguir em processamento. Mais mensagens entregues não é uma definição suficiente de correção.

O compromisso também depende do próximo servidor. Return não pode ser retransmitido para uma etapa sem suporte a DELIVERBY, nem para outra cujo mínimo fixo de tempo seja maior que o intervalo restante. Notify pode atravessar uma etapa que não ofereça a extensão, com as consequências de notificação descritas pela RFC2852.

Por isso, o registro de uma transferência não prova sozinho a preservação do prazo. Capacidade, modo e tempo restante precisam viajar como uma obrigação interpretável por quem assume o trabalho seguinte. A rede não é uma reserva única feita no primeiro clique.

Há ainda uma diferença entre o fim das tentativas e o conhecimento desse fim. A RFC2852 esclarece que os avisos de estado não precisam receber tratamento acelerado. Um prazo curto não garante que o remetente será informado de uma falha dentro desse mesmo prazo. Ausência de retorno continua sendo ausência de observação, não confirmação de entrega.

Mesmo a aceitação precisa indicar sua fase. Uma resposta positiva a MAIL não comprova a aceitação final de toda a mensagem, muito menos a entrega. A RFC2852 observa que certas impossibilidades podem aparecer no tratamento dos destinatários ou na conclusão dos dados. Um contador único de sucesso esconderia essas etapas.

Quem oferece o calendário deve enxergar o estoque

O serviço guarda hoje o trabalho que poderá executar amanhã. A autorização do usuário não elimina o custo desse estoque. Um remetente legítimo também consegue acumular mensagens futuras em volume suficiente para consumir o armazenamento de um servidor.

A RFC4865 recomenda uma cota por usuário para esse armazenamento. Quando o servidor aplica tal cota e detecta que uma nova mensagem a excederá, deve rejeitar MAIL. A recomendação de estabelecer o orçamento e a obrigação de recusar um excesso detectado sob esse orçamento não são a mesma regra.

Nada nisso demonstra que todos os produtos reservam espaço de forma idêntica. A norma não é uma descrição da contabilidade interna de cada implementação. Para planejar capacidade real, o operador precisa conhecer o comportamento do serviço que usa.

Os estados X.7.16 e X.7.17 separam insuficiência de cota individual e insuficiência de cota do sistema. Liberar margem na fila de uma pessoa pode resolver a primeira; recuperar o orçamento compartilhado é outra tarefa. Um tempo universal de nova tentativa não decorre dessa distinção.

Também importa a distribuição dos horários futuros. Muitos pedidos individualmente aceitáveis podem se tornar elegíveis juntos. Essa concentração é um cenário operacional plausível para teste, não um evento medido nesta análise. Ela mostra que o gargalo pode mudar de bytes guardados para processamento de liberação e transporte de saída.

O horizonte máximo anunciado é um limite da oferta, não uma prova de capacidade disponível na data escolhida. Sem distinguir os dois, a área que amplia a conveniência do calendário pode assumir compromissos cuja pressão só outra equipe verá mais tarde.

A Nota32 de Lu Heng fornece uma lente para esse problema: a separação entre controle e consequências econômicas. Neste caso, vale perguntar quem pode oferecer a espera, quem paga o armazenamento e quem responde pela execução. A análise não permite concluir que uma empresa ou seus engenheiros tenham más intenções. A Nota36 sobre BTW.Media reforça essa disciplina ao tratar a descrição da realidade, e não a defesa de um lado, como produto editorial.

Guardar o pedido não é medir o acontecimento

Se o servidor de submissão gerar uma DSN sobre uma mensagem com liberação futura, a RFC4865 exige Arrival-Date e Future-Release-Request na parte legível por máquina. O segundo campo preserva o valor originalmente solicitado, na forma definida pela extensão.

Isso permite distinguir espera intencional de demora que surgiu no transporte. Mas um pedido de liberação não comprova sua execução exata. O operador ainda precisa ligar o registro original à tentativa observada, à resposta da próxima etapa e ao resultado que eventualmente conheça.

A extensão proíbe o cliente de pedir liberação futura ao submeter uma DSN ou uma notificação de disposição MDN. Um aviso sobre processamento não deve, por esse mecanismo, virar outro aviso intencionalmente adiado. A proibição não promete ausência de atrasos na transmissão dessas notificações.

Date, no cabeçalho, também não deve substituir o histórico operacional. A RFC4865 diz que permanece inalterado depois da submissão; o cliente pode escolher uma data futura, e não há expectativa de que o transporte modifique as informações de rastreamento para disfarçar a espera. Isso é diferente da correção limitada de uma Date ausente ou malformada durante a submissão, permitida pela RFC6409.

A RFC6409 substitui a RFC4409 e separa submissão de retransmissão. A submissão usa normalmente a porta587; a permissão geral de designar certos serviços na25 para esse papel não autoriza anunciar FUTURERELEASE em um serviço comum de retransmissão. O âmbito específico da extensão continua valendo.

O limite da evidência também faz parte da análise

A errata editorial2040 da RFC4865 foi verificada e corrige uma referência gramatical indefinida para usar date-time da RFC3339. A observação do relator, em2010, sobre seu servidor em funcionamento é um depoimento histórico atribuído. Não é um levantamento atual de adoção ou qualidade.

A errata editorial2300 da RFC2852 está retida para atualização do documento e trata de espaços na gramática. Ela não altera os modos nem o comportamento dos prazos. Apresentar ambas como mudanças funcionais seria acrescentar algo que seus registros não sustentam.

Não foram executados comandos SMTP, alterados relógios ou examinadas filas de produção para este trabalho. Os documentos permitem formular obrigações e perguntas de verificação; não provam a conduta de um fornecedor específico diante de igualdade de horários, congestionamento ou recuperação.

O valor da extensão aparece com mais clareza quando o serviço consegue recusar uma promessa impossível, sem transformar essa recusa em escolha silenciosa pelo cliente. O agendamento pode terceirizar a espera. Não pode fazer um prazo anterior à saída virar uma entrega possível.

Fontes