Expor a pasta IIS SMTP Pickup como um compartilhamento de arquivos - má ideia?

Question

Ambiente:

• Farm da Web do IIS
  • 5 servidores
  • Windows Server 2008 R2
  • IIS 7.5
  • Aplicativo da Web ASP.NET 3.5 e 4.0

Nosso aplicativo da web, como muitos, precisa enviar e-mails. Enviar apenas, sem receber.

No passado, ativamos o serviço SMTP do IIS 6 em cada servidor Web e usamos as classes SMTP do .NET para descartar arquivos de mensagens na pasta de recebimento. Funciona bem.

Para simplificar o ambiente e executar menos serviços nos servidores da web, estou considerando a viabilidade de executar o serviço SMTP em apenas um serviço do utilitário Windows e expondo o diretório de recebimento ao restante dos servidores da web no farm usando um compartilhamento de arquivos. Os aplicativos da Web do ASP.NET simplesmente descartarão seus arquivos de mensagens na pasta de recebimento compartilhada e o único serviço SMTP manipulará o fluxo de mensagens de saída para todos os servidores da Web. Eu não estou preocupado com o volume ou a capacidade do serviço SMTP de acompanhar, isso não será um problema.

Os profissionais:

• Administração e configuração simplificadas
• Menor carga e reduzido vetor de ataque nos servidores da web
• Ponto único de solução de problemas se houver problemas de e-mail

Os contras:

• Ponto único de falha
• Se eu precisar reinicializar a caixa do utilitário, perderei os recursos de e-mail de saída. Isso pode ser potencialmente atenuado usando o cache de pastas off-line para o compartilhamento de arquivos nos servidores da web. Não testei isso, mas possivelmente os servidores da Web, não detectando nenhuma conexão com o compartilhamento de arquivos, podem soltar seus arquivos localmente, para serem automaticamente sincronizados com o servidor SMTP quando ele for reinicializado.
• Conflito de nomes de arquivos por email - é necessário garantir que o ASP.NET, ao gravar os arquivos .eml, use um nome exclusivo garantido em todo o Web farm. O código-fonte SmtpClient indica que um GUID é usado para nomear os arquivos, mas a MS pode alterar isso em uma implementação futura.

Isso funcionará?

Editar: Pensando mais na minha ideia de Arquivos Offline, não tenho certeza se essa é a melhor abordagem. Arquivos offline requer uma tarefa agendada para agendar a sincronização e, toda vez que for executada, puxarei todos os outros arquivos de mensagens dos servidores da Web para o cache local de todos os outros servidores. Talvez uma idéia melhor seja apenas empilhar os arquivos em uma pasta local, e algum outro trabalho (robocopy programado) tenta copiá-los para o compartilhamento de arquivos remoto sempre que estiver ativo. Pensei em DFSR, mas, novamente, estarei embaralhando todos os arquivos de mensagens para todos os servidores da web, e isso é um desperdício.

    

Answer 1

A melhor aposta seria usar SMTP via tcp / ip, ou seja, ouvir na porta 25 (ou qualquer outra porta) e, em seguida, usar MailMessage e SmtpClient de System.Net.Mail.

Em seguida, você pode lançar um balanceador de carga na frente do servidor SMTP e fazer com que cada servidor se conecte a esse nome / ip com carga balanceada.

    

Answer 2

Eu não consigo ver seu argumento aqui. Você tenta simplificar sua configuração apresentando mais problemas de complexidade e segurança.

O SMTP é a solução para o seu problema. Agora você só precisa procurar uma boa implementação. O SMTP vem com manipulação de filas interna (sem colisões de nome de arquivo), resistente a falhas, com reconhecimento de redundância devido a múltiplos MX e é um protocolo antigo e bem testado. A propósito, é independente do sistema operacional.

Você deseja trocar isso por ponto único de falha, dependente do Agendador, limite do Sistema Operacional, não documentado e novo procedimento de reinventar a roda não testado. Além disso, você expõe um drop-in-box para todos, não apenas para esses 5 servidores.

Use um servidor simples de armazenamento e encaminhamento (como E-MailRelay ) nos servidores Web e um servidor SMTP central onde os e-mails são encaminhados para. Este servidor SMTP será então usado para a entrega final. Então você pode proteger seu SMTP central para aceitar apenas conexões desses 5 servidores e fazer rejeições baseadas em remetentes ou qualquer filtro / bloco que você queira reduzir o risco potencial (Spam) para o público.

Esta solução tem todos os benefícios da transparência (registro + monitoramento), simplicidade (um processo), conformidade (protocolo padrão da Internet) e integridade (confirmação de entrega). Não há necessidade de trocar soluções de self-made.