Alexander (HH): usr/lib/sendmail' klappt nicht immer

Beitrag lesen

Moin Moin!

ich möchte, dass du Email::Sender/Email::MIME statt MIME::Lite empfiehlst.

Kann ich nicht. Bislang hab ich beide nicht benutzt, und normalerweise bin ich recht offen, was neue, bessere Module angeht. Also hab ich sie mir bei CPAN angesehen.

Email::Sender ist v0.1x, zieht jede Menge Non-Core Module nach sich, die API ist mindestens so gruselig wie MIME::Lite (E-Mail wird wie ein Objekt erzeugt, der Versand läuft dann aber über importierte Prozeduren ...) und Dokumentation ist bis auf ein paar Stubs nicht vorhanden. Wenn es explizit ein Manual gibt, dann erwarte ich, dass dort mehr steht als ein Link auf das magere Quickstart-Dokument, dass unter "Where can I learn more?" stumpf auf das leere Manual verweist ("Have a look at Email::Sender::Manual"). Außerdem wird auf Email::Sender::Simple verwiesen, das wiederum nur auf das Quickstart-Dokuemnt verweist. An diesem Punkt komme ich mir langsam veralbert vor. Der letzte Link auf [http://search.cpan.org/perldoc?Email::Sender::Transport@title=Email::Sender::Transport] endet in einem Mini-Dokument, das sich in Implementationsdetails verliert. Ich will nicht erst die gesamte Implementationsdokumentation lesen müssen (und das habe ich in diesem Fall auch nicht), um zu raten, was dieses Paket wohl für ein (öffentliches) Interface hat. "Setzen, sechs!" Mit einem kleinen "plus" für die Mühe, die Dokumentenstümpfe anzufertigen.

Email::MIME ist schon besser dokumentiert, auch wenn "Easy MIME message parsing" zunächst etwas verwirrend ist. Ich will E-Mails versenden, nicht zerlegen. Aber Email::MIME kann auch E-Mails zusammenbauen. Nur ist dann Schluß. Ich habe eine hübsch zusammengebaute Mail im Speicher liegen, die ich mir in einen String serialisieren kann, über die ich wie wild Informationen ziehen kann, aber ich werde sie nicht los!

M::L ist seit 7 bis 9 Jahren im Maintainermodus,

Letztes Release: 3.027 vom 10. Oktober 2009. Ich sehe da keine neun Jahre, noch nicht einmal neun Monate.

hat drei Dutzend Tickets angehäuft,

26 "new" + 7 "open" = 33. Drei Dutzend sind 36. Von den 33 sind einige mittlerweile schlicht veraltet, andere sind Feature Requests, wieder andere sind Korrekturen der Dokumentation.

Und um mal Bugs zu zählen: Email::Sender hat zwei offene Bugs, einer davon ist schon ein Jahr offen. Und Email::MIME hat vier, der älteste ist sechs Jahre alt.

ist nicht kompatibel mit Email::Abstract,

Na und?

Ziel von MIME::Lite ist es nicht, EMails zu parsen, sondern sie zusammen zu bauen und zu verschicken. Und genau das schafft MIME::Lite.

hat eine grausige API,

Nicht schlimmer als Email::Sender.

wirft keine Exceptions im Fehlerfall

Kann ich mir nicht so recht vorstellen, hab ich jetzt aber nicht im Detail überprüft.

und ist überhaupt insgesamt nicht so toll, wie man es in einer modernen Perlumgebung als Programmierer haben wollen mag.

"überhaupt insgesamt nicht so toll" - was für ein spezifisches Kriterum.

Die Implementation ist alt und an manchen Stellen ziemlich gruselig. Zum Beispiel die Defaults (sendmail statt SMTP), zum Beispiel erben von MIME::Lite (scheitert gelegentlich daran, das MIME::Lite intern Funktionen statt Methoden benutzt), zum Beispiel Übergabe mehrerer Adressaten (als String statt als Array).

Aber: MIME::Lite wird weiter entwickelt, und mit MIME::Lite kann man einfach eine Mail zusammenbauen und auf die Reise bringen, und das sicherer als wenn man irgendwelche Daten selbstgestrickt in sendmail pumpt.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".