Окружающая среда:
Нашему веб-приложению, как и многим другим, необходимо отправлять почту. Только отправка, без получения.
Раньше мы включали службу IIS 6 SMTP на каждом веб-сервере и использовали классы .NET SMTP для удаления почтовых файлов в папку получения. Работает отлично.
Чтобы упростить среду и запустить меньшее количество служб на веб-серверах, я рассматриваю возможность запуска службы SMTP только на одной служебной службе Windows и предоставления доступа к каталогу раскладки для остальных веб-серверов в ферме с помощью файловый ресурс. Веб-приложения ASP.NET просто помещают свои почтовые файлы в общую папку получения, а единая служба SMTP будет обрабатывать поток исходящей почты для всех веб-серверов. Меня не беспокоит объем или способность службы SMTP не отставать, это не будет проблемой.
Плюсы:
Минусы:
Это сработает?
Изменить: размышляя о моей идее автономных файлов, я не уверен, что это лучший подход. Автономным файлам требуется запланированная задача для планирования синхронизации, и каждый раз, когда она запускается, я буду извлекать почтовые файлы всех других веб-серверов из локального кеша каждого другого сервера. Может быть, лучше просто скопировать файлы в локальной папке, а какое-то другое задание (запланированное роботизированное копирование) будет пытаться скопировать их в удаленный файловый ресурс, когда он появится. Подумал о DFSR, но опять же, я буду перетасовывать все почтовые файлы на все веб-серверы, а это расточительно.
Я не понимаю, о чем вы говорите. Вы пытаетесь упростить настройку, добавив больше вопросов сложности и безопасности.
SMTP - это решение вашей проблемы. Осталось только найти хорошую реализацию. SMTP поставляется со встроенной обработкой очереди (без конфликтов имен файлов), отказоустойчивым, учитывает избыточность из-за нескольких MX и является древним, хорошо протестированным протоколом. Кстати, он не зависит от операционной системы.
Вы хотите заменить это на единую точку отказа, зависимую от планировщика, связанную с операционной системой, недокументированную и новую непроверенную процедуру повторного изобретения колеса. Также вы выставляете дроп-инбокс для всех, а не только для этих 5 серверов.
Используйте простой сервер с промежуточным хранением (например, E-MailRelay) на веб-серверах и центральном SMTP-сервере, на который пересылаются сообщения. Затем этот SMTP-сервер будет использоваться для окончательной доставки. Затем вы можете защитить свой центральный SMTP, чтобы он принимал соединения только с этих 5 серверов и выполнял отклонение на основе отправителя или любой другой фильтр / блокировку, который вы хотите уменьшить потенциальный (спам-) риск для общественности.
Это решение обладает всеми преимуществами прозрачности (ведение журнала + мониторинг), простоты (один процесс), соответствия (стандартный Интернет-протокол) и целостности (подтверждение доставки). Нет необходимости обменивать это самодельными обходными путями.
Лучше было бы использовать SMTP через tcp / ip, то есть прослушивать порт 25 (или любой другой порт), а затем использовать MailMessage и SmtpClient System.Net.Mail.
Затем вы можете установить балансировщик нагрузки перед SMTP-сервером и подключить каждый сервер к этому имени / IP-адресу с балансировкой нагрузки.