# Projeto de infraestrutura de listas de e-mail

**Grupo Murad · Estudo técnico e plano de implantação**  
**Versão:** 0.2 — revisão de escopo  
**Data:** 15 de outubro de 2026  
**Status:** proposta técnica; implantação não autorizada

> **DECISÃO PENDENTE — DOMÍNIO**  
> O domínio da nova infraestrutura **ainda não foi escolhido**. Este projeto **não define nem presume** nome de domínio, subdomínio, endereço de lista, URL do painel ou hostname SMTP. Todas essas escolhas serão tomadas em uma etapa específica, antes de qualquer mudança em DNS.

## 1. Resumo executivo

A proposta é estudar e, após aprovação, implantar uma solução **self-hosted** para dois tipos de comunicação por e-mail, administrados no mesmo ambiente:

- **Listas de discussão:** participantes autorizados publicam e respondem por e-mail, com moderação configurável.
- **Listas de anúncios:** somente remetentes autorizados divulgam boletins, comunicados e avisos; os assinantes recebem, mas não publicam livremente.

Foram comparados **GNU Mailman 3** e **mlmmj**. A recomendação técnica inicial é **GNU Mailman 3**, com **Postorius** para administração e **HyperKitty** para arquivamento, integrado a **Postfix**, **PostgreSQL** e **Nginx** em um host Linux isolado. O **mlmmj** permanece como alternativa para um cenário mais minimalista, centrado no terminal, em que o custo operacional de uma interface web completa não se justifique.

A escolha do domínio, do provedor/host, do transporte SMTP de saída e a eventual integração com endereços existentes no Google Workspace **continuam em aberto**. Não há proposta de alterar os registros MX corporativos existentes nesta fase. [S1–S5]

## 2. Objetivos e limites

### Objetivos

1. Permitir múltiplas listas de discussão e anúncios, cada uma com políticas próprias.
2. Oferecer administração acessível pela web, sem excluir a manutenção por SSH/CLI.
3. Configurar inscrição, cancelamento, aprovação, moderação, rejeição e tratamento de falhas de entrega.
4. Manter histórico consultável das listas em que o arquivamento for autorizado.
5. Garantir controle de acesso e tratamento adequado dos dados dos membros.
6. Facilitar backup, restauração, atualizações e monitoramento.
7. Preservar o funcionamento do serviço de e-mail corporativo já existente.

### Fora do escopo inicial

- Migrar todo o correio corporativo para uma infraestrutura própria.
- Implantar caixas IMAP/POP3 ou um webmail completo.
- Criar um sistema de marketing em massa ou uma plataforma de newsletters visuais.
- Escolher ou registrar domínio sem decisão expressa.
- Alterar o endereço atualmente utilizado para comunicações do grupo de TI sem plano de transição aprovado.
- Pressupor integração SSO, LDAP, autenticação via Google ou qualquer host já existente.

**Contexto conhecido:** o grupo atualmente usa recursos do Google Workspace; `ti@grupomurad.network` é um endereço existente de referência. **Isso não significa que `grupomurad.network` ou qualquer derivação será usado pela nova plataforma.**

## 3. Decisões ainda não tomadas

| Item | Estado | Critério para decidir |
|---|---|---|
| Domínio da lista | **Não definido** | Identidade desejada, DNS sob controle e independência do e-mail atual |
| Endereços das listas | **Não definidos** | Nome de cada grupo e política de publicação |
| URL da interface web | **Não definida** | DNS, TLS, acesso público ou restrito |
| Host / VPS | **Não escolhido** | IP, PTR, portas SMTP, backup, isolamento e custo |
| Método de saída | **Não escolhido** | SMTP direto ou relay autenticado, conforme entregabilidade |
| Visibilidade dos arquivos | **Por lista** | Privado, público ou sem arquivo |
| Autenticação do painel | **Não escolhida** | Conta local inicialmente; avaliar SSO depois |
| Migração do endereço atual | **Não aprovada** | Inventário, testes e regras de roteamento |
| Volume e retenção | **A medir** | Quantidade de membros/mensagens, anexos e política de dados |

