n'Abend,
Ich glaube doch, schon. Ein kompaktes Modul mit klar umrissener Funktionalität. Kein GUI, keine Applikationsschicht, nur der reine SMTP-Client als wiederverwendbares Modul.
Im Leben nicht. Der RFC hat schon knapp 100 Seiten, den müsste man erstmal lesen und technische Spezifikationen lesen sich nicht so schnell wie Romane.
aber RFC822 und 2822 habe ich in den letzten 20 Jahren schon einige Male vor- und rückwärts gelesen und kenne den Inhalt im Wesentlichen. Mit den Ergänzungen müsste ich mich etwas intensiver befassen.
Und allein die Spezifikation wird nicht reichen, um alle Details zu verstehen, wenn man Glück hat gibt es eine Referenz-Implementierung in einer Programmiersprache, die man versteht. Dann muss man recherchieren, ob es Defacto-Standards gibt, die für den Produktiv-Betrieb unerlässlich sind, die aber nicht Teil der offiziellen Spezifikation sind.
Da würde ich mich vorbehaltlich einer gewissen Fehlertoleranz stur an die Spezifikation halten; wenn "ein real existierender Server" davon abweicht, hat er Pech.
Dann muss man sich eine Architektur überlegen.
Was gibt's da zu überlegen? Socket zum SMTP-Host öffnen, SMTP-Dialog führen, Antwort(en) abwarten, Fehler abfangen, zum Schluss Verbindung schließen und Status (Erfolg oder Fehlercode) zurückmelden.
Dann richtet man sich eine lokale Entwicklungsumgebung ein.
Die setze ich bereits voraus.
Dann kann man anfangen Tests zu schreiben, für jedes MUST in der Spezifikation sollte es mindestens einen Test geben.
Ja, ich weiß: Die Profis machen das mit dem Testen sehr systematisch und ausführlich. Ich würde das Testen hier stark vereinfachen, da es sich im Wesentlichen um einen streng sequentiellen Ablauf mit kontrollierten Abbruchbedingungen handelt.
Dann kan man die Library debuggen.
Das hat man - deiner Beschreibung nach - doch bis hierher schon lang und breit getan.
Wenn dann wirklich mal eine erste Version existiert, dann muss man sich übers Deployment Gedanken machen. Wenn das kein Wegwerf-Skript werden soll, dann muss man sich über CI-Pipelines Gedanken machen.
Hä?
Wenn man Glück hat, gibt es eine DevOps-Abteilung, die das übernimmt.
Hä?
Wenn ich den Auftrag aufbekäme, einen SMTP-Client zu programmieren, würde ich mir schon mindestens einen Tag Zeit nehmen, um den Entwicklungs-Prozess zu planen, Aufwände abzuschätzen, Features zu priorisieren.
Wie gesagt: Ich mach das nicht professionell. Ich mach das, wenn überhaupt, für den Eigenbedarf, aus Spaß oder wegen der technischen Herausforderung. Wenn's gut läuft, könnte ich mir vorstellen, das fertige Modul dann zu veröffentlichen. Muss aber nicht sein.
Aber vermutlich würde ich dem Kunden gleich davon abraten und zu einer bereits erprobten Implementierung raten, die den Test der Zeit bereits bewältigt hat und starken Community-Support erfährt.
Wir denken eindeutig in unterschiedlichen Dimensionen.
So long,
Martin
--
Ich stamme aus Ironien, einem Land am sarkastischen Ozean.