From-Angabe in mail (SELFHTL-Formmail)

[Silly]

Hallo,
meine Frage scheint im Gewirr der Diskussion untergegangen zu sein.
Daher hier noch einmal (man möge mir verzeihen).

Wenn der Absender des Formulars eine mail-Adresse angibt, stelle ich diese in die FROM-Angabe (korrekt?).
Was ist üblich als FROM-Angabe, wenn keine e-mail-Adresse angegeben wurde?
Gruß
Silly

[Sven Rautenberg]

Moin!

Wenn der Absender des Formulars eine mail-Adresse angibt, stelle ich diese in die FROM-Angabe (korrekt?).

Nein, nicht unbedingt. Du kannst ja nicht wissen, ob diese Mailadresse korrekt ist, und ob sie tatsächlich auch dem Besitzer des Postfaches gehört.

Meine Vorgehensweise ist, als FROM-Adresse eine meiner eigenen Adressen anzugeben, und für die Erleichterung der Mailantwort die angegebene Absenderadresse als "Reply-to"-Angabe in die Mail zu schreiben.

Beachte bitte: Die Absenderadresse, egal ob als "From" oder als "Reply-To", kann zusätzliche EMail-Header enthalten. Der SELFHTML-Formmailer schreibt in seiner aktuellen Form lediglich den Betreff in den Mailheader, und filtert auch nur diese Angabe. Die Absenderadresse ist also vor der Übertragung in den Mailheader auch unbedingt zu filtern!!!

Was ist üblich als FROM-Angabe, wenn keine e-mail-Adresse angegeben wurde?

Irgendeine Adresse muß man angeben. Im Zweifel eben eine, über die man selbst die Kontrolle hat.

- Sven Rautenberg

[Silly]

Danke,
aber noch eine Frage

Meine Vorgehensweise ist, als FROM-Adresse eine meiner eigenen Adressen anzugeben, und für die Erleichterung der Mailantwort die angegebene Absenderadresse als "Reply-to"-Angabe in die Mail zu schreiben.

Reply-to habe ich noch nirgendwo gesehen (auch nicht jetzt im Forum).
Ist das ein reservierts Wort im mail-System (wie FROM/TO/CC/BCC) ?
Oder wie gibst Du das an?

Gruß
Silly

[Cheatah]

Hi,

Reply-to habe ich noch nirgendwo gesehen (auch nicht jetzt im Forum).
Ist das ein reservierts Wort im mail-System (wie FROM/TO/CC/BCC) ?

ich weiß nicht, was Du mit "mail-System" meinst; aber es ist ein definierter Mail-Header.

Cheatah

[Silly]

aber es ist ein definierter Mail-Header.

Danke, wieder etwas gelernt !
Silly

[Silly]

Hallo,
/\s/ berücksichtigt alle Whitespaces.
Gibt es eine elegante Möglichkeit nach Whitespaces zu suchen/diese zu ersetzen ohne Berücksichtigung des eigentlichen Leerzeichens
(also eine Abfrage in der Art / \s aber ausschließlich \x20 /)
oder muss ich dann alle möglichen Whitespaces angeben?
Ich will nämlich nicht nur \r\n weg haben sondern alle übrigen.
Gruß
Silly

Übrigens habe ich verzweifelt gesucht nach einer Definition von Whitespaces. Da werden ja die unterschiedlichsten Versionen angeboten.
Ich nehme an, es sind alle Zeichen mit ASCII-Wert < 33.

[Dennis]

Hi Silly,

Gibt es eine elegante Möglichkeit nach Whitespaces zu suchen/diese zu ersetzen ohne Berücksichtigung des eigentlichen Leerzeichens
(also eine Abfrage in der Art / \s aber ausschließlich \x20 /)
oder muss ich dann alle möglichen Whitespaces angeben?
Ich will nämlich nicht nur \r\n weg haben sondern alle übrigen.

