SmtpClient MailKit und Office365 Two-Factor-Authentication (2FA)

Hallo Forum!

Ich habe eine Windows Forms Anwendung mit der ein Anwender E-Mail verschicken kann.

Ein Anwender kann hierfür seine SMTP Einstellungen (Benutzername, Kennwort, Hostname, Port, SSL ) entsprechend hinterlegen.
Die Anwendung verwende hierfür im Augenblick noch System.Net.Mail.SmtpClient was ich aber als nächstes auf das empfohlene MailKit.Net.Smtp.SmtpClient umstellen möchte.

Meine Frage bezieht sich jetzt auf einen Anwender der Office365 mit aktivierten Two-Factor-Authentication (2FA) verwenden möchte.

An der Stelle bin ich mir jetzt nicht sicher, ob eine 2FA Möglichkeit in meine Windows-Forms-Anwendung generell überhaupt rein gehört bzw. ob mir MailKit hier weiterhelfen wird oder ob hierfür die (beispielsweise) Office365 App-Passwörter (Manage app passwords for two-step verification) angedacht sind.

Meine Frage lautet also: Bin ich hier als Entwickler gefordert eine 2FA Lösung in meiner Anwendung zu schaffen und wird mir Mailkit hier weiterhelfen?

Lg Toni

Was hat dein 2FA Problem mit Mailkit zu tun?
Mailkit kommuniziert mit einem SMTP Server, der kennt kein 2FA.
Der braucht nur einen Benutzer/Passwort für die Authentifizierung.

Wenn man sich mit 2FA bei Office 365 oder sonst wo anmeldet, dann tut man dies im (Web) Frontend.
Die Kommunikation via SMTP passiert dann auch nur über Benutzer/Kennwort mit dem SMTP Server.

Nachtrag:
Dies düfte alles nötige enthalten.

Link:
How to set up a multifunction device or application to send email using Microsoft 365 or Office 365

T-Virus

Die Hinweise gehen leider insgesamt in die falsche Richtung.

Aus Sicherheitsgründen - und das ist gut so - ändert Microsoft das Authentifizierungsprinzip von Microsoft 365. Jegliche Basic Authentication wird entfernt.
Deprecation of Basic authentication in Exchange Online
Basic Authentication ist leider einfach extremst unsicher, das Einfallstor für sehr viele Phishing Attacken; damit ist auch SMTP leider ein - zu heutigen Maßstäben - sehr unsicheres Protokoll.
Das wurde schon vor über 3 Jahren angekündigt und in vielen Tenants ist heute bereits kein Basic Auth und damit kein SMTP - egal mit welcher Lib - mehr möglich. Seitdem bekommt man Warnings in der Adminansicht von M365. Man hatte also wirklich genug Zeit zu handeln.

Willst Du im Namen eines Kontos E-Mails versenden, dann muss das in Zukunft über den Graph passieren, über einen OAuth Token.
Smtp fliegt vollständig raus.
Ein Beispiel dazu hier: How to send emails in .NET with the Microsoft Graph

Du musst also zwingend den Graph verwenden, wenn Du über Konten mit 2FA Mails verschicken willst, weil dort heute schon kein Basic Auth und damit kein Smtp mehr funktioniert.
Außer man verwendet hier die App Passwords, die auch bald abgeschafft werden.
Der Wechsel auf MailKit hilft Dir also wahrscheinlich nur ein paar Wochen / Monate. Besser gleich richtig machen.
Und ja: wenn Du bisher keine ordentliche Token-Authentifizierung in Deiner App hast, dann heisst das, dass Du diese (endlich!) vollständig ersetzen musst.

Das Limit der möglichen Mails gilt pro M365 Account und ist gleich wie bisher.
Wer das ganze aber at Scale machen will, und in die Limits von M365 kommt, muss dafür in Zukunft den Azure Communcation Service verwenden.
How to send emails at scale in .NET with the Azure Communication Service

PS: das sind beides Medium Beiträge, an denen ich mitgewirkt hab.
Wenn eine Info kommt, dass man das Maximum an Beiträgen pro Monat schon gelesen hat, einfach InPrivate aufrufen (oder Medium Cookies löschen).

Hallo!

Den Lösungsansatz mit Microsoft Graph werde ich mir auf jeden Fall mal genauer anschauen. Vielen lieben Dank!

Jetzt hätte ich aber noch eine Frage was den Einsatz von so einem kostenlosen SMTP-Dienstleiter wie beispielsweise sendgrid.com angeht.
Die bieten/bewerben doch derzeit nach wie vor SMTP-Lösungen an. Sind diese auch sicher bzw. wäre das ein brauchbarerer Lösungsansatz für meine Anwender?

Lg Toni

Sind diese auch sicher bzw. wäre das ein brauchbarerer Lösungsansatz für meine Anwender?

Das musst Du selbst entscheiden; wir tragen keine Verantwortung für Deine Anwender.
Meine Meinung: alles, was mit SMTP zutun hat, ist nicht brauchbar und nicht mehr zumutbar. Und SMTP und "sicher" in einem Satz passt auch nicht mehr in die Zeit.

Jetzt hätte ich aber noch eine Frage was den Einsatz von so einem kostenlosen SMTP-Dienstleiter wie beispielsweise sendgrid.com angeht.

Es gibt de facto keine "nutzbaren" Dienstleister, die wirklich kostenlos sind. Warum sollten sie das auch anbieten?
Das sind alles Freemium Modelle für's Testen, entsprechend hast Du entweder a) super wenig Mails pro Tag/Monat oder b) einfach null Dinge, die man für einen sicheren E-Mail-Versand benötigt. Mit kostenlosen Angeboten würden sie sich Spammer ins Haus holen und ihr eigenes Produkt kaputt machen.

Du wirst akzeptieren müssen, dass Du Dich von SMTP verabschieden werden musst.
Es ist einfach eine obsolete, unsichere Technik, die verschwinden wird.

Hallo!

Du meintest, dass ich mich von SMTP verabschieden müsste aber mich irritiert es jetzt, dass der folgende Microsoft Artikel (vom 16.03.2023) die Verwendung von SMTP-Releaydienst wie SendGrid regelrecht empfiehlt:

Problembehandlung bei ausgehenden SMTP-Verbindungen in Azure

Empfohlene Methode zum Senden von E-Mails
Es wird empfohlen, authentifizierte SMTP-Relaydienste zu verwenden, um E-Mails von Azure-VMs oder von Azure App Service zu senden. (Diese Relaydienste stellen in der Regel eine Verbindung über den TCP-Port 587 her, unterstützen aber auch andere Ports.) Mithilfe dieser Dienste wird die Zuverlässigkeit der IP-Adresse und der Domäne bewahrt, um die Wahrscheinlichkeit zu minimieren, dass Ihre Nachrichten von externen Domänen abgelehnt oder im Spam-Ordner platziert werden. SendGrid ist ein solcher SMTP-Relaydienst, aber es gibt auch andere. Möglicherweise befindet sich auf Ihren lokalen Servern auch ein authentifizierter SMTP-Relaydienst.
Das Verwenden dieser Dienste für die E-Mail-Zustellung ist in Azure nicht eingeschränkt – unabhängig vom Abonnementtyp.

Wie passt das zusammen bzw. übersehe ich hier jetzt etwas?
Lg Toni

Da missverstehst Du den Eintrag. Der Titel bezieht sich auf den Artikel, und in diesem Artikel geht es spezifisch um das Trouble Shooting von legacy SMTP Outbound-Verbindungen; Der Eintrag ist nicht gemeint mit "Microsoft empfiehlt nur authentifizierte SMTP Verbindungen für das Versenden von Mails".
Sondern im Endeffekt steht in verständlicher Art "Microsoft empfiehlt - wenn SMTP Verbindungen verwendet werden - authentifizierte Verbindungen". Weil SMTP das tatsächlich auch ohne Authentifizierung unterstützt, was viele Spammer suchen und dann verwenden.

Dazu bezieht sich der Artikel explizit auf Azure VMs und App Service.
SMTP wurde hier verwendet um lokal Mails zu verschicken. SMTP war hier nichts anderes als ein SMTP Client auf der Maschine, der direkt mit dem Empfänger gesprochen hat. Dadurch kann man unvalidiert Mails verschicken. Viele SMTP Empfänger blocken das aber mittlerweile.
Daher gibt es SMTP Relay Server, die quasi eine vertrauenswürdige Stellung in der Legacy SMTP Welt einnehmen, damit alte Anwendungen überhaupt noch Mails zustellen können.

Aber das Problem löst sich irgendwann von alleine, weil fast alle Anbieter SMTP abgekündigt haben.
Auch das SendGrid Angebot richtet sich vor allem an Legacy Anwendungen, die mal nicht eben so umgebaut werden können. SendGrid sagt aber auch ganz klar: nutze wenn möglich die modernen Schnittstellen, nicht SMTP.

Ich hab mal nen Issue erstellt, dass die Formulierungen vielleicht deutlicher werden.
https://github.com/MicrosoftDocs/azure-docs/issues/106731