**Regra de projeto:** comandos e exemplos abaixo usam identificadores conceituais como `DOMINIO_A_DEFINIR`. Eles não representam valores DNS prontos para aplicação.

## 4. Comparação técnica: Mailman 3 × mlmmj

| Critério | GNU Mailman 3 | mlmmj |
|---|---|---|
| Filosofia | Suíte modular e completa | Gerenciador enxuto, próximo da tradição Unix |
| Discussão e anúncios | Sim; estilos, permissões e moderação | Sim; controles de acesso e moderação |
| Administração web | **Postorius**, integrada | Ferramentas PHP opcionais; experiência mais simples |
| Arquivo navegável pela web | **HyperKitty**, integrado | Arquivos próprios; publicação web exige arranjo adicional |
| Gestão de membros | Interface web, API e CLI | CLI, arquivos/controles e interfaces opcionais |
| Banco de dados | SQLite ou SGBD; **PostgreSQL recomendado neste projeto** | Não exige SGBD próprio |
| Processos e dependências | Mais serviços: Python/Django e banco | Muito leve, sem daemon próprio contínuo |
| Integração com MTA | Postfix via LMTP e SMTP | Compatível com Postfix/Exim; integração por transporte/pipe |
| Manutenção | Mais componentes; experiência de equipe facilitada | Poucos componentes; exige mais familiaridade com CLI |
| Debian 13 | Pacote `mailman3-full` | Pacotes `mlmmj`, `mlmmj-php-web` e `mlmmj-php-web-admin` |
| Melhor encaixe | Várias listas, delegação de administração e arquivo web | Poucas listas, pouca RAM e preferência por terminal |

**Constatação verificada:** no Debian 13 (Trixie), o metapacote `mailman3-full` agrupa Core, interface web e integração do arquivador. O pacote está publicado como `3.3.10-2`. O `mlmmj` está disponível no repositório estável como `1.5.2-1`, incluindo pacotes web opcionais. Versões upstream podem divergir das versões empacotadas. [S1, S2, S4]

### Avaliação

**Por que Mailman 3 vence para este caso:** há necessidade de **dois tipos de listas no mesmo sistema**, múltiplos administradores potenciais, moderação e arquivos consultáveis. O Postorius diminui a dependência do administrador Linux para tarefas recorrentes; o HyperKitty evita construir um site de arquivos do zero. O preço dessa conveniência é manter uma suíte Python/Django e seu banco.

**Quando escolher mlmmj:** se o requisito principal mudar para simplicidade operacional e administração quase toda por SSH, o mlmmj é uma boa alternativa. As interfaces em PHP existem, mas devem ser avaliadas em um piloto antes de prometer uma experiência equivalente à do Mailman 3. Sua integração com o Postfix merece cuidado com o usuário do processo e as permissões dos diretórios. [S2, S3, S5]

**Decisão recomendada:** usar **Mailman 3 como candidato principal**, sem impedir um piloto comparativo com mlmmj.

## 5. Arquitetura de referência — sem domínio escolhido

```text
                       PARTICIPANTES
              Clientes de e-mail / navegadores
                              |
                       SMTP (entrada)
                              v
                    +------------------+
                    | Postfix (MTA)    |
                    | recepção/fila    |
                    +------------------+
                              |
                       LMTP local
                              v
                    +------------------+
                    | Mailman 3 Core   |
                    | regras / listas  |
                    +------------------+
                       |           |
               entrega SMTP    arquivamento
                       |           v
                       |    +------------------+
                       |    | HyperKitty       |
                       |    | arquivo web      |
                       |    +------------------+
                       v           ^
                Postfix saída     Django
                       |           ^
            SMTP direto ou relay  |
                       |    +------------------+
                       |    | Postorius        |
                       |    | administração    |
                       |    +------------------+
                       |           ^
                       v           |
              Destinatários     Nginx / HTTPS

              PostgreSQL: dados do Core e do Web
              SSH administrativo: acesso restrito
```

### Função de cada componente