Du willst also alle Whitespaces löschen, das Leerzeichen aber behalten? Warum das? Es ist am einfachsten, wenn du einfach alle Whitespaces durch ein Leerzeichen ersetzt - damit werden Leerzeichen durch Leerzeichen ersetzt (bleiben also) und alle anderen Whitespaces werden zu Leerzeichen.

Du könntest aber mal folgenden regulären Ausdruck probieren:

[^ \S]

In eckigen Klammern gibt man eine Zeichenklasse an, das ^ bedeutet "alle Zeichen außer" und \S bedeutet "kein Whitespace", hier also alle Zeichen außer dem Leerzeichen und den Zeichen, die kein Whitespace sind.

Übrigens habe ich verzweifelt gesucht nach einer Definition von Whitespaces.

Ich würde Whitespaces jetzt einfach mal als nicht-sichtbare Schriftzeichen definieren ;-)

MfG, Dennis.

[Ashura]

Hallo Silly.

Übrigens habe ich verzweifelt gesucht nach einer Definition von Whitespaces.

Warum verzweifeln? Einfach die Wikipedia befragen.

Einen schönen Dienstag noch.

Gruß, Ashura

[Silly]

Hallo Ashura

Warum verzweifeln? Einfach die Wikipedia befragen.

Dort steht u.a.

"Je nach Kontext werden verschiedene Zeichen als Leerraum angesehen, fast immer zumindest Leerzeichen und Tabulatorzeichen, meist auch Zeilenumbrüche."

Was ist das für eine Definition ?

Wenn ich demnach irgendwo lese "Diese Routine ersetzt die Whitespaces...", so kann ich mir aussuchen, welche Whitespaces dieser Autor meint !

Ebenfalls schönen (Fußball-?)Tag.
Silly

[Ashura]

Hallo Silly.

"Je nach Kontext werden verschiedene Zeichen als Leerraum angesehen, fast immer zumindest Leerzeichen und Tabulatorzeichen, meist auch Zeilenumbrüche."

Was ist das für eine Definition ?

Eine leicht verständliche? Wenn sie dir nicht gefällt und dir eine bessere einfällt, steht es dir frei, den Wikipedia-Artikel zu ändern.

Wenn ich demnach irgendwo lese "Diese Routine ersetzt die Whitespaces...", so kann ich mir aussuchen, welche Whitespaces dieser Autor meint !

Whitespaces sind im Normalfall immer dieselben, also Leerzeichen, Tabulatoren und Zeilenumbrüche.

Ebenfalls schönen (Fußball-?)Tag.

Nö, bitte ohne Fußball.

Einen schönen Dienstag noch.

Gruß, Ashura

PS: Du plenkst.

[Silly]

Hallo

Eine leicht verständliche? Wenn sie dir nicht gefällt und dir eine bessere einfällt, steht es dir frei, den Wikipedia-Artikel zu ändern.

Es geht mir nicht um eine leicht verständliche, sondern um eine eindeutige Definition.
"fast immer .... meist auch ...." definieren doch nichts eindeutiges.
Den Artikel kann ich nicht ändern, weil ich ja nicht weiß, welche Zeichen definitiv gemeint sind.

Whitespaces sind im Normalfall immer dieselben, also Leerzeichen, Tabulatoren und Zeilenumbrüche.

Auch hier wieder "im Normalfall"?

Es wäre nach meiner bescheidenen Meinung eindeutig, wenn man definieren würde "Whitespaces sind (genau) die Zeichen mit Nr ...,.... gemäß Code-Tabelle xyz".

Gruß Silly

[Ashura]

Hallo Silly.

Es wäre nach meiner bescheidenen Meinung eindeutig, wenn man definieren würde "Whitespaces sind (genau) die Zeichen mit Nr ...,.... gemäß Code-Tabelle xyz".

Kann man eben aber nicht, gerade weil es noch viele andere Zeichen gibt, die man hinzuzählen kann. Es hängt einfach von der Implementierung ab und ist meist auch irgendwo dokumentiert.

