Я убираю наш 10-летний веб-сервер (больше никакого Pentium III - ура!). Некоторые страницы размещенного на нем веб-сайта имеют формы, которые позволяют отправлять электронные письма определенным людям. Эти электронные письма отправляются через SMTP-сервер в IIS. Мы также используем этот smtp-сервер для некоторых других целей, включая сообщения от нашего программного обеспечения службы поддержки и оповещения по электронной почте от некоторых из наших сетевых устройств. Это единственный оставшийся SMTP-сервер в кампусе. Остальная часть нашей электронной почты хранится в Google Apps для образования. Сервер настроен со смарт-хостом, указанным на smtp.gmail.com, и имеет хорошее имя пользователя / пароль (с tls) для связи с сервером Google. Другими словами, все, что он делает, - это пересылает сообщения из программного обеспечения в университетском городке в нашу почтовую систему за пределами кампуса.
К сожалению, сообщения, отправленные через этот сервер, застревают в папке mailroot / Queue. Если я буду ждать слишком долго, я надеюсь, что они наконец перейдут на BadMail. Насколько я могу судить, эта новая конфигурация сервера точно управляет старой конфигурацией. Мои собственные исследования показывают, что DNS работает нормально (наиболее частое предложение для подобных проблем, обнаруженных в Интернете, до такой степени, что оно заглушает другие идеи). Журнал событий содержит записи следующего вида:
Доставка сообщения на хост 74 .125.148.14 не удалась при доставке в удаленный домен york.edu по следующей причине: удаленный сервер не ответил на попытку подключения.
Для меня это звучит как проблема с брандмауэром (я его отключил - не повезло) или проблема аутентификации / шифрования. Я трижды проверил, что имя пользователя и пароль верны, а опция шифрования TLS включена (как и должно быть). Новый сервер установлен в Hyper-v, поэтому я попытался отключить брандмауэр на хосте, но это не помогло.
Обновлено:
Кроме того, я могу telnet smtp.gmail.com 25 и я получаю ожидаемые 220 ответов. Конечно, я не могу пройти дальше через telnet, потому что для этого требуется команда STARTTLS, но я, по крайней мере, зашел так далеко.
Любые идеи?
Этот IP-адрес принадлежит серверу Postini согласно обратному Поиск DNS а затем, выполнив whois search. Первое, похоже, не позволяет ссылаться на результаты, поэтому вам придется искать самостоятельно.
По сути, поскольку Google приобрел Postini, я ожидаю, что долгосрочная проблема связана не с их серверами в свете их довольно большой серверной фермы.
Учитывая, что сообщение об ошибке исходит от IIS, а не повторяется эхо сообщения от какого-то удаленного почтового сервера, я бы сказал, что у вас есть проблемы с сетевым подключением между вашим виртуальным сервером и внешним миром.
Выполнить
telnet 74.125.148.14 25
Я могу подключиться к этому:
Connected to 74.125.148.14.
Escape character is '^]'.
220 Postini ESMTP 188 y6_34_1c0 ready. CA Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements.
..если вы не можете, тогда ваша проблема связана с сетью.
Хорошо, я снова упустил очевидное. При настройке сервера smtp после внесения изменений я перехожу в корень окна консоли управления для IIS и приказываю ему перезапустить, чтобы убедиться, что все изменения были применены. К сожалению, это не привело к перезапуску службы smtp, и мои изменения не были внесены. Как только я исправил это поведение, я начал видеть фактические сообщения об ошибках, и исправить их было несложно.