Richtig wäre es, die möglichen Methoden aus dem banner zu lesen.
In diesem Fall wird AUTH LOGIN nicht aufgeführt, wird aber vom mailserver, wie eben demonstriert, behandelt.Doch, wird aufgeführt. Zumindest laut deinem Testlog.
Scheint so zu sein, wenn man die Zeile zu interpretieren versteht.
AUTH LOGIN PLAIN
ID METHODE METHODE
Hier noch eine interessante Lektüre
http://www.huschi.net/11_108_de-esmtp-dialog-smtp-auth.html
Problem ist, dass smtp->auth() selbst keinen Fehler produziert.
Aus den Tiefen von SMTP.pm
sub auth {
my ($self, $username, $password) = @_;
eval {
require MIME::Base64;
require Authen::SASL;
} or $self->set_status(500,["Need MIME::Base64 and Authen::SASL todo auth"]), return 0;
Das ist natürlich jetzt klar.
Das Modul ist nicht in meiner ActiveState enthalten.
damit fällt smtp->auth() als eine Methode für ein öffentliches Formmailer-Script dahin.
Mein Workaround erweist sich somit als sicher, sofern man ohne SASL leben kann.
Im praktischen Fall wird ja ein CGI-Formmailerscrpt nicht über das Internet auf einen fernen Server zugreifen.
mfg Beat
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische