IMAP com polling, em vez de webhook ou API de provedor

Três plataformas internacionais de geração de leads entregam os contatos por e-mail, para um endereço da empresa. São cerca de 50 leads por dia útil, e esse volume já chegava assim antes de existir sistema: os leads eram transcritos à mão da caixa de entrada para uma planilha, a caixa era a fila, e a planilha era o cadastro. O sistema não tinha nenhuma infraestrutura de recebimento de e-mail: nem biblioteca, nem serviço, nem IMAP, nem parser.

1. Independência de provedor, porque a empresa pode trocar de e-mail sem que isso vire projeto.
2. Latência aceitável. O lead não é urgente ao ponto de exigir tempo real, mas é enviado para até quatro empresas concorrentes: minutos importam, segundos não.
3. Custo zero de terceiros.
4. Caminho de evolução para quando as plataformas oferecerem API.

• API de e-mail de um provedor de nuvem específico (Microsoft ou Google): traria notificação por push, ao custo de amarrar a captura a um provedor, exigir configuração de identidade corporativa e complicar a autenticação servidor a servidor. Descartada por lock-in.
• Webhook de entrada por serviço de e-mail transacional: daria tempo real e payload estruturado, mas exige redirecionar o registro de MX do domínio para um serviço pago, com risco de perda quando o webhook falha. Descartada por razão de negócio: mexer no MX do domínio corporativo por causa de captura de lead é risco desproporcional ao ganho.
• Polling IMAP com o MailKit, biblioteca madura de e-mail em .NET, disparado por job.

O que não foi avaliado, e devia ter sido: o IMAP IDLE, que entrega notificação quase em tempo real sem mexer no MX e sem amarrar a um provedor, ou seja, ataca os dois motivos que derrubaram as outras duas opções. Ele não entrou na comparação, e não por um critério: passou despercebido. Fica registrado assim porque inventar uma justificativa depois seria pior do que admitir a falha na avaliação.

A captura é por IMAP, com polling a cada dois minutos, usando o MailKit. O .NET não traz cliente IMAP nativo, e o SmtpClient do System.Net.Mail, além de só enviar, é desaconselhado pela própria documentação para código novo, que aponta o MailKit como alternativa. Funciona com qualquer servidor IMAP, então trocar de provedor é alterar host, porta e credencial. A conexão tem política de retentativa com backoff exponencial (três tentativas, com timeout por tentativa e timeout global), e o job avança pelo identificador da última mensagem processada, em vez de reler a caixa. A senha da caixa fica criptografada no banco, com a chave em variável de ambiente, e nunca aparece em log nem em resposta de API; ela tem inclusive um endpoint próprio de alteração, fora do update comum, para que a credencial não circule em toda edição de rótulo. O caminho de evolução ficou registrado: se as plataformas passarem a oferecer webhook, o parser e o registro de e-mail são reaproveitados como caminho alternativo de entrada, sem reescrever o núcleo.