Einen schönen Dienstag noch.

Gruß, Ashura

[Silly]

Hallo wahsaga,
hoffentlich werde ich nicht wieder angepfiffen, dass ich hier poste, aber im thread von heute kann ich ja nicht antworten.
Nach meiner Meinung (ich habe die Charta gelesen) war das einzig
Gemeinsame meiner postings, dass die Probleme in meinem Formmailer (-fragment) auftraten.
Die Probleme waren doch aber grundverschieden.
Im einen Falle war es eine Frage zur from-Angabe
und im andern Falle eine Frage zu regulären Ausdrücken.

Ich war der Annahme, dass eine ganz andere Frage in einem alten thread gestellt, tatsächlich untergeht bzw. dass moniert wird, dass plötzlich ein ganz anderes Thema/Problem angesprochen wird.

Ich bin daher jetzt unsicher, wie ich weiter vorgehen soll, damit ich auch zukünftig die bitter notwendige Hilfe erhalte.

Gehört es tatsächlich in den alten Thread oder hätte ich ein anderes (aussagefähigeres) Thema wählen müssen ?
Gruß
Silly

[Ashura]

Hallo Silly.

Gehört es tatsächlich in den alten Thread oder hätte ich ein anderes (aussagefähigeres) Thema wählen müssen ?

Es gehört nach wie vor zu ein und dem selben Thema, ja.

Und den Threadtitel kannst du jederzeit ändern, indem du eine Vorschau generieren lässt.

Einen schönen Montag noch.

Gruß, Ashura

[Silly]

Hallo,
ist es sinnvoll, im Formmailer die Methode (POST/GET) abzufragen, mit denen die Daten geschickt wurden.
Wie lautet diese Abfrage - möglichst ohne dass ich dafür eine library einbinden muss?
Wenn ich dann auf GET abfrage und es kommt false, ist es dann automatisch POST oder gibt es weitere Varianten?
Danke und schönen Abend

[Struppi]

Wenn ich dann auf GET abfrage und es kommt false, ist es dann automatisch POST oder gibt es weitere Varianten?

POST, GET und HEAD

use CGI;

if( CGI::request_method() eq 'POST')

Struppi.

[Silly]

... und schon hat's geklappt. Danke!

[Silly]

Hallo,
so langsam macht Perl Spaß!
Ist es eigentlich sinnvoll, im Formmailer nicht nur die Werte sondern auch deren Namen auf spam-/hackerverdächtige Elemente zu prüfen?
Oder kommen diese gar nicht an, wenn sie nicht der Namenskonvention entsprechen?

$mailtext = "";
foreach(@names) {
  $name = $_;

#          $name prüfen <=========================================

@values = "";
  @values = $query->param($name);
  if($name ne "return" && $name ne "subject" && .....) {
    foreach $value (@values) {
#          $value prüfen
      $mailtext = $mailtext.$name;
      $mailtext = $mailtext.$delimiter;
      $mailtext = $mailtext.$value."\n";
    }
  }
}
Gruß
Silly

[Siechfred]

Hell-O!

Ist es eigentlich sinnvoll, im Formmailer nicht nur die Werte sondern auch deren Namen auf spam-/hackerverdächtige Elemente zu prüfen?

Grundsätzlich und theoretisch wäre ein Angriff genauso wie über den Wert auch über den Namen möglich, wobei die Gefahr bei der GET-Methode größer ist, da es hier einfacher geht (einfach nur das Name/Wert-Paar anhängen). Ein sicheres Script fragt m.E. nur die Name/Wert-Paare ab, die es erwartet und ignoriert ungefragte Pärchen.

Oder kommen diese gar nicht an, wenn sie nicht der Namenskonvention entsprechen?

Der Typ CDATA ist da ziemlich umfassend: Erlaubt ist alles, was die Zeichenreferenz des Dokumentes hergibt.

