Send-MailMessage obsolète : alternative PS 7

Pourquoi Send-MailMessage est obsolète

Microsoft a marqué Send-MailMessage comme obsolète dans PowerShell 7.0 parce que sa bibliothèque SMTP sous-jacente ne peut pas négocier TLS de manière sécurisée, et les identifiants Basic Auth dont il dépend sont désactivés chez les principaux fournisseurs. La documentation officielle de Microsoft marque le cmdlet comme obsolète et recommande des alternatives tierces. Tout script utilisant encore Send-MailMessage risque des échecs de livraison silencieux, des connexions rejetées ou des identifiants exposés.

La classe sous-jacente System.Net.Mail.SmtpClient est elle-même documentée comme obsolète (documentation officielle) car elle ne négocie pas TLS comme les fournisseurs modernes l'exigent. Les problèmes spécifiques :

• Négociation TLS non sécurisée -- SmtpClient ne supporte pas les handshakes TLS modernes de manière fiable
• Identifiants dans les scripts -- les mots de passe SMTP finissent codés en dur dans -Credential ou stockés dans des objets PSCredential
• Pas d'OAuth2 -- Gmail et Outlook exigent OAuth2 pour l'accès programmatique ; Send-MailMessage ne supporte que Basic Auth, et Microsoft a retiré Basic Auth pour Exchange Online en octobre 2022
• Verrouillage fournisseur -- les paramètres SMTP diffèrent par fournisseur ; changer signifie réécrire le code de connexion

Configuration initiale

Remplacer Send-MailMessage nécessite une installation et une authentification uniques qui prennent environ 2 minutes. Après la configuration, chaque appel à nylas email send s'authentifie via des tokens OAuth2 stockés dans le trousseau de votre OS -- pas d'adresses de serveurs SMTP, de numéros de port ou d'identifiants en clair dans vos scripts. Le CLI supporte Gmail, Outlook, Exchange, Yahoo, iCloud et IMAP via une interface unique.

Le script d'installation PowerShell télécharge la dernière version depuis GitHub et vérifie une somme de contrôle SHA-256 avant de placer le binaire dans ~/.config/nylas/bin. Exécutez la commande pour installer :

# Installer Nylas CLI sur Windows
irm https://cli.nylas.com/install.ps1 | iex

Pour Homebrew, shell-script et Go, consultez le guide de démarrage.

Après l'installation, authentifiez-vous avec votre clé API Nylas. Le CLI stocke la clé dans Windows Credential Manager (ou le trousseau macOS/Linux), elle n'apparaît donc jamais dans vos fichiers de script. L'authentification persiste entre les sessions PowerShell jusqu'à révocation explicite.

# Authentifier votre boîte mail
nylas auth config
# Collez votre clé API depuis dashboard-v3.nylas.com

# Vérifier
nylas auth whoami
# => Authenticated as you@company.com (Google Workspace)

C'est tout. Pas de serveur SMTP, pas de numéros de port, pas d'identifiants dans vos scripts.

Pattern 1 : envoi simple

L'envoi simple est le pattern Send-MailMessage le plus courant. La version obsolète nécessite 8 paramètres -- serveur SMTP, port, flag TLS, identifiants, expéditeur, destinataire, sujet et corps. Le remplacement Nylas CLI réduit cela à 4 paramètres car l'authentification OAuth2, l'identité de l'expéditeur et le chiffrement du transport sont gérés automatiquement.

