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

  • Multi-User-WebDAV, Docker, GitHub

    17.11.2019

    Nachdem ich mich in letzter Zeit verstärkt mit Docker und dem zugehörigen Ökosystem beschäftige, habe ich begonnen, verschiedenste Dienste in Containern zu testen um zu sehen, ob in manchen Fällen LXC oder KVM nicht doch die bessere Wahl wäre...

    Weiterlesen...

Neueste Artikel

  • Migration der Webseite und aller OpenSource Projekte

    In eigener Sache...

    Weiterlesen...
  • AutoHideToolbar für Java Swing

    Ich habe eine neue Java Swing Komponente erstellt: Es handelt sich um einen Wrapper für von JToolBar abgeleitete Klassen, die die Werkzeugleiste minimieren und sie nur dann einblenden, wenn der Mauszeiger über ihnen schwebt.

    Weiterlesen...
  • Integration von EBMap4D in die sQLshell

    Ich habe bereits in einem früheren Artikel über meine ersten Erfolge berichtet, der sQLshell auf Basis des bestehenden Codes aus dem Projekt EBMap4D eine bessere Integration für Geo-Daten zu spendieren und entsprechende Abfragen, bzw. deren Ergebnisse auf einer Kartenansicht zu visualisieren.

    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.