Достаточно ли хорош SMTP-сервер IIS для рабочего сервера?
Я планировал использовать SMTP-сервер, который поставляется с IIS7 (для веб-сайта), но потом я наткнулся на эту ссылку и начал беспокоиться (прочитайте принятое решение), с другой стороны, у меня ограниченный бюджет, и я не могу позволить себе купить MS Exchange или другой дорогой сервер, кроме того, я использую ASP.NET для своего приложения, которое очень хорошо работает с SMTP-сервером IIS (я собирался использовать опцию доставки папки раскладки, это особенно хорошо для веб-приложений так что пользователю не придется ждать, пока сообщение будет отправлено).
Я слышал о hmailserver, но, похоже, у него нет опции папки раскладки (хотя я не совсем уверен, поэтому, пожалуйста, исправьте меня, если я ошибаюсь). Я также не знаю, лучше ли производительность, чем SMTP-сервер IIS. Если это достаточно хорошо, я мог бы, вероятно, переслать SMTP-сервер IIS на hmailserver, чтобы я все еще мог использовать опцию папки раскладки. Извините, если я говорю, что разговариваю сам с собой, но я пытаюсь найти лучший вариант, и пока не ясно.
Любые предложения будут очень признательны...
5 ответов
IIS SMTP достаточно хорош и для высоких нагрузок.
Я бы определенно пошел с опцией hMailServer. Мы использовали IIS SMTP в прошлом, но когда возникает проблема, устранять неисправности очень сложно. hMailServer имеет намного лучшую регистрацию и лучший контроль над различными настройками SMTP.
Вы должны увидеть ответ без использования папки раскладки... мы используем hMailServer напрямую для наших приложений, и, похоже, все работает хорошо. Как вы упомянули, вы можете также выполнять ретрансляцию с помощью "умного" хоста, но, по моему опыту, для устранения неполадок лучше иметь меньше шагов.
Хорошо - мы использовали это в нашей производственной среде - но я должен предостеречь от решения:
1) Мы использовали его локально, чтобы очередь никогда не уменьшалась, мы отправили его на смарт-хост (мы использовали Postfix). Локальная очередь просто была там, чтобы принимать сообщения и отправлять их. Производительность доставки SMTP IIS на несколько доменов была ужасна с объемом.
2) Если вы перейдете непосредственно в папку DROP, ваше приложение будет привязано к этому решению. Если вы поставляете с CDO (который должен быть настроен для использования SMTP, а не только DROP), то у вас есть проблема с старшими символами в адресах электронной почты. Это привело к тому, что мы в конечном итоге доставили напрямую в наши почтовые ящики Postfix, несмотря на недостатки, связанные с отсутствием локальной очереди машин.
3) Входящие сообщения проходили через сторонний фильтр спама. Мы обнаружили, что DataEnter XWall идеально подходит по соотношению цена / производительность. Не совсем интуитивно понятный, но с хорошей производительностью и множеством опций для конфигурации. Если вы используете его, я рекомендую получить надстройку ESET от Ceratec, чтобы предоставить вам некоторые дополнительные функции, отсутствующие в основном продукте.
Кстати: вы можете использовать XWall для доставки исходящих сообщений - мы сделали это для нескольких приложений, и это работало довольно хорошо. Postfix будет обрабатывать большую нагрузку бесплатно, но означает управление другим приложением и ОС (Linux)...
Это будет хорошо с низким до умеренного объема. Если он будет использоваться для входящей почты, в конечном итоге вы будете перенаправлены на сервер другого типа из-за проблем со спамом и недостатка функциональности.
Это несмотря на тот факт, что ядро IIS SMTP довольно прочное - это именно то, что Exchange использует для обработки уровня SMTP. Microsoft просто не вкладывает много средств в инструменты управления или делает их доступными, потому что они хотят, чтобы вы платили за Exchange.
Я использовал опцию IIS SMTP для нескольких крупных веб-сайтов, отправляющих большое количество почты (более 2000 в день). Во всех случаях у меня не было проблем (стук по дереву). Если вы выбрали SMTP IIS, ознакомьтесь с этой статьей для получения справки по устранению неполадок. Большинство проблем, с которыми я столкнулся с IIS SMTP, были быстро решены с помощью небольшого устранения неполадок DNS.
http://msmvps.com/blogs/bernard/archive/2004/09/28/14480.aspx