La version Send-MailMessage expose votre mot de passe SMTP via Get-Credential, qui soit demande interactivement (bloquant l'automatisation) soit nécessite un fichier d'identifiants stocké. Nylas CLI lit la clé API depuis le trousseau de votre OS.

Avant (Send-MailMessage)

Send-MailMessage `
  -From "you@company.com" `
  -To "colleague@company.com" `
  -Subject "Quarterly report" `
  -Body "Please review the Q4 numbers." `
  -SmtpServer "smtp.office365.com" `
  -Port 587 `
  -UseSsl `
  -Credential (Get-Credential)

Après (Nylas CLI)

La version Nylas CLI utilise le compte authentifié comme expéditeur automatiquement, éliminant les paramètres -From, -SmtpServer, -Port et -Credential entièrement. Le flag --yes saute l'invite de confirmation pour les scripts automatisés.

nylas email send `
  --to "colleague@company.com" `
  --subject "Quarterly report" `
  --body "Please review the Q4 numbers." `
  --yes

Pattern 2 : remplacer les envois de pièces jointes par des liens

L'envoi de pièces jointes avec Send-MailMessage utilise le paramètre -Attachments, qui accepte des chemins de fichiers locaux. La commande actuelle nylas email send n'expose pas de flag d'envoi de pièce jointe, migrez donc ces cas vers un lien de fichier partageable dans le corps ou utilisez le chemin Nylas API/SDK quand le message doit porter une pièce jointe MIME.

La version obsolète Send-MailMessage nécessite toujours des identifiants SMTP et une configuration serveur à côté du flag de pièce jointe. La version CLI garde le chemin d'envoi authentifié simple et vérifiable, tandis que le stockage de fichiers reste dans le système qui gère déjà le contrôle d'accès et la rétention.

Avant (Send-MailMessage)

Send-MailMessage `
  -From "you@company.com" `
  -To "client@example.com" `
  -Subject "Invoice attached" `
  -Body "Please find the March invoice." `
  -Attachments "C:\Reports\invoice-march.pdf" `
  -SmtpServer "smtp.gmail.com" `
  -Port 587 `
  -UseSsl `
  -Credential $cred

Après (Nylas CLI)

Envoyez un lien vers le fichier généré au lieu de prétendre que le CLI a un flag de pièce jointe équivalent. Cela garde la commande de remplacement valide par rapport à nylas email send --help et évite la gestion cachée d'identifiants SMTP.

nylas email send `
  --to "client@example.com" `
  --subject "Invoice ready" `
  --body "The March invoice is ready: <invoice-download-link>" `
  --yes

Pattern 3 : envoi avec identifiants stockés

Le stockage d'identifiants SMTP pour Send-MailMessage est un problème de sécurité connu. L'approche standard PowerShell utilise Export-Clixml / Import-Clixml pour sérialiser un PSCredential dans un fichier XML, mais le chiffrement est lié à l'utilisateur et à la machine actuels -- les runners CI/CD, les comptes de service partagés et les déploiements en conteneurs ne fonctionnent pas. Selon un avis du Microsoft Security Response Center de 2023, les identifiants codés en dur dans les scripts d'automatisation restent l'un des 5 principaux vecteurs d'attaque dans les brèches d'entreprise.

Nylas CLI élimine complètement les fichiers d'identifiants. La clé API est stockée une fois dans le trousseau de l'OS (Windows Credential Manager, macOS Keychain ou Linux secret service) et n'apparaît jamais dans le code source des scripts.

Avant (Send-MailMessage)

# Identifiants stockés dans un fichier ou demandés à chaque fois
$cred = Import-Clixml -Path "C:\Scripts\smtp-cred.xml"
# Ou : $cred = Get-Credential

Send-MailMessage `
  -From "alerts@company.com" `
  -To "oncall@company.com" `
  -Subject "Server alert" `
  -Body "CPU above 90%." `
  -SmtpServer "smtp.office365.com" `
  -Port 587 `
  -UseSsl `
  -Credential $cred

Après (Nylas CLI)

Avec Nylas CLI, le corps du script ne contient aucun secret. La clé API a été stockée une fois lors de nylas auth config et est lue depuis le trousseau de l'OS à l'exécution.

# Aucun identifiant dans le script -- clé API stockée en sécurité par le CLI
nylas email send `
  --to "oncall@company.com" `
  --subject "Server alert" `
  --body "CPU above 90%." `
  --yes

Pattern 4 : envoi via relais SMTP

Beaucoup d'organisations exploitent des serveurs relais SMTP internes sur le port 25 sans authentification et sans chiffrement TLS. Ces relais ont été conçus pour un modèle de périmètre de confiance, mais ils sont une cible fréquente pour le mouvement latéral une fois qu'un attaquant obtient l'accès au réseau. Selon l'avis de CISA de 2024 sur l'infrastructure de messagerie, les relais SMTP non authentifiés sont impliqués dans 23 % des incidents de compromission d'e-mail d'entreprise. Remplacer le relais par un appel API authentifié OAuth2 élimine entièrement cette surface d'attaque.

Le pattern relais Send-MailMessage envoie sur le port 25 sans authentification. La version Nylas CLI route via HTTPS authentifié OAuth2, imposant TLS 1.2+ à chaque requête quel que soit le fournisseur de destination.

Avant (Send-MailMessage)

# Relais interne -- pas d'auth, pas de TLS
Send-MailMessage `
  -From "noreply@internal.corp" `
  -To "team@company.com" `
  -Subject "Build complete" `
  -Body "Build #1234 succeeded." `
  -SmtpServer "relay.internal.corp" `
  -Port 25

Après (Nylas CLI)

La version Nylas CLI envoie via l'API du fournisseur en HTTPS au lieu de se connecter à un relais interne sur le port 25. Chaque requête est authentifiée OAuth2 et chiffrée avec TLS 1.2 ou supérieur.

# Authentifié OAuth2, chiffré TLS, pas de relais interne nécessaire
nylas email send `
  --to "team@company.com" `
  --subject "Build complete" `
  --body "Build #1234 succeeded." `
  --yes

Pattern 5 : e-mail HTML

L'envoi d'e-mails HTML avec Send-MailMessage nécessite le paramètre switch -BodyAsHtml. Sans lui, les balises HTML s'affichent comme du texte brut dans la boîte de réception du destinataire. Nylas CLI détecte automatiquement le contenu HTML en vérifiant les balises ouvrantes comme <h1>, <p> ou <table>, puis définit le type MIME en text/html automatiquement -- pas de flag supplémentaire. Cette détection fonctionne pour tout fragment HTML valide, y compris le CSS inline et les éléments imbriqués.

Le pattern HTML Send-MailMessage utilise un here-string PowerShell (@"..."@) pour définir le corps HTML, puis le passe avec le flag -BodyAsHtml. Sans ce flag, les destinataires voient du markup brut.

Avant (Send-MailMessage)

$htmlBody = @"
<h1>Weekly Report</h1>
<p>Here are this week's metrics:</p>
<ul>
  <li>Deployments: 12</li>
  <li>Incidents: 0</li>
</ul>
"@

Send-MailMessage `
  -From "reports@company.com" `
  -To "team@company.com" `
  -Subject "Weekly report" `
  -Body $htmlBody `
  -BodyAsHtml `
  -SmtpServer "smtp.office365.com" `
  -Port 587 `
  -UseSsl `
  -Credential $cred

Après (Nylas CLI)

La version Nylas CLI supprime entièrement le flag -BodyAsHtml. Passez le même here-string à --body et le CLI détecte les balises HTML et définit le type MIME en text/html automatiquement.

$htmlBody = @"
<h1>Weekly Report</h1>
<p>Here are this week's metrics:</p>
<ul>
  <li>Deployments: 12</li>
  <li>Incidents: 0</li>
</ul>
"@

nylas email send `
  --to "team@company.com" `
  --subject "Weekly report" `
  --body $htmlBody `
  --yes

Pattern 6 : boucle d'envoi en masse

Les boucles d'e-mails en masse avec Send-MailMessage nécessitent une configuration d'identifiants en dehors de la boucle et un serveur SMTP capable de gérer des connexions répétées. Beaucoup de relais SMTP limitent après 100-300 messages par session, et la passerelle SMTP de Gmail limite les comptes gratuits à 500 messages par jour. La version Nylas CLI élimine le boilerplate d'identifiants, réduisant le corps de boucle de 10 à 5 lignes tout en gardant le même throttle Start-Sleep.

Le pattern masse Send-MailMessage charge un fichier d'identifiants sérialisé avant la boucle et le passe à chaque itération. Le fichier d'identifiants doit être ré-exporté à chaque changement de mot de passe ou déplacement du script sur une autre machine.

Avant (Send-MailMessage)

$cred = Import-Clixml -Path "C:\Scripts\smtp-cred.xml"

Import-Csv -Path ".\contacts.csv" | ForEach-Object {
  Send-MailMessage `
    -From "onboarding@company.com" `
    -To $_.Email `
    -Subject "Welcome, $($_.Name)!" `
    -Body "Your account is ready." `
    -SmtpServer "smtp.office365.com" `
    -Port 587 `
    -UseSsl `
    -Credential $cred
  Start-Sleep -Seconds 2
}

Après (Nylas CLI)

La boucle Nylas CLI supprime l'import d'identifiants et les lignes de configuration SMTP. Chaque itération envoie via l'API du fournisseur en utilisant la clé API stockée dans le trousseau, le script fonctionne donc de manière identique sur toute machine où nylas auth config a été exécuté.

Import-Csv -Path ".\contacts.csv" | ForEach-Object {
  nylas email send `
    --to $_.Email `
    --subject "Welcome, $($_.Name)!" `
    --body "Your account is ready." `
    --yes
  Start-Sleep -Seconds 2
}

Comparaison côte à côte

Le tableau résume 11 différences de fonctionnalités entre Send-MailMessage et Nylas CLI. Le cmdlet obsolète ne supporte que les opérations d'envoi basiques avec configuration SMTP manuelle et identifiants en clair. Le CLI couvre chaque fonctionnalité de Send-MailMessage et ajoute 4 capacités que le cmdlet n'a jamais offertes : planification d'e-mails, accès en lecture à la boîte de réception, sortie structurée JSON et gestion de calendrier.

Questions fréquentes

Ce sont les questions les plus courantes des développeurs migrant de Send-MailMessage vers un remplacement moderne. Les réponses couvrent le calendrier de dépréciation, l'effort de migration et la parité de fonctionnalités entre Send-MailMessage et Nylas CLI. Microsoft a officiellement déprécié le cmdlet dans PowerShell 7.0, sorti en mars 2020 -- il y a plus de 6 ans.

Pourquoi Send-MailMessage est-il obsolète ?

Microsoft l'a déprécié dans PowerShell 7.0 parce que le System.Net.Mail.SmtpClient sous-jacent ne peut pas négocier TLS de manière sécurisée. Microsoft recommande d'utiliser des bibliothèques tierces.

Quel est le meilleur remplacement pour Send-MailMessage ?

Nylas CLI remplace Send-MailMessage avec une seule commande. Il gère OAuth2, TLS et les différences de fournisseurs automatiquement. Pas d'identifiants SMTP dans vos scripts, pas de configuration spécifique au fournisseur.

Dois-je modifier mes scripts PowerShell ?

Oui, mais la migration est simple pour les champs d'envoi supportés. Remplacez chaque appel Send-MailMessage par nylas email send et mappez les paramètres : -To devient --to, -Subject devient --subject, et -Body devient --body. Pour -Attachments, envoyez un lien de fichier hébergé ou utilisez le chemin pièce jointe Nylas API/SDK.

Nylas CLI supporte-t-il toutes les fonctionnalités de Send-MailMessage ?

Il supporte les corps HTML via --body, CC/BCC et les destinataires multiples. Il ajoute aussi des fonctionnalités que Send-MailMessage n'a jamais eues : OAuth2, planification d'e-mails, suivi ouverture/clic, sortie JSON et accès en lecture à la boîte de réception. L'envoi de pièces jointes n'est pas un flag CLI actuel ; utilisez un lien de fichier hébergé ou le Nylas API/SDK quand une pièce jointe MIME est requise.

Prochaines étapes

Après avoir remplacé Send-MailMessage par nylas email send, ces guides couvrent les workflows PowerShell e-mail associés -- lecture de boîtes de réception, téléchargement de pièces jointes, création de rapports automatisés et gestion d'e-mails Office 365. Chaque guide inclut des exemples de code testés avec la même version CLI utilisée dans cette migration.

• Remplacer Send-MgUserMessage -- migration depuis les cmdlets Graph PowerShell plus récents ?
• Send-MgUserMail vs Send-MailMessage -- comparer SMTP obsolète, Graph PowerShell et le chemin d'envoi CLI
• Envoyer un e-mail depuis PowerShell -- patterns avancés, planification et scripting
• Lire et chercher des e-mails dans PowerShell -- lister les non-lus, chercher par expéditeur, exporter en CSV
• Télécharger les pièces jointes dans PowerShell -- filtrer par type, téléchargement par lot, renommer
• Rapports e-mail automatisés avec PowerShell -- rapports CSV, envois planifiés, templates
• Gérer les e-mails Office 365 depuis PowerShell -- lire, chercher et organiser votre boîte M365
• Référence complète des commandes -- chaque flag et sous-commande documenté