2 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O foco principal é o fluxo de trabalho de arquivamento e gerenciamento de rótulos de e-mail na internet para usuários que assinam várias listas de discussão e revisam muitos patches
  • Em particular, a pergunta é direcionada a usuários do Lobsters que participam de 20 listas de discussão e àqueles que revisam muitos patches
  • Busca confirmar se existe algum fluxo de trabalho específico para lidar com arquivamento e rótulos
  • Pergunta quais ferramentas foram de grande ajuda e, se possível, estabelece preferência por ferramentas FOSS
  • O uso de ferramentas como scripts Sieve é citado como exemplo específico

1 comentários

 
GN⁺ 3 시간 전
Opiniões no Lobste.rs
  • Gosto muito de Sieve
    O Roundcube também tem um plugin que permite editar o Sieve por uma GUI na WebUI, então é ótimo para ir aprendendo os recursos da linguagem Sieve, e, se precisar, também dá para editar o arquivo de script diretamente
    Normalmente me cadastro em cada site com um endereço de e-mail por domínio para filtrar facilmente, por exemplo algo como lobsters@example.com

    if address :localpart :is "to" ["lobsters"]  
    {  
      fileinto "Social";  
      stop;  
    }  
    

    Não uso mailing lists, mas, se fosse usar, provavelmente criaria uma caixa de entrada para cada lista, agruparia por thread no cliente de e-mail e mostraria só as mensagens não lidas
    Para spam, uma regra básica que verifica se o corpo contém frases como "my salacious friend" e rejeitar caixas de entrada genéricas como info@ já foi suficiente por mais de 6 anos, e como só tenho 6 regras manuais, para uso pessoal não vejo motivo para investir em soluções de machine learning como rspamd

  • De vez em quando troco de cliente de e-mail, mas há anos meu fluxo de busca-importação e filtragem continua praticamente o mesmo
    No momento, depois de usar mutt por muito tempo, estou avaliando o Gnus; busco e-mails do servidor do provedor com mpop, encaminho para o maildrop por pipe e depois salvo em uma das várias pastas maildir do diretório local de e-mail
    Para qual pasta vai é decidido por um grande script chamado .mailfilter, e as mailing lists são associadas principalmente pelo cabeçalho List-Id. Em anos assinando listas, nunca vi uma mailing list que não configurasse esse cabeçalho RFC2919
    E-mails pessoais eu geralmente filtro pelo cabeçalho From, e spam o provedor já trata tão bem que não tenho regras separadas; ele só cai na caixa de entrada algumas vezes por ano, então apago manualmente
    Esse método é quase igual ao fluxo clássico baseado em procmail, mas uso maildrop no lugar de procmail. Na época, vi um texto dizendo que o procmail não era mais mantido e fui procurar uma alternativa; acabei escolhendo o maildrop, que faz parte do Courier MTA, mas também pode ser usado sozinho
    A vantagem de um armazenamento local de e-mail baseado em maildir é que vários clientes de e-mail leves, ou MUAs no jargão de e-mail, podem ser usados sem problemas sobre a mesma estrutura de diretórios maildir
    Estou muito satisfeito com essa configuração, e sua utilidade já foi comprovada ao longo de vários anos. O que mais me preocupa agora é a tendência de provedores de e-mail deixarem disponível apenas a interface de webmail e pararem de oferecer até POP3 ou IMAP. No meu trabalho atual, já perdi essa briga, e é horrível usar um MS Exchange on-premises em que a única forma de ler e-mail é pelo webmail

    • A universidade em que estou atualmente tem quase 50 mil usuários registrados e não oferece suporte a POP3, IMAP nem apps modernos de autenticação baseados em OAuth
      Webmail, Outlook ou nada. O fato de terem escolhido ativamente não permitir nenhum outro cliente, independentemente do nível de suporte, parece quase um insulto ao meio que é o e-mail
      Dá para dizer “se gente suficiente usar, no fim eles vão ter que oferecer suporte a outros clientes de e-mail”, mas esse é exatamente o ponto. Deveria ser possível usar algo melhor do que webmail e Outlook
  • Antigamente eu operava meu próprio servidor de e-mail e servidor IMAP, e amigos hospedavam um MX de backup para mim, mas no fim migrei para o Fastmail para simplificar a vida
    Organizo o e-mail com scripts Sieve e com o Sieve por meio de “filters and rules” do Fastmail, depois trago tudo para o maildir dos meus equipamentos pessoais com isync/mbsync
    No fim do mês faço uma arrumação manual e, para pastas com pouco e-mail, arquivo a cada 6 meses ou todo ano em archive/<folder>-YYYYMM. Os arquivos também são sincronizados localmente e têm backup completo, mas ainda não tenho uma boa forma de lidar com revisão de patches

  • Até 2020 eu operava meu próprio servidor de e-mail, mas desisti por causa do volume de spam de entrada sempre mudando e assinei o Fastmail
    O Fastmail, para falar de forma gentil, parece um Squirrelmail turbinado. Tenho usado o recurso deles de Mail filtering para fazer filtros como enviar determinados remetentes para pastas específicas
    Independentemente do provedor, uso uma estrutura de arquivamento simples que dá para carregar facilmente em qualquer cliente de e-mail. É um esquema com uma pasta por ano, então tenho pastas como 2025, 2024, 2023, e cada uma tem mais ou menos mil e-mails
    Quando começa um novo ano, movo os e-mails de 2026 que estão na pasta Archive para a nova pasta 2026. Quando vou procurar um e-mail, só de olhar a pasta já dá para ter uma noção se foi dentro do último ano ou há 8 anos, então fica mais fácil encontrar

  • Uso tanto imapfilter quanto imap_tools

  • Uso Postfix → spfpolicyd → https://github.com/fazalmajid/gtldmilter → Procmail
    Sei que deveria usar Sieve. Em casos especiais, também já escrevi processadores de e-mail customizados como https://github.com/Dirac-Software/mailsink
    Como diz Cal Newport, e-mail não estruturado não deve ser usado para fluxos de trabalho recorrentes, e eu detesto fluxos baseados em e-mail, então evito. Por isso, em geral simpatizo com os objetivos do SourceHut, mas não cheguei a considerá-lo

  • Antigamente eu usava procmail, depois migrei para Sieve, e nos últimos anos uso scripts de tagging do notmuch
    É aí que essa marcação fica realmente poderosa. Dá para colocar tags temporárias em uma thread e, ao mesmo tempo, manter intactas as outras tags, e visualizar os e-mails de várias formas dependendo do que você quer fazer ou do que está procurando
    Combinando isso com um domínio de e-mail catchall e usando um endereço único para cada lista e serviço, filtrar e etiquetar fica muito fácil

  • Pergunta meio paralela, mas fiquei curioso sobre o que cada um usa para servidor de e-mail de saída
    No momento estou rodando meu próprio servidor de e-mail na DigitalOcean e também configurei DKIM/SPF/DMARC, mas a entrega ainda é um tanto instável
    Queria pagar por algo como o Proton Mail e usar como relay, então aceito recomendações

    • No começo eu ia usar o plano gratuito do SMTP2GO, mas no fim acabei indo com o combo padrão de Postfix + Dovecot
      Já houve uma discussão sobre email setups aqui antes, então talvez dê para achar uma ou duas recomendações lá dentro
    • Usei Postfix e Dovecot, mas faz mais de 5 anos que não administro meu próprio servidor, então não sei bem qual é o padrão hoje em dia
      Antes de desistir totalmente de hospedar meu próprio servidor de e-mail, eu estava olhando o Roundcube para tentar criar uma experiência melhor, mas aí descobri o Fastmail e larguei tudo
    • Outra opção é sair da DigitalOcean
      Eles não fazem o suficiente para evitar spammers, então a reputação é ruim. Gosto da Panix: por padrão eles bloqueiam a porta 25 de saída, mas abrem se você pedir, e se você for cliente também pode usar o servidor de e-mail de saída deles como relay. Nunca tive problemas de entrega
    • OpenSMTPD é muito mais fácil de configurar do que as alternativas, então acho que é um bom meio-termo para um smtpd pessoal
      Como já foi dito, a DigitalOcean não é uma boa escolha para servidor de e-mail
  • Há algum tempo escrevi um script Sieve simples que coloca e-mails com cabeçalho List-ID em suas respectivas pastas. Se a pasta não existir, ela é criada: https://gist.github.com/epilys/bf190ffb0147aa5ab863f7fa886a27da
    A desvantagem é que o valor de List-ID em algumas newsletters é algo difícil de ler para humanos, tipo um UUID

  • Eu uso Thunderbird
    Para arquivamento, o recurso padrão de arquivar já basta. Pelo que sei, ele salva os e-mails no disco como arquivos de texto. Dá para configurar o arquivamento em pastas por ano, ou por ano+mês, por exemplo
    No começo eu fazia isso, mas no fim decidi deixar o arquivo espelhar a estrutura de pastas da conta de e-mail
    Para listas de discussão, o cabeçalho List-Id é excelente. Eu envio os e-mails para um diretório específico com base nele. Quanto a rótulos, o Thunderbird suporta tags, mas eu não uso; só a pasta de destino já basta
    Não reviso muitos patches por e-mail, mas já usei um pouco o SourceHut, que trata o fluxo por e-mail como um recurso de primeira classe
    O Thunderbird tem seu próprio sistema de filtragem no lado do cliente, e isso funciona bem para mim porque minha máquina principal fica praticamente sempre ligada. Com o tempo, acumulei dezenas de filtros que movem mensagens com base no domínio — geralmente o domínio de topo — ou no cabeçalho List-Id de listas de e-mail
    Só que a história de sincronização do Thunderbird praticamente não existe em quase nenhum aspecto: arquivo, mensagens, configurações, filtros, basicamente tudo
    Há trabalho em andamento, mas da última vez que vi eles estavam focados em modernizar e unificar um codebase de backend que é resultado de mais de 20 anos de engenharia estilo velho oeste. Cada colaborador foi criando sua própria abordagem com SQLite, texto puro, arquivos JSON, bancos de dados mork etc., então só resta desejar boa sorte :D