foreach(@names) {
  $name = $_;

mache doch gleich die Wertzuweisung im foreach:

foreach my $name (@names) { ... }

#          $name prüfen <=========================================

Wenn du dir die übermittelten Namen via CGI::param holst, würde ich diese mit einer Liste von möglichen Namen (die man bspw. in einem Hash ablegen könnte) abgleichen:

use CGI;  
  
my %formfields = ( foo => '',  
                   bar => '',  
                   baz => ''  
                 );  
  
foreach (CGI::param) {  
  if( exists $formfields{lc($_)} ) {  
    # Value prüfen  
    $formfields{$_} = CGI::param($_);  
    print $_, ' = ', $formfields{$_}, "\n";  
  }  
  else {  
    print 'Unbekannter Name: ', $_;  
  }  
}

Im Ergebnis hast du alle zulässigen Name/Wert-Paare geprüft in deinem Hash %formfields stehen, den du dann weiter verwenden kannst. Aber vielleicht bin ich ja Morgens vor dem 5. Kaffee etwas neurotisch :-)

Siechfred

[Struppi]

Im Ergebnis hast du alle zulässigen Name/Wert-Paare geprüft in deinem Hash %formfields stehen, den du dann weiter verwenden kannst. Aber vielleicht bin ich ja Morgens vor dem 5. Kaffee etwas neurotisch :-)

vielleicht ;-)

ich hab solche Sachen auch schon gemacht, aber wozu?

Die Parameter sind ja schon ausgewertet (durch das CGI Modul) und folglich stehen alle CGI Parameter im Perlskript zu Verfügung. Wieso sollte man also einen zusätzlichen HASH erzeugen, nur um einige ausgewählte Parameter zu kopieren?

Wichtiger ist es denn tatsächlich angekommen Wert zu überprüfen

Struppi.

[Siechfred]

Hell-O!

Aber vielleicht bin ich ja Morgens vor dem 5. Kaffee etwas neurotisch :-)
vielleicht ;-)

Hehe, ich wusste es ;-)

ich hab solche Sachen auch schon gemacht, aber wozu?

Nur gepflegte Neurosen sind gute Neurosen :-)

Die Parameter sind ja schon ausgewertet (durch das CGI Modul) und folglich stehen alle CGI Parameter im Perlskript zu Verfügung. Wieso sollte man also einen zusätzlichen HASH erzeugen, nur um einige ausgewählte Parameter zu kopieren?

Entweder um Parameter herauszufiltern, die nicht von außen (z.B. einem Formular) kommen können, weil es kein entsprechendes Eingabefeld gibt, oder um sämtliche Namen vordefiniert zu haben, also auch diejenigen, die (aus welchen Gründen auch immer) nicht mit übertragen werden.

Wichtiger ist es denn tatsächlich angekommen Wert zu überprüfen

Selbstverständlich, das hatte der OP ja schon erkannt, deswegen bin ich darauf nicht noch mal eingegangen.

Siechfred

[Struppi]

ich hab solche Sachen auch schon gemacht, aber wozu?

Nur gepflegte Neurosen sind gute Neurosen :-)

so gesehen :-)

Die Parameter sind ja schon ausgewertet (durch das CGI Modul) und folglich stehen alle CGI Parameter im Perlskript zu Verfügung. Wieso sollte man also einen zusätzlichen HASH erzeugen, nur um einige ausgewählte Parameter zu kopieren?

Entweder um Parameter herauszufiltern, die nicht von außen (z.B. einem Formular) kommen können, weil es kein entsprechendes Eingabefeld gibt, oder um sämtliche Namen vordefiniert zu haben, also auch diejenigen, die (aus welchen Gründen auch immer) nicht mit übertragen werden.

Naja, die Parameter werden ja nicht rausgefiltert, bzw. solange du nicht darauf zugreifst sind im CGI Modul zwar im Speicher, aber stören sie dort?

Aus dem zweiten Grund hatte ich sowas ähnliches auch mal eingesetzt, aber wieder verworfen, da es praktischer war an Ort und Stelle entsprechend zu reagieren (z.b. mit my $value = CGI::param('name') || '') um z.b. auch Defaultwerte wenn nötig zuweisen zu können.

Ich denke es ist einfach überflüssig, die Werte noch ein zweites mal zu kopieren und sie dann u.U im Skript dann noch ein drittes mal einer Variabel zu zuweisen, um sie dann auf Gültigkeit zu überprüfen

Struppi.

[Silly]

Hallo Ihr alle,
so langsam übersteigt die Diskussion meinen Horizont.
Was ich schade finde ist, dass ich das Musterscript aus SELFHTML hernehme und dann lesen muss, dass das alles ... ist.
Natürlich wurde darauf hingewiesen, dass das Script ein Gerippe ist, das erweitert werden muss (was ich gerade mache). Aber warum ist dann das Gerippe nicht schon mustergültig entwickelt.
Aufruf an die Cracks:
Bis (ich glaube es war) Siechfred sein geheimes Projekt realisiert, was hoffentlich die eierlegende Wollmilchsau wird, ändert doch das Muster-Formularskript.
Wie ich gesehen habe verwenden es nämlich zahlreiche weitere Leidensgenossen.

[Siechfred]

Hell-O!

Was ich schade finde ist, dass ich das Musterscript aus SELFHTML hernehme und dann lesen muss, dass das alles ... ist.

Nein, ist es nicht, da hast du was misserstanden.

Natürlich wurde darauf hingewiesen, dass das Script ein Gerippe ist, das erweitert werden muss (was ich gerade mache). Aber warum ist dann das Gerippe nicht schon mustergültig entwickelt.

Das Gerippe ist mustergültig in der Form, dass es dir einen idealen Einstieg in die Programmierung eines Formmailers mit Perl bietet. Mehr kann und sollte man von einem "Gerippe" auch nicht erwarten, denn wenn man anfängt, sämtliche Sicherheits- und anderen Aspekte einzubauen, bekommt man ein Scriptmonster, das für einen Anfänger nicht mehr überschaubar ist und somit dem SELF-Gedanken widerspräche.

Bis (ich glaube es war) Siechfred sein geheimes Projekt realisiert,

Nee, das war Christoph Schnauß.

Siechfred

[Silly]

Hallo,
ich möchte jetzt prüfen , ob alle Formular-Felder angekommen (und korrekt) sind bzw. ob über diese weitere Felder gesendet wurden.
Dies habe ich folgendermaßen versucht.

wenn Feld vorhanden und in Ordnung war, wurde betr. Eintrag von 'N' auf 'J' gesetzt    =====>

%allfields  = (remote_addr     => 'J',
                Feld2           => 'J',
                Feld3           => 'J',
                ...
                 );

foreach my $name (%allfields)
  {
    print "<br>1. $name: $name";
    print "<br>$allfields{$name}: $allfields{$name}";

if ($allfields{$name} ne 'J')                  # Feld nicht vorhanden oder fehlerhaft
      {
       print "<br>2. $name: $name";
       print "<br>$allfields{$name}: $allfields{$name}";
       exit(0);
     };
    print "<br>3. $name: $name";
    print "<br>$allfields{$name}: $allfields{$name}";

.......................

}

Ergebnis:
1. $name: remote_addr
$allfields{remote_addr}: J
3. $name: remote_addr
$allfields{remote_addr}: J
1. $name: J
$allfields{J}:
2. $name: J
$allfields{J}:

Der erste Durchlauf der Schleife scheint in Ordnung zu sein.
Aber warum ist beim zweiten Male $name = 'J' und nicht 'Feld2'?

[Silly]

... war natürlich keine Meinung, sondern sollte 'PERL' sein!

[Silly]

Problem geklärt!
Habe die spezielle Schleifensyntax für Hashes gefunden!

[Siechfred]

Hell-O!

Naja, die Parameter werden ja nicht rausgefiltert, bzw. solange du nicht darauf zugreifst sind im CGI Modul zwar im Speicher, aber stören sie dort?

Man könnte ja auf den Gedanken kommen (Achtung: Neurosenpflege!), dass ein Missbrauchsversuch dadurch geschieht, dass Name/Wert-Paare an das Script übermittelt werden, die es eigentlich gar nicht geben darf. So gesehen halte ich die Hash-Variante für gar nicht so schlecht.

Aus dem zweiten Grund hatte ich sowas ähnliches auch mal eingesetzt, aber wieder verworfen, da es praktischer war an Ort und Stelle entsprechend zu reagieren (z.b. mit my $value = CGI::param('name') || '') um z.b. auch Defaultwerte wenn nötig zuweisen zu können.

Was aber tust du mit Eingabefeldern, die keine Successful controls sind und somit nicht übermittelt werden? Ich könnte mir durchaus vorstellen, dass hier in dem ein oder anderen Fall trotzdem eine Scriptvariable gebraucht wird.

Ich denke es ist einfach überflüssig, die Werte noch ein zweites mal zu kopieren und sie dann u.U im Skript dann noch ein drittes mal einer Variabel zu zuweisen, um sie dann auf Gültigkeit zu überprüfen

Igitt, wer will denn sowas ;-)

Siechfred

[Struppi]

Naja, die Parameter werden ja nicht rausgefiltert, bzw. solange du nicht darauf zugreifst sind im CGI Modul zwar im Speicher, aber stören sie dort?

Man könnte ja auf den Gedanken kommen (Achtung: Neurosenpflege!), dass ein Missbrauchsversuch dadurch geschieht, dass Name/Wert-Paare an das Script übermittelt werden, die es eigentlich gar nicht geben darf. So gesehen halte ich die Hash-Variante für gar nicht so schlecht.

Naja, das einzige was du damit tust ist quasi die nicht gewünschten Parameter ignorieren, aber das tust du doch auch, wenn du sie einfach ignorierst?

Umgekehrt wird schon eher ein Schuh draus, in dem man überprüft ob ungewünschte Parameter dabei sind.

Aus dem zweiten Grund hatte ich sowas ähnliches auch mal eingesetzt, aber wieder verworfen, da es praktischer war an Ort und Stelle entsprechend zu reagieren (z.b. mit my $value = CGI::param('name') || '') um z.b. auch Defaultwerte wenn nötig zuweisen zu können.

Was aber tust du mit Eingabefeldern, die keine Successful controls sind und somit nicht übermittelt werden? Ich könnte mir durchaus vorstellen, dass hier in dem ein oder anderen Fall trotzdem eine Scriptvariable gebraucht wird.

Das versteh ich nicht. Ich benutze doch oben ein Variabel?

Struppi.

[Siechfred]

Man könnte ja auf den Gedanken kommen (Achtung: Neurosenpflege!), dass ein Missbrauchsversuch dadurch geschieht, dass Name/Wert-Paare an das Script übermittelt werden, die es eigentlich gar nicht geben darf. So gesehen halte ich die Hash-Variante für gar nicht so schlecht.
Naja, das einzige was du damit tust ist quasi die nicht gewünschten Parameter ignorieren, aber das tust du doch auch, wenn du sie einfach ignorierst?

Wenn ich sie nicht abrufe, weiß ich doch gar nicht, dass es sie gibt und kann nicht reagieren (Fehlermeldung o.ä.). Und da du mit einer Blacklist nicht weiterkommst (die wäre quasi unendlich), müsste es für diesen Fall eine Whitelist der erlaubten Felder geben.

Was aber tust du mit Eingabefeldern, die keine Successful controls sind und somit nicht übermittelt werden? Ich könnte mir durchaus vorstellen, dass hier in dem ein oder anderen Fall trotzdem eine Scriptvariable gebraucht wird.
Das versteh ich nicht. Ich benutze doch oben ein Variabel?

