usr/lib/sendmail' klappt nicht immer

[Jürgen]

Hallo,

Bei folgenden Programm kommen die Emails nicht bei allen
Systemen wie Z.B einen OUTLOOK nicht an.

---------------------------------------------
#!/usr/bin/perl -w

E-mail address to send intake form to (your address)

If not using PERL 5, escape the @ thus: @ instead of @

$YourEmail = '[e-mail]';

Location of mail program - check your doc or ask admin

$MailProgram = '/usr/lib/sendmail';

$subjectauto = "Registration";

open(MAIL,"|$mailp -t");
print MAIL "To: $YourEmail\n";
print MAIL "From: $YourEmail\n";
print MAIL "Subject: $subjectauto\n\n";
print MAIL "Hallo";
               close (MAIL);

print "Content-Type: text/html\n\n";
print $YourEmail;

[hotti]

Hallo,

Bei folgenden Programm kommen die Emails nicht bei allen
Systemen wie Z.B einen OUTLOOK nicht an.

Eine eMail wird ja auch nicht an outlook gesendet sondern an ein Mailsystem. Zur Fehlereingrenzung mach Dir klar, wie Mail funktioniert.

Du machst ein pipe auf das lokale Mailprogramm (MTA), Status?
Das lokale Mailprogramm, der MailTransfer Agent versucht die Zustellung an den der eMail-Adresse entsprechenden im MX-Record eingetragenen Mailserver und braucht dazu eine Verbindung "nach draußen" über port 25, desweiteren muss der MTA dazu den DNS (UDP, port 53) abfragen, Status? Was sagt die Mail-Queue des lokalen MailTransferAgents? Kommt da was an, gibt es eine Bounce?

Hotti

[Struppi]

#!/usr/bin/perl -w

Das du die Warnungen angeschaltet hast, ist zwar gut, aber du musst sie auch anzeigen lassen. Das Skript läuft als Serverskript, dann könntest du CGI::Carp verwenden.

Mit:

use CGI::Carp qw(fatalsToBrowser warningsToBrowser);

Siehst du im Browser ob alles in Ordnung ist.

Du solltest auch noch use strict benutzen.

E-mail address to send intake form to (your address)

If not using PERL 5, escape the @ thus: @ instead of @

$YourEmail = '[e-mail]';

my $YourEmail = '[e-mail]';
(wegen use strict)

Location of mail program - check your doc or ask admin

$MailProgram = '/usr/lib/sendmail';

sendmail ist auch tatsächlich dort?
Wenn nicht kannst du es auch prüfen:

die "Kann sendmail nicht finden: $MailProgram" unless -e $MailProgram:

$subjectauto = "Registration";

my $subjectauto = "Registration";

open(MAIL,"|$mailp -t");

auch hier solltest du testen, ob das überhaupt geht:

open(MAIL,"|$mailp -t") or die "Fehler beim öffnen, weil: $!";

(Wobei aber hier das Problem ist, woher kommt $mailp?)

print MAIL "To: $YourEmail\n";
print MAIL "From: $YourEmail\n";
print MAIL "Subject: $subjectauto\n\n";
print MAIL "Hallo";
               close (MAIL);

abgesehen davon, dass diese ganzen Variabeln nicht definiert wurden, musst du hier aufpassen, dass dein Skript nicht mißbraucht wird, in dem zusätzliche Headerzeilen eingeschleust werden.

Versuch's doch mal mit einem Modul, z.b. MIME::Lite

Struppi.

[Jürgen]

Hallo Struppi

sendmail sollte Installiert sein weil die emails
print MAIL "To: an die aol email funktionieren\n";
und  To: Email die ich im Outllok eiogestellt habe nicht.

Ich empfange alle Anfragen über die Email im Outlook,
außer die Vom CGI, und über die AOL email kann ich die Anfragen von dem CGI empfangen.

Mit MIME kommt es auch nicht an die Outlook Mail an und an die aol email schon.

(Wobei aber hier das Problem ist, woher kommt $mailp?)

da hatte ich im beispiel $mailprogramm vergessen (Sorry)

abgesehen davon, dass diese ganzen Variabeln nicht definiert wurden, musst du hier aufpassen, dass dein Skript nicht mißbraucht wird, in dem zusätzliche Headerzeilen eingeschleust werden.

