mailto: via PHP

[Arx]

Hallo Selfer,

ich habe experimentell einfach mal folgende PHP-Datei auf einen Server hochgeladen:

<?php
header("Location: mailto:[e-mail]");
exit;
?>

Und siehe da: Es funktioniert. Wenn ich die Datei öffne, öffnet sich sofort Word mit einer neuen Nachricht.

Jetzt möchte ich aber noch folgendes wissen:
1. Ist diese Methode wirksam gegen Spambots?
2. Gibt es irgendwelche Risiken oder Nebenwirkungen?

Gruß
Arx

[Dennis]

Hi Arx,

<?php
header("Location: mailto:[e-mail]");
exit;
?>

Da ich etwas im Zweifel war, ob mailto: im PHP header() erlaubt ist, habe ich nachgeschaut. PHP.net (http://de.php.net/manual/de/function.header.php) sagte mir dann dazu:

"HTTP/1.1 verlangt einen absoluten URI inkl. dem Schema, Hostnamen und absoluten Pfad als Argument von Location; aber manche Clients akzeptieren auch relative URIs."

Das hört sich so an, also ob mailto: nicht genehmigt wäre, wo ich mich durch http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 dann auch noch bestätigt fühlte:

• Location       = "Location" ":" absoluteURI -

Und siehe da: Es funktioniert. Wenn ich die Datei öffne, öffnet sich sofort Word mit einer neuen Nachricht.

Word? Kann man aus Word E-Mails verschicken? Funktioniert das auch in _allen_ Browsern?

Jetzt möchte ich aber noch folgendes wissen:

1. Ist diese Methode wirksam gegen Spambots?

Da kann ich dir leider nichts außer Vermutungen zu sagen. Spambots die nur den Quellcode einer Seite durchsuchen, werden wohl nichts zu sehen bekommen. Letztlich eh egal, wenn mailto: gar nicht im PHP header() erlaubt ist.

2. Gibt es irgendwelche Risiken oder Nebenwirkungen?

Natürlich gibt es immer noch die grundsätzlichen Nachteile von mailto:, wie sie auch bei Formularen anzutreffen sind, siehe auch http://tutorial.riehle-web.com/formulare/versenden.html#server

MfG, Dennis.

[wahsaga]

hi,

Letztlich eh egal, wenn mailto: gar nicht im PHP header() erlaubt ist.

das ist es definitiv nicht.

header() ist dazu da, um HTTP-header auszulesen - mailto: ist aber kein bestandteil von HTTP.

und nur weil zufällig eine kombination aus client- und serverseitiger konfiguration gefunden wurde, bei der das "geht", sollte man ja bekanntlich noch lange nicht auf ein allgemeingültiges "es funktioniert" schliessen.

@Arx: diesen unfug bitte schnellstmöglich vergessen.

gruß,
wahsaga

[Arx]

Hallo,

Letztlich eh egal, wenn mailto: gar nicht im PHP header() erlaubt ist.

das ist es definitiv nicht.

header() ist dazu da, um HTTP-header auszulesen - mailto: ist aber kein bestandteil von HTTP.

und nur weil zufällig eine kombination aus client- und serverseitiger konfiguration gefunden wurde, bei der das "geht", sollte man ja bekanntlich noch lange nicht auf ein allgemeingültiges "es funktioniert" schliessen.

@Arx: diesen unfug bitte schnellstmöglich vergessen.

Ok, wenn ihr das meint :-(

Hat jedenfalls mit Firefox, IE und Opera funktioniert (, wobei mir letzterer seinen eigenen Mail-Client aufzuhalsen versuchte) .

Gruß
Arx

[Andreas-Lindig]

Hallo Arx,

warum machst Du nicht einen einfachen Formmailer, statt son Krampf?

Gruß, Andreas

[Arx]

Hallo,

warum machst Du nicht einen einfachen Formmailer, statt son Krampf?

Ich möchte eine zweigleisige Lösung anbieten: Mail-Link _und_ Form-Mailer.

Gruß
Arx, dem die linke Backe schmerzt, weil er heute morgen seine letzten zwei Weisheitszähne losgeworden ist

[Dennis]

Hi Andreas-Lindig,

warum machst Du nicht einen einfachen Formmailer, statt son Krampf?

Da würde dann garantiert auch gar kein Spammbot drankommen, da die Adresse gar nicht herausgegeben wird, sondern die Daten serverseitig versandt werden ;-)

MfG, Dennis.

[Sönke Tesch]

Letztlich eh egal, wenn mailto: gar nicht im PHP header() erlaubt ist.

das ist es definitiv nicht.

Falsch, es ist erlaubt (ich beziehe mich hier auf HTTP-Location & mailto:, mit PHP und header() hat das alles nur sehr entfernt am Rande zu tun).

header() ist dazu da, um HTTP-header auszulesen

Nicht so hastig, header() gibt etwas aus, zum Einlesen ist die Funktion nicht da.

mailto: ist aber kein bestandteil von HTTP.

Nein, muß es auch nicht. Dennis hat schon die richtige Seite rausgesucht: In Abschnitt 14.30 der HTTP/1.1-Spezifikation (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30) heißt es zur Syntax des HTTP-Kopfs Location:

Location       = "Location" ":" absoluteURI

Leider hat Dennis sich nicht die Mühe gemacht, mal weiter zu schauen, was "absolute URI" eigentlich bedeutet; dabei ist die Antwort nur eineinhalb Seiten entfernt.
Der Begriff "absoluteURI" gibt schon alleine einen Hinweis darauf, dass damit keine spezielle URI-Form gemeint sein kann (andernfalls hieße es "absoluteHTTPURI" oder etwas in der Art). Genau steht es in Abschnitt 3.2.1 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1), dort heißt es nämlich lapidar, die HTTP/1.1-Spezifikation "adopts the definitions of [..] 'absoluteURI' [..] from ['Uniform Resource Identifiers (URI): Generic Syntax and Semantics,' RFC 2396]". In der allgemeinen (!) Beschreibung von URIS, RFC 2396, angekommen, lesen wir

