#c# #asp.net #asp.net-mvc #smtpclient #system.net
#c# #asp.net #asp.net-mvc #smtpclient #system.net
Вопрос:
У нас есть asp.net приложение, которое заботится об отправке наших электронных писем в продукте. Мы хотели бы использовать учетную запись пула приложений для отправки аутентифицированных электронных писем на наш сервер Exchange.
Наш web.config выглядит следующим образом:
<smtp deliveryMethod="Network" from="support@company.com">
<network host="mail.company.com" defaultCredentials="true"/>
</smtp>
Основываясь на документах msdn, я бы ожидал, что при отправке электронной почты будут использоваться учетные данные пула приложений. Однако во время выполнения не предпринимается никаких попыток аутентификации.
Копание в системе.Чистый код, похоже, что опция DefaultCredentials заставит нас использовать CredentialCache.Свойство DefaultCredentials, которое заполняет учетные данные пустым именем пользователя и паролем. Таким образом, это может быть причиной проблемы.
Из соображений безопасности мы не хотим вводить явное имя пользователя и пароль в разделе конфигурации smtp. Мы вообще не хотим использовать открытый ретранслятор (который мы используем в настоящее время), потому что у нас нет способа ограничить или остановить электронную почту.
Мы хотели бы, чтобы пул приложений аутентифицировался, чтобы мы могли отключить почтовый ящик в ситуации, когда наше приложение обнаруживает ошибку и отправляет нам спам по электронной почте (что уже произошло).
Как мы можем настроить наше приложение на использование учетных данных пула приложений для отправки аутентифицированной электронной почты?
Комментарии:
1. Используете ли вы интегрированную аутентификацию?
2. Мы не передаем учетные данные от пользователя, если это то, что вы спрашиваете, мы установили для пула приложений некоторую учетную запись домена, которая использует анонимную учетную запись IUSR для доступа к элементам на диске.
3. Что это возвращает?
System.Security.Principal.WindowsIdentity.GetCurrent().Name
Ответ №1:
В коде, который отправляет электронное письмо, сделайте что-то вроде этого…
SmtpClient client = new SmtpClient();
client.UseDefaultCredentials = false;
client.Credentials=new NetworkCredential("myusername","mypassword");
При этом будут использоваться указанные имя пользователя и пароль. При необходимости вы можете получить имя пользователя и пароль из зашифрованного файла, веб-службы или другого безопасного хранилища.
Другой альтернативой является шифрование вашего файла конфигурации.
Комментарии:
1. Наши специалисты по безопасности не хотят, чтобы разработчики имели доступ к учетным данным или знали о его зашифрованном местоположении.
2. Разработчики должны знать, где. Не могу использовать его, если они не могут его найти. Просто позвольте учетной записи с низким уровнем привилегий отправлять электронное письмо. Храните пароль в зашифрованном виде, чтобы они не могли его увидеть.
Ответ №2:
Я подозреваю, что это невозможно, поскольку для аутентификации SMTP в большинстве случаев требуется имя пользователя и пароль. Если вы используете пул приложений под любой из встроенных учетных записей (например NETWORK SERVICE , или ApplicationPoolIdentity ), по сути, нет учетных данных для передачи для использования SMTP. Или, чтобы заставить их работать, это выходило бы за рамки стандартной спецификации SMTP, используя какую-то сумасшедшую форму нестандартной проверки подлинности Windows.
Затем, если вы используете пул приложений как пользователь, имя пользователя и пароль хранятся на сервере в зашифрованном, но обратимом формате. Это имя пользователя и пароль могут быть получены и использованы при более масштабной атаке на сеть, поэтому больший риск для безопасности, если случайное приложение может быть запущено для получения учетных данных действительного локального / доменного пользователя. Или, что еще хуже, можете ли вы представить себе запущенное настольное приложение .NET, способное извлекать текущие учетные данные запущенного пользователя? Все быстро катится вниз, если вы можете получить такие учетные данные.
У вас есть несколько вариантов, включая использование веб-службы для отправки электронной почты, создание локального SMTP-сервера, который разрешает неаутентифицированный доступ только с определенных IP-адресов, ввод имени пользователя и пароля в код приложения, шифрование web.config (оба варианта в ответе Мейсона). Вероятно, есть еще несколько вариантов, которые я не могу придумать прямо сейчас. Возможно, вам захочется обратиться к системному администратору в вашей инфраструктуре, чтобы узнать, какие варианты возможны.