Mal angenommen, du hast mehrere Checkboxen. Übermittelt werden nur die angekreuzten, du möchtest aber auch warum auch immer die nicht angekreuzten in einer Variablen haben. Oder du hast eine Auswahlliste, die nur übermittelt wird, wenn wenigstens 1 Eintrag gewählt wird. Wie willst du kontrollieren, ob ein Wert für diese Auswahlliste übermittelt wurde, wenn dem Script nicht wenigstens der Name der Liste bekannt ist. Und da fand ich den Ansatz mit dem Hash irgendwie am elegantesten.

Siechfred

[Struppi]

Wenn ich sie nicht abrufe, weiß ich doch gar nicht, dass es sie gibt und kann nicht reagieren (Fehlermeldung o.ä.). Und da du mit einer Blacklist nicht weiterkommst (die wäre quasi unendlich), müsste es für diesen Fall eine Whitelist der erlaubten Felder geben.

Ich sehe trotzdem keinen Vorteil darin, die bereits virhandenen Parameter in einem zusätzlichen HASH zwischen zu speichern. Es spricht sicher nichts dagegen eine whitelist auf zustellen um dann böse Parameter zu finden, aber dann muss ich die guten Werte ja nicht unbedingt sofort ermitteln.

Aber ich glaub wir drehen uns hier im Kreis.

Mal angenommen, du hast mehrere Checkboxen. Übermittelt werden nur die angekreuzten, du möchtest aber auch warum auch immer die nicht angekreuzten in einer Variablen haben.

Gut, in dem Falle magst du Recht haben.

Oder du hast eine Auswahlliste, die nur übermittelt wird, wenn wenigstens 1 Eintrag gewählt wird. Wie willst du kontrollieren, ob ein Wert für diese Auswahlliste übermittelt wurde, wenn dem Script nicht wenigstens der Name der Liste bekannt ist. Und da fand ich den Ansatz mit dem Hash irgendwie am elegantesten.

Ich glaube ich verstehe, ich würde es aber sicher anders machen, weiß aber nicht wie ;-)

wir sind mal wieder abgeschwiffen, für das konkrete Problem ist es nicht unbedingt sinnvoll.

Struppi.

[Siechfred]

wir sind mal wieder abgeschwiffen, für das konkrete Problem ist es nicht unbedingt sinnvoll.

In der Tat, aber Abschweifungen (englisch: Thread-Drifts) sind doch auch Sinn dieses Forums :-)

Siechfred

[Silly]

Hallo,
Und nun?
Was schlagt Ihr mir vor?
Als Laie (oder sagt man Laie-e+in?) kann ich natürlich nicht beurteilen, was ich jetzt machen soll.
Danke für Eure Unterstützung.
Silly

[Siechfred]

Hell-O!

Was schlagt Ihr mir vor?

Schließe dich Struppis Meinung an und überlasse die wesentliche Arbeit dem CGI-Modul oder schließe dich meinen Neurosen an und prüfe auch die Namen, nicht nur die Werte.

Siechfred

[Struppi]

Was schlagt Ihr mir vor?

Kommt drauf an was du willst.

Sowie ich den Code Auschnittt verstehe, willst du alle CGI Parameter (@names?) in den Mailtext einbauen und verschicken.
Da dort nichts passieren kann, ist es egal ob du die Felder überprüfst oder nicht. Im Prinzip ist es wahrscheinlich interessant zu erfahren ob z.b. gespamt wurde, anderseits will man nicht unbedingt unnötige Mails bekommen. Dann kannst du die Aufrufe ausfiltern (mit Siechfreds Beispiel), die die falschen Felder definieren.

Struppi.

[Silly]

Hallo Struppi,

Kommt drauf an was du willst.

Ich will den Selfhtml Formmailer so erweitern, dass ich die Daten des "echten Ausfüllers" meines Formulars erhalte und die Daten von Spammern u.a. Ungeziefer (verzeiht den Ausdruck, aber mich nerven diese Gauner ungemein) im Nirwana landet.
Gruß Silly

