Nachdem mich neulich ein Kollege auf eine mir bis dahin unbekannte Möglichkeit aufmerksam gemacht hat, EMail-Funktionalitäten ohne EMail-Server und -Konto zu testen holte ich ein altes Projekt aus der Versenkung hervor...

Die eingesetzte Komponente ist Greenmail - und sie hat nichts mit klimaneutralem Versand von realen Versandstücken zu tun.

Damit ließen sich zunächst erst einmal alle möglichen Konfigurationen und Anwendungsfälle meiner selbstgeschriebenen - und ja: ich weiß, dass es da draußen Milliarden von Implementierungen gibt, die dasselbe tun - Komponente zum Versand von EMails testen; einschließlich des Versands von Attachments und des Setzens selbstdefinierter Header.

Als ich damit fertig war überlegte ich mir, auch die S/MIME-Funktionalität ähnlichen Tests zu unterziehen. Auch das gelang mir - allerdings habe ich immer ein ungutes Gefühl, wenn derjenige, der die Implementierung schreibt auch für die Tests verantwortlich ist. Ich löse das privat wann immer es geht so, dass ich - besonders bei der Implementierung von Schnittstellen und Protokollen - die Tests durch eine Implementierung erledigen lasse, an der ich nicht beteiligt war.

Im Falle von Crypto ist mein erster Anlaufpunkt dafür oft OpenSSL - so auch dieses Mal: Ich erweiterte die Unit-Tests um einen Schalter der - wenn aktiviert - dafür sorgt, dass die erzeugten S/MIME-Botschaften für jeden Test als Dateien mit Endung .eml in ein eigenes Verzeichnis rausgeschrieben werden - zusammen mit dem Crypto-Material (Schlüssel, Zertifikate,...), das zum Verifizieren der elektronischen Signaturen und zum Entschlüssel gebraucht wird. Dazu kommen noch Schlüssel von Empfängern, für die die jeweilige Nachricht nicht verschlüsselt wurde (man soll auch den Negativtest durchführen können) und ein Bash-Script, das die jeweiligen Operationen des Entschlüsselns und Verifizierens mittels OpenSSL ausführt.

Jemand, der diese Implementierung verifizieren möchte, kann dann die einzelnen Skripte ausführen. Unten habe ich ein Beispiel für ein so erzeugtes Archiv angehängt - bevor jetzt jemand anfängt über meinen Geisteszustand zu räsonieren: Die Zertifikate sind selbsverständlich selbst-signiert und haben eine Gültigkeitsdauer von exakt einer Woche, die privaten Schlüssel sind als PEM-Dateien gespeichert und nicht durch ein Passwort geichert, da beides - Zertifikate und Schlüssel - bei jeder Testausführung erzeugt und danach weggeworfen werden. Durch die Veröffentlichung und Weitergabe wird also niemand gefährdet oder kompromittiert.

Da die API noch nicht ganz in einem Zustand ist, wie ich ihn mir vorstellen würde habe ich diese Komponente noch nicht als OpenSource freigegeben - wer trotzdem Interesse hat und damit leben kann, dass BouncyCastle als Abhängigkeit mitkommt, wende sich an mich: Das würde mir den Anstoß geben, die letzten Reste der Politur abzuwischen und ein OpenSource-Projekt daraus zu machen.

Hier noch ein Snapshot wie die API derzeit für einen schnellen test angewendet werden kann:

java.lang.String fromaddress="<sender_email>";
java.lang.String smtpPasswd="<change_me>";

java.security.Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider()); KeyStore ks = KeyStore.getInstance(java.security.KeyStore.getDefaultType()); ks.load(null);//insert the keystore holding certificates of your receivers

java.security.KeyStore signerKeystore = java.security.KeyStore.getInstance(java.security.KeyStore.getDefaultType()); signerKeystore.load(null, null);//insert the keystore here that holds your digital identity!

de.elbosso.util.net.mail.MailConfigurationBean mcb=new de.elbosso.util.net.mail.MailConfigurationBean(); mcb.setContent("content"); mcb.setSubject("subject"); mcb.setToaddress(java.util.Arrays.asList(new java.lang.String[]{fromaddress})); mcb.setSmtp_password(smtpPasswd); mcb.setSmtp_username(fromaddress); mcb.setAdminaddress(fromaddress); mcb.setFromaddress(fromaddress); mcb.setMailserver(null/*SMTP server address goes here*/); mcb.setReplyto(fromaddress); mcb.setSecurityMode(Security.STARTTLS/*or maybe something different - adjust to your needs*/); mcb.setEncryptionKeystore(ks); mcb.setSignerKeystore(signerKeystore); mcb.setSignerPassword("123456".toCharArray()/*you have secured your private key with a much stronger password of course...*/); SmtpMailHelper.send(mcb); SmtpMailHelper.sendEncrypted(mcb);

Lizenz
IntegrationTestSmtpMailHelper.zip

Alle Artikel rss Wochenübersicht Monatsübersicht Codeberg Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • xBrowserSync in Docker

    29.03.2021

    Nachdem ich schon längere Zeit nicht mehr über neue Dienste in meinem Docker-Zoo berichtet habe, habe ich in der vergangenen Woche wieder einmal einen Neuzugang begrüßen dürfen...

    Weiterlesen

Neueste Artikel

  • Asymmetrische Kryptographie

    Ich habe mich mit der Idee schon länger getragen: Nochmal einen Rundumschlag zu asymmetrischer Kryptographie zu machen. Dabei werde ich mich auf Demonstrationen der einzelnen Konzepte und Operationen mit Beispielcode konzentrieren und zu jedem der vorgestellten Konzepte mehr oder weniger ausführlich bezüglich der Einsatzszenarien und Vor- und Nachteile Stellung beziehen

    Weiterlesen
  • Windows? Nur noch gegen Bezahlung!

    Ich habe mich nun völlig von Windows - der armseligen Ausrede für ein Computerbetriebssystem aus Redmond - abgenabelt

    Weiterlesen
  • Vergleich Analoger und Digitaler Identitäten

    Eine Präsentation zum besseren Verständnis der Konzepte hinter digitalen Identitäten

    Aktualisierung vom 16. März 2025

    Aktualisierung der Präsentation mit einem Beispiel aus einem Film der 1980er Jahre und Betonung des Fakts, dass das Subjekt überhaupt nicht bemerken muss, dass eine Identität erstellt wird...

    Aktualisierung vom 17. August 2025

    Ein weiteres Beispiel wurde hinzugefügt.

    Aktualisierung vom 30. März 2026

    Aktualisierung der Präsentation: Erläuterung der Möglichkeit, mehr als ein Zertifikat für dasselbe Schlüsselpaar auszustellen und Exkurs zu Transport Layer Security als Beispiel der Forderung des Vorweisens bestimmter Arten digitaler Identitäten.
    Weiterlesen

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muss damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen Codeberg-Repositories findet man hier.