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