Resumo

  • RFC 772 e RFC 780 definiam R, destinatários primeiro, e T, texto primeiro. O emissor sugeria, mas o receptor controlava o esquema que conseguia executar.
  • MRSQ detectava, escolhia e reiniciava o estado. MRCP apresentava destinatários, porém sua resposta confirmava armazenamento de nome em R e processamento do texto já armazenado em T.
  • RFC 788 e RFC 821 adotaram uma sequência única: MAIL, um ou mais RCPT, DATA. A economia de uma cópia para vários destinatários ficou; a coreografia negociada saiu.

A pergunta tinha efeito de reset

Em RFC 780, MRSQ ? pede a preferência do servidor e recebe 215 R ou 215 T. Um MRSQ sem argumento confirma a instalação e volta ao estado sem esquema. Uma seleção concreta pode ser recusada se o receptor não a suporta.

Qualquer MRSQ também limpa o estado associado. Perguntar não é uma leitura passiva: uma lista ou um texto guardado pode desaparecer. Uma ferramenta de diagnóstico que injete a pergunta durante o fluxo altera justamente aquilo que tenta observar.

O remetente precisa aceitar a escolha disponível. Só o receptor sabe se entrega em lote a um mailer central, se trabalha incrementalmente, quanto cabe na tabela e qual buffer é seguro.

R guardava nomes e aguardava um corpo

No modo recipients-first, cada MRCP TO:<path> recebe resposta própria. Os caminhos aceitos entram numa tabela; um endereço rejeitado não anula os outros.

Depois, MAIL FROM:<sender-path> sem TO transfere um único corpo para todos os nomes lembrados. Sucesso final cobre o conjunto; falha faz o conjunto ser tratado como falho. Em seguida, a tabela é apagada.

O arranjo combina com uma entrega centralizada: reunir destinatários e conteúdo antes de passar o pacote inteiro. A economia vem de não retransmitir o corpo por pessoa.

Mas a tabela pode encher. Um 452 força o emissor a enviar o corpo ao lote existente, recolher outro lote e transmitir de novo. Cinquenta nomes diante de espaço para dez podem virar cinco cópias. Eficiência é limitada pela capacidade de estado, não por um slogan.

T guardava o corpo e aguardava nomes

No modo text-first, o MAIL sem destinatário armazena o texto primeiro. Cada MRCP posterior aplica a cópia guardada a uma pessoa e retorna um resultado individual, sem outra transmissão do corpo.

O texto permanece até outro MAIL substituí-lo ou MRSQ eliminá-lo. T preserva a mesma economia, mas escolhe o conteúdo como objeto persistente.

Isso favorece implementações que entregam uma pessoa de cada vez. Quota, conflito de acesso e outros limites podem aparecer na resposta específica do destinatário.

O custo é aceitar texto antes de saber se haverá endereço válido. MRCP antes do texto equivale a tentar uma mensagem nula e pode gerar comportamento local diferente. O verbo depende da história da sessão.

O esquema fazia parte da evidência

Em R, o sucesso de MRCP registra o destinatário para uma operação coletiva futura. Em T, o corpo já existe e a resposta se refere à aplicação daquela cópia ao nome. O mesmo código não prova a mesma ação.

Resets ampliam a diferença. MRSQ apaga estado; MAIL normal com destino também reinicia. Se o log omite uma dessas linhas, um analista pode ligar o MRCP ao corpo ou à lista errada.

Duas ordens significam duas custódias, interpretações e fronteiras de descarte. A otimização interna torna-se complexidade comum para clientes, gateways e auditoria.

O receptor possuía o conhecimento relevante

RFC 780 explica R como útil para quem entrega um pacote completo a um mailer central. T serve a quem faz entrega incremental e precisa de resultados variáveis por caixa.

O remetente não enxerga essas condições. Pode desejar uma ordem, mas não sabe o custo real do outro lado. O receptor paga pelo buffer e responde pelo erro; por isso controla o esquema executável.

Essa autoridade é bem fundamentada numa conexão. No sistema inteiro, porém, obriga todos a implementar e testar os dois caminhos. Uma diferença local passa a ocupar o contrato de interoperabilidade.

SMTP fixou a ordem externa

RFC 788 define MAIL FROM para iniciar e nomear o remetente, RCPT TO repetido para negociar destinatários e DATA para enviar o corpo. A conversa é deliberadamente lock-step e deve seguir essa ordem.

MRSQ e o MRCP de correio não aparecem. O receptor não escolhe texto primeiro. Uma rejeição RCPT afeta aquele nome, não precisa encerrar toda a transação.

RFC 821 preserva a estrutura. Ela não obriga servidores a usar a mesma fila ou o mesmo disco; obriga pares a enxergar a mesma causalidade.

A arquitetura local continua livre atrás da borda. O que desaparece é o direito de fazê-la bifurcar o diálogo de todos os clientes.

Uma cópia para muitos continuou

R e T evitavam repetir conteúdo. O SMTP manteve essa meta em seu único caminho: um MAIL, vários RCPT, um DATA.

RFC 788 e RFC 821 incentivam uma única cópia para pessoas no mesmo destino. RFC 1123 recomenda fortemente RCPT, RCPT, ... RCPT, DATA em vez de repetir RCPT, DATA.

Portanto, a convergência não abandonou economia de banda. Retirou a alternativa em que o corpo atravessava antes da lista, mas fez o compartilhamento funcionar no esquema fixo.

Menos espera não é outra sequência

Lock-step também cria latência. PIPELINING posterior permite enviar comandos permitidos antes de receber todas as respostas, mas não move DATA para antes de RCPT.

MRSQ T alterava qual estado existia primeiro. PIPELINING altera quando bytes de uma ordem já válida podem viajar. Uma melhoria de ida e volta não restaura escolha de coreografia.

Separar as duas coisas evita confundir esta história com o artigo sobre PIPELINING e impede que uma captura compacta pareça reordenada.

O contorno moderno permanece estável

RFC 5321 conserva MAIL, um ou mais RCPT, DATA. Extensões adicionam parâmetros, mas não entregam ao servidor a escolha R/T.

Internamente, servidores podem validar em momentos diferentes, usar filas distintas e encontrar limitações após DATA. A forma comum não elimina engenharia local; impede que ela imponha outra gramática ao par.

Esse recuo reduz estados compartilhados e facilita trocar componentes sem coordenar todos os emissores. Uma otimização pode continuar existindo por trás da interface sem virar obrigação universal.

MRCP também nomeia um protocolo sem relação

Aqui MRCP é Mail Recipient do MTP. O Media Resource Control Protocol posterior usa a sigla para controlar síntese e reconhecimento de voz. Não há linhagem técnica.

Buscas precisam combinar MRCP com MRSQ, mail ou RFC 772/780. Quatro letras iguais não provam o mesmo objeto histórico.

Fontes e limites

Os documentos demonstram uma mudança na máquina de estados especificada, não uma troca simultânea de todas as instalações em operação. Separar essas duas coisas evita transformar uma sequência normativa clara em estatísticas de adoção ou em uma data única de abandono que as fontes não fornecem.

O artigo usa RFC 772, 780, 788, 821, 1123 e 5321. Eles estabelecem esquemas, resets, autoridade, limites, ordem SMTP e continuidade da eficiência.

Não fornecem censo de implantação, uma reunião decisiva ou ganho universal. RFC 788 simplesmente deixa de definir MRSQ/MRCP e impõe outra sequência.

R não é entrega atômica, e T não retransmite o corpo por destinatário. A diferença é onde o estado fica e quando a resposta ganha força.