absoluteURI   = scheme ":" ( hier_part | opaque_part )

Allgemeiner geht's bald nicht mehr, von einer Beschränkung auf HTTP keine Spur. Wer trotzdem noch zweifelt, darf meinetwegen auch noch "scheme" nachschauen.

Kurz: Bei Location kann jede denkbare URI angegeben werden.

und nur weil zufällig eine kombination aus client- und serverseitiger konfiguration gefunden wurde, bei der das "geht", sollte man ja bekanntlich noch lange nicht auf ein allgemeingültiges "es funktioniert" schliessen.

Ein Browser, der in Location nur HTTP akzeptiert (und vielleicht FTP), ist schlichtweg kaputt. Nichtsdestotrotz wäre ich allerdings auch etwas vorsichtig bei der Angabe von mailto: in diesem Fall, obwohl eigentlich nichts für eine spezialisierte Behandlung von URIs, die mit Location statt <a> & Co. kommen, spricht.

@Arx: diesen unfug bitte schnellstmöglich vergessen.

Jaja, Lesen bildet ;)

Gruß,
  soenk.e

[Arx]

Hallo,

danke für die ausführliche Info! Habe mich noch ein wenig weiter schlau gemacht:

absoluteURI   = scheme ":" ( hier_part | opaque_part )

Allgemeiner geht's bald nicht mehr, von einer Beschränkung auf HTTP keine Spur. Wer trotzdem noch zweifelt, darf meinetwegen auch noch "scheme" nachschauen.

Auf http://zvon.org/tmRFC/RFC2396/Output/chapter3.html#sub1 steht genaustens definiert, was Scheme enthalten darf. Ich habe die Einzelbestandteile wie "alpha" zwar jetzt nicht nachgeschaut, aber aus dem Text geht hervor, dass da alles stehen kann.
Desweiteren stehen auf http://zvon.org/tmRFC/RFC2396/Output/chapter1.html#sub3 einige Beispiele für URIs, darunter auch:

mailto:[e-mail]
      -- mailto scheme for electronic mail addresses

Folglich sollte das senden eines Headers mit mailto: an den aufrufenden Client kein Problem sein, vorausgesetzt, letzterer kann mit mailto: umgehen.

Gruß
Arx

[Arx]

Hallo,

Nachtrag:
Das ganze kann hier (-> http://cojobo.bonn.de/~s_rheind/homepage/tmp/index.php ) ausprobiert werden.

Gruß
Arx

[Andreas Korthaus]

Hi!

Jetzt möchte ich aber noch folgendes wissen:

1. Ist diese Methode wirksam gegen Spambots?

Prinzipiell nicht. Ein Spambot kann natürlich Location-Header auf mailto: filtern, da diese Methode tatsächlich von einigen Seiten eingesetzt wird, könnte ich mir durchaus vorstellen, dass es spambots gibt die das machen, ich weiß es aber nicht.

2. Gibt es irgendwelche Risiken oder Nebenwirkungen?

Ja, wenn entweder der Browser dies nicht implementiert hat, oder der Anwender kein Standard-Email-Programm definiert hat, oder wenn das Betriebssystem sowas nicht ermöglicht. Bei Mozilla ist (war?) sowas z.B. nicht per default eingerichtet, das ging früher nur über eine manuelle Änderung in einer Konfigurations-Datei, möglicherweise geht das inzwichen, k.A. Auch geht das unter Linux nicht ganz so einfach - wenn überhaupt. Firefox macht das bei mir jedenfalls nicht.

Naja, in all diesen Fällen hat der Anwender keine Möglichkeit an die email-Adresse zu kommen (na gut, mit einem Sniffer... :)). Daher würde ich das lassen.

Hab mal kurz gegoogelt: http://lists.evolt.org/archive/Week-of-Mon-20031208/152403.html

das sollte Deine Frage beantworten, und bedenke, das ist schon von 2003, und es gibt sicher erheblich ausgefeiltere Programme...

Grüße
Andreas

[Arx]

Hallo,

2. Gibt es irgendwelche Risiken oder Nebenwirkungen?
   Ja, wenn entweder der Browser dies nicht implementiert hat, oder der Anwender kein Standard-Email-Programm definiert hat, oder wenn das Betriebssystem sowas nicht ermöglicht. Bei Mozilla ist (war?) sowas z.B. nicht per default eingerichtet, das ging früher nur über eine manuelle Änderung in einer Konfigurations-Datei, möglicherweise geht das inzwichen, k.A. Auch geht das unter Linux nicht ganz so einfach - wenn überhaupt. Firefox macht das bei mir jedenfalls nicht.

Unter meinem WinXP funktioniert's mit Firefox 0.8, Opera 7.50 und IE 6. (Mehr Browser habe ich nicht.)

Naja, in all diesen Fällen hat der Anwender keine Möglichkeit an die email-Adresse zu kommen (na gut, mit einem Sniffer... :)). Daher würde ich das lassen.

Ich könnte die Adresse als 3D-Text in einer Grafik speichern und auf der Seite anzeigen. Hat ein Spambot bei sowas noch eine Chance?

Hab mal kurz gegoogelt: http://lists.evolt.org/archive/Week-of-Mon-20031208/152403.html
das sollte Deine Frage beantworten, und bedenke, das ist schon von 2003, und es gibt sicher erheblich ausgefeiltere Programme...

Interessant. Danke!

Gruß
Arx

[at]

Hallo.

Ich könnte die Adresse als 3D-Text in einer Grafik speichern und auf der Seite anzeigen. Hat ein Spambot bei sowas noch eine Chance?

Hat ein Nutzer bei sowas noch die Geduld?
MfG, at