- **Postfix:** recebe mensagens destinadas às listas, repassa-as ao Core e realiza as entregas de saída ou envia a um relay SMTP contratado/configurado.
- **Mailman Core:** controla listas, membros, regras de postagem, moderação, filas e mensagens devolvidas.
- **Postorius:** painel Django para proprietários, moderadores, membros e administradores.
- **HyperKitty:** arquivo web, navegação por conversas e participação pela interface, quando permitida.
- **PostgreSQL:** armazenamento persistente para Core e Web; os pacotes Debian podem iniciar com SQLite, mas a documentação Debian desaconselha esse padrão para produção.
- **Nginx:** HTTPS e proxy reverso para a interface web.

O servidor de API REST do Mailman **não deve ser exposto à internet**; deve ficar restrito a loopback/rede interna. O componente SMTP de recebimento precisa ser alcançável conforme o desenho de rede escolhido. [S1, S3, S6]

### Porte inicial de referência (estimativa, não requisito)

Para um piloto de baixo volume: **2 vCPU, 4 GiB RAM e 30–40 GiB SSD**, ajustando após medir uso, arquivo de mensagens e anexos. A adequação dependerá do tráfego real, do MTA, do armazenamento de arquivos e de outros serviços no host. Preferir VPS ou VM isolada, evitando disputar configurações de Postfix com aplicações já existentes.

## 6. Políticas de listas propostas

| Configuração | Lista de discussão | Lista de anúncios |
|---|---|---|
| Quem publica | Membros autorizados | Proprietários/remetentes explicitamente aprovados |
| Não assinantes | Retenção para moderação ou rejeição | Rejeição, salvo exceções explícitas |
| Entrada de membros | Convite ou aprovação; confirmação de e-mail | Inscrição confirmada ou inclusão administrativa válida |
| Respostas | Permitidas; definir Reply-To depois de testar | Preferencialmente ao autor/equipe, não a toda a lista |
| Moderação | Somente casos suspeitos ou definidos | Restringir postagem; aprovação adicional quando desejado |
| Arquivo | **Privado por padrão** | Privado, público ou desabilitado por decisão editorial |
| Anexos | Limites de tamanho e tipos permitidos | Limites menores para comunicados |
| Cancelamento | Sempre disponível conforme política | Sempre disponível conforme política |

**Sugestão para o primeiro piloto:** duas listas temporárias com nomes **a escolher**: uma colaborativa, outra de anúncios. Não publicar arquivo web de mensagens internas por padrão. A política de arquivo precisa ser testada no HyperKitty, inclusive com usuário deslogado. O Mailman oferece estilos de lista, incluindo um de anúncios (`legacy-announce`), e políticas de arquivamento. [S6, S7]

## 7. Domínio e DNS: etapa separada de decisão

Não há domínio ou subdomínio escolhido. Existem três caminhos conceituais:

1. **Domínio exclusivo para listas:** separação de identidade, DNS e reputação; implica manter outro domínio.
2. **Subdomínio de um domínio já controlado:** preserva o domínio principal com MX próprios e delega o subdomínio à nova plataforma; depende de avaliação do DNS e da política organizacional.
3. **Uso experimental sem publicação pública de e-mail:** testar interfaces, fluxo local de mensagens e moderação em ambiente fechado, enquanto a decisão de domínio não ocorre.

Nenhuma opção será aplicada automaticamente. A escolha deve especificar, separadamente, o domínio de endereços das listas, o hostname SMTP, o nome de acesso à interface web e o provedor DNS. Eles **não precisam ser a mesma coisa**.

### Registros a preparar **depois** da escolha

- Endereço A/AAAA do host que receberá SMTP, se aplicável, e registro **MX** do domínio de recebimento definido.
- **PTR/rDNS** coerente com o hostname de envio e seu IP, sob responsabilidade do provedor da VPS.
- **SPF, DKIM e DMARC**, de acordo com o serviço real de saída e os remetentes autorizados.
- Registro de certificação HTTPS e política TLS para interface web.
- Caso o DNS utilize Cloudflare: host SMTP não deve depender de proxy HTTP/HTTPS (registros SMTP pertinentes em modo DNS only).

