Um unseren Hostingkunden diese Dinge nicht immer wieder vom neuen erklären zu müssen, haben wir folgenden Artikel über die richtige Umsetzung von E-Mail Formularen verfasst.

1. Empfängeradresse
2. Absenderadressen und Namen
3. Betreffzeilen
4. Kodierung
5. HTML
6. Return-Path

1. Empfängeradresse

Die Empfängeradresse ist niemals durch den Benutzer festzulegen, da ein Formular so 100%ig zum Versand von Spam missbraucht wird. Die Empfängeradresse ist also fest im Programmcode zu codieren. Versteckte HTML-Formularfelder oder $_GET-Parameter sind ebenfalls nicht geeignet, da sie sehr leicht durch einen Angreifer manipuliert werden können.

2. Absenderadresse und Name

Jede Absenderadresse, die ein Benutzer eingeben darf, ist auf Gültigkeit zu überprüfen. Es reicht ausdrücklich nicht aus, dass die Adresse ein @-Zeichen enthält. Eine Überprüfung mittels regulärem Ausdruck ist Pflicht!

Eine Prüfung kann in PHP beispielsweise wie folgt aussehen:

preg_match(“/^[a-z0-9!#$%&'*+\/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[a-z]{2,4}|museum|travel)$/i”, $adresse)

Im Falle, dass die Adresse gültig ist, gibt preg_match true, im Fehlerfall false zurück.

Was auf gar keinen Fall in der Absenderadresse erlaubt sein darf, ist das Einfügen von Zeilenumbrüchen. Die Verwendung von <input>-Tags reicht hier nicht aus, da ein Angreifer trotzdem Zeilenumbrüche einschleusen kann. Dadurch ist es einem Angreifer möglich, einer E-Mail beliebige Headerzeilen, beispeilsweise eine To: <empfänger> Zeile, hinzuzufügen. Hierdurch kann ein E-Mailformular zum massenhaften Versandt von Spam missbraucht werden.

3. Betreffzeilen

Betreffzeilen dürfen ausschließlich 7-Bit ASCII-Code enthalten. Also kein ä ö ü ß oder ähnliches!
Sonderzeichen müssen generell umkodiert werden.

In PHP ist dies beispielsweise mit der Funktion mb_convert_encoding möglich.

$betreff = mb_convert_encoding($betreff, “ASCII”, “UTF-8″);

Auch in der Betreffzeile darf auf gar keinen Fall ein Zeilenumbruch akzeptiert werden!
Hier gilt das selbe wie bei der Absenderadresse!

4. Kodierung

Die Kodierung einer E-Mail ist stets im Header anzugeben!
Fehlende Header führen immer wieder zu nicht ordnungsgemäß darstellbaren E-Mails.
Der Entwickler merkt dies meist nicht. Er erstellt seine E-Mails beispielsweise in UTF-8, und liest diese auch mit seinem UTF-8 Client. Die Darstellung ist dann natürlich korrekt. Öffnet nun aber jemand mit einem ISO-8859-1 Client diese E-Mails, sieht er statt Umlauten nur schwarze Kästchen oder Fragezeichen. Professionell wirkt dies definitiv nicht! Zuletzt erlebten  wir so eine Sache mit dem Carsharing der Deutschen Bahn. Hier fehlte die Kodierungsangabe, und in allen E-Mails wurden die Umlaute bei uns nicht korrekt dargestellt!

Die Kodierung gehört also in den Header der E-Mail eingebaut. Beispielsweise so:

Content-Type: text/plain; charset=utf-8

Selbstverständlich ist auf die Verwendung des richtigen Zeichensatzes zu achten!

Zum Schluss möchten wir noch anmerken, dass fehldende Kodierungsangaben von Spamfiltern gerne bestraft werden, da normale Mailclients stets die Kodierung in den Mailheader einbauen!

5. HTML

HTML in E-Mails ist eine tolle Sache, würde Sie nur richtig verwendet werden. Der HTML-Code gehört nicht einfach in den Mailbody. Es gibt da draußen nicht gerade wenige Leute, die keine HTML Mails öffnen. Enthält die E-Mail jedoch anstelle des Textes einfach nur HTML-Code, sieht der Benutzer einfach nur HTML-Code und wird der E-Mail keine besondere Beachtung schenken.
HTML E-Mails sind stets als Multipart-Messages zu versenden! Wir Empfehlen folgenden Artikel: http://www.webcheatsheet.com/php/send_email_text_html_attachment.php

6. Return-Path

Die Angabe eines Return-Path im Mailheader ist beim Versand von E-Mails über einen Webserver unerlässlich. Kann eine E-Mail beispielsweise nicht zugestellt werden, erzeugt der Mailserver eine Bounce-Nachricht an den Absender. Dies ist im Normalfall der Webserver, was zur Folge hat, dass diese Nachricht nicht zugestellt werden kann. Ist im Header eine Return-Adresse angeben, werden die Bounce-Mails an diese Adresse versandt. Eine Headerzeile für einen Return-Path sieht wie folgt aus:

Return-Path: <benutzer@domain.tld>

So bemerkt der Webmaster auch, wenn eine E-Mail nicht zugestellt werden konnte.

Eine Option GT 3G Quad.
Im Vorfeld informierte ich mich natürlich, inwiefern diese Karte denn unter Linux läuft. Ich fand also diverse Howto’s, doch funktionieren wollte keines.

Hier also mein Lösungsweg, um anderen diesen Leidensweg ersparen zu können.

Nach dem Einstecken der Karte sollte die Ausgabe von /sbin/dmesg etwa wie folgt aussehen:

[ 3756.756000] ACPI: PCI Interrupt 0000:03:00.1[B] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[ 3756.756000] PCI: Setting latency timer of device 0000:03:00.1 to 64
[ 3756.756000] ohci_hcd 0000:03:00.1: OHCI Host Controller
[ 3756.756000] ohci_hcd 0000:03:00.1: new USB bus registered, assigned bus number 6
[ 3756.756000] ohci_hcd 0000:03:00.1: irq 11, io mem 0xc4001000
[ 3756.840000] usb usb6: configuration #1 chosen from 1 choice
[ 3756.840000] hub 6-0:1.0: USB hub found
[ 3756.840000] hub 6-0:1.0: 1 port detected
[ 3759.916000] usb 6-1: new full speed USB device using ohci_hcd and address 2
[ 3760.128000] usb 6-1: configuration #1 chosen from 1 choice
[ 3760.132000] usbserial_generic 6-1:1.0: GSM modem (1-port) converter detected
[ 3760.132000] usb 6-1: GSM modem (1-port) converter now attached to ttyUSB0
[ 3760.136000] usbserial_generic 6-1:1.1: GSM modem (1-port) converter detected
[ 3760.136000] usb 6-1: GSM modem (1-port) converter now attached to ttyUSB1
[ 3760.140000] usbserial_generic 6-1:1.2: GSM modem (1-port) converter detected
[ 3760.140000] usb 6-1: GSM modem (1-port) converter now attached to ttyUSB2
[ 3760.140000] usbserial_generic 6-1:1.3: GSM modem (1-port) converter detected
[ 3760.144000] usb 6-1: GSM modem (1-port) converter now attached to ttyUSB3

Sollte das Gerät /dev/ttyUSB0 nicht korrekt angelegt worden sein, wird es daran liegen, dass das Modul usbserial nicht korrekt geladen ist. Dies kann mit dem Befehl “modprobe usbserial vendor=0xaf0 product=0×6300″.

Nachdem das Gerät als solches nun also erkannt wurde, muss wie beim Handy auch, die PIN “eingegeben” werden. Das Passiert idealerweise über ein Script. Das Script sieht wie folgt aus:

#!/usr/bin/env perl

use strict;
use warnings;

my $modem = “/dev/ttyUSB0″;
# Substitute xxxx with your PIN.
# You should probably put your pin somewhere else, e.g. on an USB stick,
# an encrypted file system or something else, and read it from there…
# You have been warned!
my $pin = “1234″;

$SIG{ALRM} = sub {
die(“timeout: no response from modem $modem\n”);
};

open(MODEM, “+<”, $modem) or die(“can’t open modem $modem”);
alarm(10);
print(MODEM “AT+CPIN=\”$pin\”\n\r”);
while (<MODEM>) {
if (m/OK/) {
close(MODEM);
print(“PIN accepted\n”);
exit(0);
}
if (m/ERROR/) {
close(MODEM);
print(“PIN rejected\n”);
exit(1);
}
}

Hier sollte natürlich die PIN durch eure ausgetauscht werden.
Dieses Script muss vor jeder Einwahl einmal ausgeführt werden.

Nun geht es an die PPP Konfiguration. Wir benötigen dazu zwei Dateien:
eine PPP Konfiguration und
ein CHAT-Script für die Einwahl.

Hier die PPP Konfiguration in /etc/ppp/peers/vodafone:

hide-password
noauth
connect “/usr/sbin/chat -v -f /etc/chatscripts/vodafone”
debug
/dev/ttyUSB0
460800
defaultroute
noipdefault
user “vodafone”
remotename vodafone
ipparam vodafone
usepeerdns
novj
nobsdcomp

Hier das CHAT-Script in /etc/chatscripts/vodafone:

ABORT BUSY ABORT ‘NO CARRIER’ ABORT VOICE ABORT ‘NO DIALTONE’ ABORT ‘NO DIAL TONE’ ABORT ‘NO ANSWER’ ABORT DELAYED
” ATZ
OK-AT-OK “ATDT*99***1#”
CONNECT \d\c

Anschließend könnt ihr mit “pon vodafone” die “Einwahl” vornehmen und mit “poff vodafone” die Verbindung wieder trennen.

Sollte das alles nicht funktionieren, so ist die Logdatei /var/log/messages euer bester Freund.