[Struppi]

Kommt drauf an was du willst.

Ich will den Selfhtml Formmailer so erweitern, dass ich die Daten des "echten Ausfüllers" meines Formulars erhalte und die Daten von Spammern u.a. Ungeziefer (verzeiht den Ausdruck, aber mich nerven diese Gauner ungemein) im Nirwana landet.

Da kommt es dann widerrum drauf an, wie intelligent der Bot des Spammers ist, wenn dieser nur die Felder ausfüllt, die vorhanden sind (und dass sollten die meisten tun), hilft dir diese Art der Prüfung nicht weiter, da die Feldnamen dann ja Gültig sind.

Struppi.

[at]

Hallo.

Nur gepflegte Neurosen sind gute Neurosen :-)

Besser Neurosen pflegen als einen Groll hegen.
MfG, at

[Struppi]

so langsam macht Perl Spaß!

gell?

Ist es eigentlich sinnvoll, im Formmailer nicht nur die Werte sondern auch deren Namen auf spam-/hackerverdächtige Elemente zu prüfen?

kommmt drauf an, was du vorhast.
Wenn du damit rausfinden möchtest, ob ein Versuch gestartet wurde das Skript zu manipulieren, ja. also schauen ob entweder seltsame Zeichen in den von dir erwarteten Parametern sind oder schauen ob Parameter kommen, die du nicht erwartest.

Oder kommen diese gar nicht an, wenn sie nicht der Namenskonvention entsprechen?

doch. Alle CGI Parameter werden vom CGI Modul ausgerwertet.

$mailtext = "";
foreach(@names) {
  $name = $_;

#          $name prüfen <=========================================

@values = "";
  @values = $query->param($name);
  if($name ne "return" && $name ne "subject" && .....) {

Das ist nicht besonders schön.

einmal solltest du die Bedingung direkt hinter die Schleife setzten, da du ja ansonsten völlig unnötig den parameter abfragst, ausserdem sieht es so aus als ob du ohne use strict und Warnungen arbeitest. Das ist schlecht, gerade als Anfänger, aber auch bei der Entwicklung größerer Projekte können die Medlungen extrem nützlich sein.

foreach $value (@values) {
#          $value prüfen
      $mailtext = $mailtext.$name;
      $mailtext = $mailtext.$delimiter;
      $mailtext = $mailtext.$value."\n";

Wie in fast allen anderen Programmiersprachen gibt es auch in Perl die Möglichkeit einen Operator auf sich selbst anzuwenden.

$mailtext .= 'xxxxx';

entspricht:

$mailtext = $mailtext . 'xxxx'

Das geht auch mit den meisten anderen Operatoren:

my $x = 0;
$x += 10;
$x *= 2;
...

Also das ganze würde ich ungefähr so machen:

  
my $mailtext = "";  
foreach my $name(@names)  
{  
  if($name ne "return" && $name ne "subject" && .....)  
  {  
     my @values = $query->param($name);  
     foreach my $value (@values)  
     {  
        $mailtext .= "$name$delimiter$value."\n";  
     }  
  }  
}  

Struppi.

[Silly]

Hallo Struppi,

... ausserdem sieht es so aus als ob du ohne use strict und Warnungen arbeitest. Das ist schlecht, gerade als Anfänger, aber auch bei der Entwicklung größerer Projekte können die Medlungen extrem nützlich sein.

Wie kommst Du darauf?
Selbstverständlich beherzige ich Eure Anregungen!
Gruß
Silly

[Struppi]

... ausserdem sieht es so aus als ob du ohne use strict und Warnungen arbeitest. Das ist schlecht, gerade als Anfänger, aber auch bei der Entwicklung größerer Projekte können die Medlungen extrem nützlich sein.

Wie kommst Du darauf?

weil in deinem code nirgends my stand, du soltest lokale Variabeln auch lokal machen.

Selbstverständlich beherzige ich Eure Anregungen!

das ist gut ;-)

Struppi.