**Não publicar SPF/MX genéricos antes de definir a topologia:** registros incompletos podem derrubar o recebimento ou prejudicar entregas. Os requisitos de envio do Gmail incluem autenticação, DNS direto/reverso e TLS; para listas encaminhadoras, recomendam ainda ARC e cabeçalho `List-id`. [S8]

## 8. Entregabilidade, segurança e privacidade

### Saída: duas opções a medir

**A. SMTP direto da VPS.** Mais independente, mas exige saída TCP/25 liberada, PTR configurável, boa reputação de IP, gerenciamento de filas, bounce e aquecimento de reputação quando necessário.

**B. Relay SMTP autenticado.** O processamento, membros e arquivos permanecem self-hosted, enquanto um serviço externo faz a entrega. Menos independência no transporte, mas pode simplificar reputação e restrições de porta. O custo e os limites dependem do provedor escolhido, **ainda não definido**.

A decisão ocorrerá após testes com Gmail, Outlook e servidores externos. **Não pressupor** que a VPS atual permita porta 25 nem que o Google Workspace atuará como relay de saída.

### Controles mínimos

- SSH por chave e, quando útil, Tailscale para acesso administrativo; sem exposição pública da API REST do Core.
- Nginx com HTTPS, atualizações de segurança e segregação de contas de serviço.
- Postfix **não configurado como open relay**; firewall com portas estritamente necessárias.
- Listas privadas e arquivos privados por padrão; acesso testado sem login.
- Proteção contra spam, limites de envio/anexos e controle de inscrição para impedir abuso.
- Regras de DMARC em listas de discussão: testar os modos de mitigação de remetente e a compatibilidade de respostas, assinaturas e ARC; não tratar assinatura DKIM como solução automática para todos os envios encaminhados.
- Armazenamento e retenção de endereços, mensagens e logs de acordo com a política interna e a LGPD aplicável.
- Backup **criptografado** e teste de restauração periódica.

O Mailman documenta mitigação de DMARC e cabeçalhos/assinaturas ARC, mas a configuração depende da versão e da cadeia de transporte. Não prometer conformidade sem teste de ponta a ponta. [S3, S8, S9]

## 9. Instalação: roteiro de execução controlada

**Nenhum comando de instalação é uma instrução para executar em servidores de produção neste momento.** Antes é necessário aprovar o host, criar backup/snapshot e confirmar que não há Postfix corporativo compartilhado na máquina.

### Fase A — laboratório (sem DNS público)

1. Reservar VM/VPS de teste **a escolher**, idealmente Debian 13, com snapshot e acesso SSH.
2. Verificar pacotes com `apt-cache policy mailman3-full mlmmj postfix postgresql nginx`.
3. Instalar Mailman 3 com os pacotes oficiais; a documentação Debian descreve `apt install mailman3-full`.
4. Configurar PostgreSQL para dados do Core e do Web antes de declarar produção.
5. Integrar Postfix ao Mailman por LMTP, seguindo a documentação de **Debian Trixie** e conferindo cada parâmetro com a configuração existente.
6. Configurar Nginx, Postorius e HyperKitty em ambiente de teste protegido.
7. Criar as duas listas piloto e testar permissões e arquivos com contas diferentes.
8. Opcional: repetir teste funcional em VM separada com `mlmmj` e interfaces PHP, medindo esforço de administração.

**Observação Debian 13:** a documentação oficial do Debian mostra o comando `mailman-wrapper` (não apenas `mailman`) para certas operações administrativas nos pacotes Trixie. Não copiar indiscriminadamente tutoriais de Debian 11/12 ou de instalações pip/Docker. [S1]

### Fase B — preparação de produção

1. Escolher e aprovar domínio, hostname SMTP, URL web e host, sem reutilizar nomes automaticamente.
2. Decidir saída direta versus relay; validar PTR, limites e política de porta 25/587.
3. Emitir certificados e aplicar DNS **somente após** checklist revisado.
4. Ajustar assinatura e mitigação DMARC/ARC, validações de remetente e antispam.
5. Configurar backup, alertas, monitoramento de filas, armazenamento e restauração.
6. Publicar política de inscrição, retenção, privacidade, moderação e termos de uso interno.

### Fase C — entrada gradual