Was bedeudet Header eingeschleust? kann es sein dass Hecker angreifen können wenn my ausgelassen wird oder Mails abgefangen werden, oder der Komplette server dadurch manipuliert werden kann?

Vielen Dank für die Hilfe
Jürgen

[Alexander (HH)]

Moin Moin!

sendmail sollte Installiert sein weil die emails
print MAIL "To: an die aol email funktionieren\n";
und  To: Email die ich im Outllok eiogestellt habe nicht.

Offensichtlich funktioniert das Versenden, sonst würde keiner E-Mails bekommen. Spamfilter kontrolliert? Diverse Mailserver verweigern auch die Annahme von Mails, dann bekommt der unter From: genannte Absender eine Antwort-Mail. Es ist also in Deinem eigenen Interesse, dort eine brauchbare, vom Empfänger verschiedene E-Mail-Adresse anzugeben.

Was bedeudet Header eingeschleust? kann es sein dass Hecker angreifen können wenn my ausgelassen wird oder Mails abgefangen werden, oder der Komplette server dadurch manipuliert werden kann

Wenn Du das ernsthaft fragen mußt und diese wirren Schlußfolgerungen ziehst, dann benutze bitte nicht sendmail, sondern MIME::Lite, bevorzugt im SMTP-Modus. Oder noch besser: Lasse jemanden den Job machen, der sich damit auskennt.

Es ist gute Praxis, Perl-Scripte im Strikt-Modus (use strict;) und mit eingeschalteten Warnungen (use warnings;) laufen zu lassen, daran solltest Du Dich auch halten. Ohne diese beiden Pragmas ist Perl gefährlich entspannt beim Abarbeiten Deines Programms und macht oft Unerwartetes.

