Do Servidor ao Destinatário (Entrega Local)

O estágio de Entrega Local, tecnicamente o movimento Do Servidor ao Destinatário, marca a transição final na jornada de um e-mail. É o momento em que a mensagem deixa de ser um objeto de transporte dinâmico (SMTP) e torna-se um dado persistente armazenado na infraestrutura do receptor. Este processo é gerenciado pelo MDA (Mail Delivery Agent), que atua como o elo final entre o servidor de correio e a caixa de entrada do usuário. As RFCs de referência são a RFC 5321 (SMTP), RFC 2033 (LMTP) e RFC 5228 (Sieve).

1. O Papel do MDA no Fluxo de Recepção

Quando o MTA (Mail Transfer Agent) receptor valida que uma mensagem é destinada a um domínio local, ele invoca o MDA. Diferente do MTA, que foca no roteamento Internet, o MDA foca na Organização e Aplicação de Políticas de Usuário.

Mecanismos de Comunicação: LDA vs LMTP

O MTA pode entregar a mensagem ao MDA de duas formas técnicas principais:

Vantagem do LMTP

O LMTP permite que o servidor reporte falhas granulares de entrega para cada destinatário individual de uma mensagem multipart, algo que o MDA clássico não conseguia fazer com precisão. Em uma mensagem com 3 destinatários locais, o MDA pode retornar 250 Ok para o primeiro, 552 Quota exceeded para o segundo e 250 Ok para o terceiro, permitindo ao MTA gerar bounce apenas para o destinatário problemático.

2. Formatos de Armazenamento Local

O MDA decide como persistir a mensagem no disco. Existem dois formatos clássicos:

Maildir (Daniel J. Bernstein, 1995)

Estrutura baseada em diretórios, onde cada mensagem é um arquivo separado.

/var/mail/usuario/
├── tmp/    <- Mensagens sendo escritas (atomicidade)
├── new/    <- Mensagens novas, ainda não lidas
└── cur/    <- Mensagens lidas (estado modificado pelo MUA via IMAP)

Vantagens: Atomicidade (sem corrupção em queda de energia), paralelismo (vários MDAs podem escrever simultaneamente), backups incrementais simples (cada e-mail é um arquivo).

Desvantagens: Mais inodes consumidos, leitura mais lenta em filesystems sem dir_index.

mbox (clássico Unix)

Um único arquivo concatenando todas as mensagens, separadas por From (com espaço).

Vantagens: Simples, um arquivo por usuário.

Desvantagens: Corrupção catastrófica se o processo for interrompido durante escrita; travamento obrigatório (flock) impede leitura durante escrita; lentidão para abrir caixa com 50 mil mensagens.

Tabela Comparativa

3. Processamento Final e Filtragem Sieve

Antes de salvar a mensagem no disco, o MDA realiza o processamento final de inteligência. Este é o ponto onde o usuário tem controle programático sobre o seu fluxo de e-mail.

A Linguagem Sieve (RFC 5228)

A Sieve é uma linguagem de script padronizada e segura, executada inteiramente pelo MDA no servidor.

# Exemplo de script Sieve para organizacao automatica
require ["fileinto", "vacation", "regex"];

if address :is "From" "alertas@empresa.com" {
    fileinto "INBOX.Alertas";
} elsif header :contains "Subject" ["URGENTE", "CRITICO"] {
    fileinto "INBOX.Critical";
    redirect "oncall@empresa.com";
} elsif header :regex "X-Spam-Status" "score=[5-9]" {
    fileinto "INBOX.Junk";
}

vacation
  :days 7
  :subject "Ausente - retornarei em breve"
  "Estou de ferias. Para emergencias, contate oncall@empresa.com";

Vantagem: Permite que o usuário crie regras de filtragem que funcionam independentemente de qual dispositivo o usuário use (Celular, Webmail ou PC).

Segurança: Diferente de scripts shell (como Procmail), a Sieve é uma linguagem de domínio limitado (DSL), impedindo que um usuário execute comandos perigosos no servidor através de suas regras de e-mail. Não há system(), exec() ou acesso ao filesystem além das pastas do próprio usuário.

4. Gestão de Quotas e Erros de Entrega

O MDA é a "última linha de defesa" sobre o sistema de arquivos do servidor.

