Moon Flower Society > Projeto Mailing Lists Grupo Murad

Projeto Mailing Lists Grupo Murad

Posted October 15, 2026. Markdown.

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:

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

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

                       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

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

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

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

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)

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

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.

View the original Markdown file

Ideas | What changed | RSS | About | Text version

Pablo Murad <pablomurad@pm.me>