Pourquoi SmtpClient.UseDefaultCredentials est ignoré?

Je suis en train d'envoyer des e-mails par l'intermédiaire d'un domaine de serveur SMTP qui utilise l'Authentification Windows Intégrée. Lorsqu'il est explicitement spécifier les informations d'identification, tout fonctionne bien:

using (var client = new SmtpClient("<Server>"))
{
    client.Credentials = new NetworkCredential("<User name>", "<Password>");
    client.EnableSsl = true;
    client.Send(...);
}

Serveur SMTP dans les journaux d'EHLO, STARTTLS, STARTTLS et EHLO, puis AUTH, MAIL, etc.

Lorsque, d'autre part, les informations d'identification par défaut sont utilisés:

using (var client = new SmtpClient("<Server>"))
{
    client.UseDefaultCredentials = true;
    client.EnableSsl = true;
    client.Send(...);
}
  • la SmtpException est levée, avec un message “Échec de l'envoi du mail.”;
  • l'intérieur IOException message: “Impossible de lire les données de la connexion de transport: Une connexion existante a dû être fermée par l'hôte distant.”, et
  • à l'intérieur de l'intérieur SocketException est: “Une connexion existante a dû être fermée par l'hôte distant”.

Serveur SMTP dans les journaux d'EHLO, STARTTLS, STARTTLS et EHLO, puis plus rien.

Le résultat est exactement le même (succès pour le premier échantillon, échec pour le second) si les options sont déplacés à partir du code source de l'Application.config configuration/system.net/mailSettings/smtp/network, et chaque fois que le numéro de port est spécifié ou non.

Étant donné que:

  • selon la documentation, SmtpClient.UseDefaultCredentials “[g]ets ou définit une valeur Booléenne qui détermine si le DefaultCredentials sont envoyés avec la demande”, qui
  • “Pour une application côté client, [CredentialCache.DefaultCredentials] sont généralement les informations d'identification Windows (nom d'utilisateur, mot de passe et domaine) de l'utilisateur exécutant l'application”, et que
  • le code testé est un Windows Forms application côté client, l'exécution à partir du même compte dont les informations d'identification spécifiées dans le premier exemple ci-dessus,

pourquoi le deuxième échec d'exemple, alors que le premier fonctionne?


Sur un forum il a été suggéré que le problème peut être causé par le serveur SMTP de ne pas soutenir NTLM. Par EHLOing le serveur, il semble que NTLM est pris en charge, l'une des lignes de la réponse étant 250-AUTH GSSAPI NTLM.

OriginalL'auteur Arseni Mourzenko | 2012-06-06