1. Convidar um grupo pequeno e voluntário de participantes.
2. Rodar as duas listas em paralelo ao mecanismo atual, com endereços distintos inicialmente.
3. Medir entrega e experiência dos usuários por pelo menos um ciclo de boletim/discussão.
4. Revisar incidentes, mensagens devolvidas, spam, acessibilidade da administração e operação em celular.
5. Só então avaliar eventual substituição de endereços e desativação de grupos anteriores.

## 10. Google Workspace e migração do grupo de TI

A infraestrutura **atual** do Grupo Murad não deve ser modificada durante o piloto. O endereço `ti@grupomurad.network` é tratado neste documento como uma referência operacional existente, **não como destino escolhido para o novo Mailman**.

A eventual migração exigirá:

1. Levantar se o grupo atual é um Google Group, um grupo de diretório usado para distribuição ou outra configuração de roteamento.
2. Confirmar participantes, proprietários, permissões de postagem, histórico e políticas de assinatura.
3. Decidir se o endereço atual deverá permanecer como entrada, ser encerrado, ou coexistir temporariamente com outro endereço **a definir**.
4. Se houver redirecionamento, desenhar e testar a regra de Google Workspace para o destinatário específico. O Google fornece recursos de roteamento, mas a viabilidade dependerá do tipo do endereço e da configuração real. **Nunca criar encaminhamento bidirecional** que possa formar loop, duplicar mensagens ou contornar moderação.
5. Fazer comunicação aos membros, teste de aceitação e plano de retorno.

Nenhuma migração de mensagens históricas do Google é pressuposta; seus formatos e permissões devem ser avaliados separadamente. [S10]

## 11. Operação, backup e manutenção

### Rotina sugerida

| Frequência | Atividades |
|---|---|
| Diária / alerta | Monitorar serviço, filas de Postfix, erros de entrega, disco e autenticações suspeitas |
| Semanal | Revisar moderação, bloqueios, bounces, assinantes problemáticos e espaço ocupado |
| Mensal | Aplicar atualizações testadas, verificar relatórios DMARC, permissões e backups |
| Trimestral | Executar **restauração real** em ambiente isolado e rever política de retenção |

### Itens de backup

- Bancos PostgreSQL usados pelo Core e pelo Django/Postorius/HyperKitty.
- Configurações de Mailman, Nginx, Postfix, políticas de listas e chaves relevantes.
- Arquivos do HyperKitty, anexos armazenados e spool/estado pertinente das listas.
- Segredos necessários à recuperação, protegidos fora do backup comum.
- Inventário DNS, documentação operacional, certificados e procedimento de restauração.

Apenas fazer dump de banco não equivale a restaurar todo o serviço. O plano precisa prever versão compatível, ordem de restauração e teste de envio/recebimento.

## 12. Testes de aceitação (obrigatórios)

- [ ] Domínio e endereços formalmente aprovados; nenhum nome presumido aplicado.
- [ ] Uma mensagem para a lista de discussão alcança **todos os membros de teste autorizados**, sem duplicação.
- [ ] Um membro pode responder; não assinante é bloqueado ou moderado conforme política.
- [ ] Na lista de anúncios, remetente comum não consegue publicar; administrador autorizado publica.
- [ ] Convite/inscrição, confirmação, remoção e descadastramento funcionam.
- [ ] E-mail externo com SPF/DKIM/DMARC restritivo é testado nos principais provedores.
- [ ] Mensagens preservam encadeamento e mostram cabeçalhos de lista apropriados.
- [ ] Mensagens devolvidas são processadas sem gerar loops.
- [ ] Arquivos privados não ficam acessíveis a visitante ou usuário não autorizado.
- [ ] API REST do Core e serviços de banco não estão expostos publicamente.
- [ ] TLS e DNS reverso estão corretos para a topologia de saída.
- [ ] Monitoramento alerta para falha de serviço, fila e disco.
- [ ] Backup foi **restaurado**, e listas/membros/arquivos foram validados.
- [ ] O Google Workspace e o endereço de TI existente continuam operacionais.

## 13. Riscos e mitigação