• Verificação de Quota (Hard vs Soft): O MDA processa se o usuário atingiu o limite de armazenamento.

  • Quota Estourada: O MDA rejeita a entrega no momento do LMTP, forçando o MTA a enviar um erro 552 (Message rejected: quota exceeded) de volta ao remetente original.
  • Soft Quota (Warning): Alguns MDAs aceitam a mensagem mesmo acima de 90% da quota, mas inserem um cabeçalho X-Quota-Warning visível no Webmail.

• Resgate de Aliases: Se o destinatário era um apelido (alias), o MDA resolve o endereço técnico real e garante que o e-mail chegue ao diretório correto do Linux. O Postfix usa /etc/aliases (ou virtual_alias_maps) para isso.

# Exemplo de arquivo /etc/aliases
postmaster: root
root: admin@empresa.com
suporte: user1, user2, user3

5. Perspectiva de Cyber Security: O Estágio de Descarte

Para um profissional de Cyber Security, a fase de entrega local é onde ocorre a verificação final de Integridade e Malware.

Amavis e Rspamd no Fluxo de Entrega

Frequentemente, o MDA é integrado a um motor de análise de conteúdo:

• Scan Final Antivírus: Mesmo que a mensagem tenha passado pelos gateways de perímetro, o MDA pode realizar um scan de "última milha" para detectar ameaças recém-descobertas (assinaturas atualizadas após o e-mail passar pelo gateway de borda).
• Spam Tagging: O MDA processa a pontuação de spam e, em vez de descartar, insere cabeçalhos como X-Spam-Status: Yes, score=8.5 e move o e-mail silenciosamente para a pasta Junk/Lixo Eletrônico do usuário.

6. A Escrita Física no Disco (I/O e Concorrência)

O MDA deve garantir que a escrita ocorra de forma segura, especialmente em sistemas que usam o formato Maildir:

1. Atomicidade: O MDA escreve primeiro em um subdiretório temporário (tmp/) com nome único (timestamp + PID + hostname) e depois move (rename) para a pasta final (new/). O rename em Unix é atômico, garantindo que o arquivo nunca apareça "pela metade".
2. Indexing: MDAs modernos como o do Dovecot atualizam automaticamente os arquivos de índice da caixa de correio (dovecot.index, dovecot.index.cache, dovecot.index.log), garantindo que o usuário veja a nova mensagem instantaneamente quando abrir seu cliente IMAP, sem necessidade de re-escanear todo o Maildir.
3. fsync() e Durabilidade: MDAs rigorosos chamam fsync() antes do rename, garantindo que o conteúdo esteja fisicamente no disco (e não no buffer do kernel) antes de confirmar a entrega ao MTA.

7. Diagnóstico de Falhas de Entrega

Para diagnosticar por que um e-mail "sumiu" no último estágio, o analista deve olhar os logs do MDA:

# Exemplo de log do Dovecot LDA
tail -f /var/log/mail.log | grep "dovecot: lda"

# Saida tipica de sucesso:
# dovecot: lda(usuario@empresa.com): msgid=<7ab@remetente.com>: saved mail to INBOX
# dovecot: lda(usuario@empresa.com): sieve: msgid=<7ab@remetente.com>: stored mail into mailbox 'INBOX.Trabalho'

# Verificando fila do Postfix quando MDA rejeitou
postqueue -p
mailq | head -50

# Forcando reentrega de mensagens em fila
postsuper -r ALL && postfix flush

# Verificando quota de cada usuario
doveadm quota get -u usuario@empresa.com

Se o log mostrar que a mensagem foi salva, mas o usuário não a vê, o problema geralmente reside no cliente de acesso (IMAP) ou em uma regra Sieve mal configurada que moveu o e-mail para uma pasta inesperada.

8. Conclusão da Entrega Local

A entrega local encerra formalmente o ciclo de vida do SMTP. A partir deste ponto, o protocolo SMTP não tem mais qualquer controle ou visibilidade sobre a mensagem. O e-mail permanece em estado de repouso no servidor até que o usuário utilize um protocolo de Acesso Direto (como o IMAP) para recuperá-lo, reiniciando o ciclo de interação com o dado, mas agora sob uma nova gestão de estados e protocolos. Para o engenheiro de e-mail, o MDA é o componente onde a operação técnica encontra a experiência do usuário: filtros Sieve, quotas, antispam e antivírus convergem aqui para entregar uma caixa de entrada limpa, organizada e segura.