Wenn Du mit Eingaben von potenziell bösartigen Mitmenschen oder Programmen umgehen mußt, sprich: sobald Du Daten aus dem Netzwerk verarbeitest und/oder mit erhöhten Rechten arbeitest, solltest Du den Taint Mode einschalten (#/usr/bin/perl -T), alle Eingaben vor der Verarbeitung streng validieren, und im Zweifel die Verarbeitung abbrechen (NICHT versuchen, durch automatisiertes Raten zu korrigieren!). Der Taint Mode verhindert nicht alles, aber er verhindert größere Schäden, einfach in dem Perl sich weigert, ungeprüfte Eingaben an potenziell schädliche Funktionen zu übergeben.

Alexander

[CPAN]

'lo Alexander,

ich möchte, dass du Email::Sender/Email::MIME statt MIME::Lite empfiehlst. M::L ist seit 7 bis 9 Jahren im Maintainermodus, hat drei Dutzend Tickets angehäuft, ist nicht kompatibel mit Email::Abstract, hat eine grausige API, wirft keine Exceptions im Fehlerfall und ist überhaupt insgesamt nicht so toll, wie man es in einer modernen Perlumgebung als Programmierer haben wollen mag.

[Alexander (HH)]

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

[CPAN]

Hallo Alexander, ich finde es ganz bestürzend, was du da schreibst. Ein unvoreingenommener Leser würde beim Lesen deiner zwei Beiträge den Eindruck erhalten, dass Email::* ganz schlecht und M::L zu bevorzugen ist, obwohl das Gegenteil der Fall ist; zumal deine Kritik aus einer nur sehr oberflächlichen Betrachtung entspringt, weil du nach eigener Aussage noch gar nicht mit Email::* programmiert hast!

Der Textmenge nach zu beurteilen, findest du, das größte Problem ist die Qualität der Dokumentation. Tatsächlich ist M::L der Vorteil nach reiner Menge zu gewähren. Du unterschlägst aber, dass es zu Email::* Synopsen und Beispielcode gibt, mit denen die Libs genutzt werden können, und das nicht nur /mit Ach und Krach/, /geradeso für den Regelfall/, wie man mutmaßen könnte, sondern vollständig. Ich würde der Doku keine 6, sondern eine 3 geben. Dies ist leicht nachzuvollziehen, wenn man sich erst mal länger als fünf Minuten mit ihr beschäftigt, um etwas zu programmieren und nicht nur zum Sichten durchklickt. Aber genug zu dem Thema, auf lange Sicht gesehen ist die Doku kein wesentlicher Faktor verglichen mit anderen Kriterien – Doku konvergiert zur guten Qualität; das ist ohnehin ein Merkmal, wo Email::Sender sehr mühelos aufschließen kann.

Email::MIME kann auch E-Mails zusammenbauen. Nur ist dann Schluß.

Das ist beabsichtigt so! M::L begeht einen schlimmen Designfehler, Mail-Erstellung und -Versand in eine Klasse zu packen. Besser gelöst ist das mit der Hierarchie Email::*, die unter dem Schirm vom PEP (ehemaliges Wiki durch archive.org erreichbar) miteinder kompatible Klassen bietet, die genau jeweils eine Sache korrekt lösen.

Letztes Release: 3.027 vom 10. Oktober 2009. Ich sehe da keine neun Jahre
[...] Aber: MIME::Lite wird weiter entwickelt

Ein Releasedatum macht meine Aussage nicht ungültig. Siehe stattdessen das Changelog! M::L läuft auf Sparflamme, der Maintainer rjbs richtet verständlicherweise seine Energie lieber auf die modernen Email::*-Module. Es gibt schlicht keine Weiterentwicklung oder Zukunft für M::L: er will auch persönlich, dass M::L für neue Projekte nicht mehr benutzt wird.

Drei Dutzend sind 36 [nicht 33]

Diese Antwort empfinde ich als Korinthenkackerei. Ich drücke meine Absicht wohl besser deutlich aus:

um mal Bugs zu zählen

Man kann ganz klar schlussfolgern, dass obwohl die Email::*-Module auch schon eine lange Lebensdauer auf dem Buckel haben, sie wegen der aktiven Pflege wesentlich besser im Vergleich zu M::L wegkommen. Die Benutzung von M::L ist ein Risiko, solange es niemanden gibt, der es wieder aufmöbeln will.

nicht kompatibel mit Email::Abstract,
Na und? Ziel von MIME::Lite ist es nicht, EMails zu parsen, sondern sie zusammen zu bauen [...]

Sorry, da hast du das Ziel von E::A falsch aufgefasst. Häufig hat man ja schon ein Emailobjekt im Speicher! Es ist nur möglich, es von M::L verarbeiten zu lassen, wenn man es ressourcenraubend serialisiert. Dies wäre einfach vermeidbar, wenn M::L kompatibel wäre.

wirft keine Exceptions im Fehlerfall
Kann ich mir nicht so recht vorstellen

Ist aber so. Ich kann nicht genug betonen, wie schlimm eigentlich dieser Nachteil ist! Wenn man M::L einsetzt, geht Mail schlichtweg verloren. Harsch, aber wahr. Mailsysteme sind wohl eine der unzuverlässigsten Infrastrukturen im Internet, und das Modul trägt dem überhaupt keine Rechnung. Im Bestfalle kriegt man Bouncemails (hat der Programmierer, der M::L einsetzt, sich darauf korrekt und RFC-konform vorbereitet? eher nicht.) oder Meldungen im Log vom MTA (nur vom Postmaster/Root einsehbar), im ungünstigsten Falle ist die verschickte Mail einfach weg. Auf jeden Fall ist es immer zu spät. Email::Sender hat die einzig korrekte Implementation (mittels Schema von Erfolg, Teilerfolg, Fehler) vorzuweisen, so dass der Programmierer gezwungen ist, sich mit Fehlerfällen vom MTA unmittelbar auseinanderzusetzen; man kann die Exception abfangen und zeitnah behandeln. Selbst ein Programmcrash durch Exception ist besser als zu tun, als ob alles in Ordnung wäre – bedenke den typischen Einsatz vom OP in diesem Thread.

Dieses Merkmal allein sollte als Gnadenschuss gegen M::L ausreichen.

sicherer als wenn man irgendwelche Daten selbstgestrickt in sendmail pumpt

Der Vergleich war zwischen M::L und Email::Sender, nicht M::L und sendmail. Prinzipiell ist alles besser als sendmail-Pumpe.

Konnte ich es schaffen, dich zum Umdenken zu bewegen? Ich habe nur gute Absichten zur Förderung des besten Moduls für den jeweiligen Zweck im Sinn.