| Risco | Impacto | Mitigação |
|---|---|---|
| DNS configurado antes de escolher domínio e topologia | Interrupção de recebimento | Aprovação explícita, mudanças por etapas, rollback documentado |
| Porta 25 bloqueada ou IP mal reputado | Falha de entrega | Verificar com provedor; considerar relay SMTP |
| DMARC/assinaturas de remetentes externos | Rejeições em Gmail/Outlook | Testar mitigação de listas, DKIM/ARC e cabeçalhos reais |
| Exposição de mensagens internas em arquivos públicos | Vazamento de informação | Privado por padrão; teste de permissões e retenção |
| Bounces, loops e spam | Bloqueio da reputação e abuso | Limites, moderação, antispam, métricas de fila e roteamento unilateral |
| Configuração compartilhada com serviços existentes | Conflito de MTA/web | VPS/VM isolada; inventário antes de instalar |
| Falta de responsável por manutenção | Acúmulo de falhas e CVEs | Definir proprietário técnico e calendário de atualização |

## 14. Critérios de decisão final

**Aprovar GNU Mailman 3** caso sejam confirmados: administração via web por mais de uma pessoa, arquivos navegáveis com controle de acesso e demanda por múltiplas listas de discussão/anúncios. Essa é a recomendação atual.

**Reavaliar mlmmj** se o piloto indicar que a equipe prefere CLI, quase não usa arquivo web e quer a menor quantidade possível de serviços. Não mudar apenas pela estética Unix: a ferramenta escolhida precisa facilitar a operação de quem administrará as listas.

**Não iniciar produção** até decidir formalmente o domínio, o host e a rota de envio, testar entrega e privacidade e obter autorização de migração, se houver.

## 15. Registro de decisões e próximos passos

| Decisão | Situação em 15/10/2026 |
|---|---|
| Objetivo: discussão e anúncios na mesma plataforma | **Definido** |
| Candidato técnico principal: Mailman 3 | **Recomendado, sujeito a piloto** |
| Alternativa a testar: mlmmj | **Opcional** |
| Distribuição Linux de referência: Debian 13 | **Proposta, não host escolhido** |
| Domínio, subdomínio e hostnames | **NÃO DEFINIDOS** |
| Hospedagem e saída SMTP | **NÃO DEFINIDAS** |
| Integração/migração do Google Workspace | **NÃO APROVADA** |
| Políticas de arquivo, retenção, membros e acesso | **A DEFINIR POR LISTA** |

**Próxima ação sugerida:** validar os requisitos com a equipe de TI; selecionar um host de laboratório; executar um piloto Mailman 3 sem modificar os registros DNS de produção. A escolha do domínio permanece independente desse estudo.

## 16. Fontes e documentação consultadas

- **[S1]** Debian Wiki — Mailman3 (Trixie): https://wiki.debian.org/Mailman3
- **[S2]** Debian Packages — Mailman3 Full e mlmmj: https://packages.debian.org/trixie/mailman3-full ; https://packages.debian.org/trixie/mlmmj
- **[S3]** Mailman Suite — Arquitetura e API: https://docs.mailman3.org/en/latest/architecture.html ; https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/architecture.html
- **[S4]** Debian Packages — interfaces opcionais do mlmmj: https://packages.debian.org/source/trixie/mlmmj
- **[S5]** mlmmj — site e documentação de integração Postfix: https://mlmmj.org/ ; https://mlmmj.org/README.postfix.html
- **[S6]** Mailman — configuração web e políticas de arquivamento: https://docs.mailman3.org/en/latest/config-web.html ; https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/archives.html
- **[S7]** Mailman — estilos de listas e membros/moderação: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/styles/docs/styles.html ; https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs/membership.html
- **[S8]** Google — Diretrizes para remetentes de e-mail: https://support.google.com/a/answer/81126?hl=pt-BR
- **[S9]** Mailman — mitigação de DMARC: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs/dmarc-mitigation.html
- **[S10]** Google Workspace — Roteamento padrão: https://support.google.com/a/answer/2368153?hl=pt-BR

---

*Documento de planejamento. Contém recomendações e exemplos conceituais, não configurações aplicadas. O domínio da nova mailing list permanece expressamente **em definição**.*