/Email: Schutz vor Headerinjektion (2. Teil)

[Robert Bienert]

Hallo Forum!

Vor kurzem hatte ich gefragt, ob eine simple PHP-Funktion zum Versenden von Emails sicher sei. Ich bin gerade noch einmal an dem Problem dran und habe so eben eine ganz praktische Funktion aus der mbstring-Bibliothek gefunden: mb_encode_mimeheader. Nach meinen Test werden damit nicht nur die Header Encoding-gerecht codiert, sondern gleich auch noch Header-Injektionen abgefangen. Beispiel:

$mail = "\"Robert Bienert\" <root@localhost>\r\nBCC: [e-mail]";  
echo mb_encode_mimeheader($mail, mb_detect_encoding($mail), 'Q'), "\n";

Ausgabe:

"Robert Bienert" =?US-ASCII?Q?=3Croot=40localhost=3E=0D=0ABCC=3A=20Spam?=
 =?US-ASCII?Q?=40receiver=2Ecom?=

Meine Frage hier erst einmal: Reicht das?

Und für Emailadressen der Form "Absender" <[e-mail]>´´ müsste ich dann wohl Absender´´ und die Emailadresse getrennt codieren und dann zusammensetzen, oder? So, wie es aussieht, müssen im Namen noch " escaped werden.

Viele Grüße,
Robert

[Tom]

Hello Robert,

$mail = ""Robert Bienert" root@localhost\r\nBCC: [e-mail]";

echo mb_encode_mimeheader($mail, mb_detect_encoding($mail), 'Q'), "\n";

>   
> Ausgabe:  
>   
> "Robert Bienert" =?US-ASCII?Q?=3Croot=40localhost=3E=0D=0ABCC=3A=20Spam?=  
>  =?US-ASCII?Q?=40receiver=2Ecom?=  
  
Das sieht ja schon recht gut aus. Nur bin ich jetzt irritiert, ob das  
  
  To: Robert Bienert <root@localhost>;  
  
überhaupt so codiert werden muss, wie Du es oben gezeigt hast.  
Da ist die Funktion mMn zu agressiv.  
  
  
  
  
  
  
Ein harzliches Glückauf  
  
Tom vom Berg  
  
<http://bergpost.annerschbarrich.de>  
.

-- 
Nur selber lernen macht schlau  

[Robert Bienert]

Moin!

"Robert Bienert" =?US-ASCII?Q?=3Croot=40localhost=3E=0D=0ABCC=3A=20Spam?=
=?US-ASCII?Q?=40receiver=2Ecom?=

Das sieht ja schon recht gut aus. Nur bin ich jetzt irritiert, ob das

To: Robert Bienert root@localhost;

überhaupt so codiert werden muss, wie Du es oben gezeigt hast.

Also den Namen würde ich schon so codieren, schließlich können da ja haufenweise Zeichen vorkommen, die mit 7-Bit ASCII nicht darstellbar sind. Wie sieht es eigentlich mit der Emailadresse aus?

Insgesamt sähe ein To-Feld dann irgendwie so aus:

$to = '"' .  
      mb_encode_mimeheader($name, mb_detect_encoding($name), 'Q') .  
      '" <' .  
      $adresse . // ← muss irgendwie codiert werden (\n \r < >)  
      '>';

Schönen Sonntag,
Robert

[Tom]

Hello,

"Robert Bienert" =?US-ASCII?Q?=3Croot=40localhost=3E=0D=0ABCC=3A=20Spam?=
=?US-ASCII?Q?=40receiver=2Ecom?=

Das sieht ja schon recht gut aus. Nur bin ich jetzt irritiert, ob das

To: Robert Bienert root@localhost;

überhaupt so codiert werden muss, wie Du es oben gezeigt hast.

Also den Namen würde ich schon so codieren, schließlich können da ja haufenweise Zeichen vorkommen, die mit 7-Bit ASCII nicht darstellbar sind. Wie sieht es eigentlich mit der Emailadresse aus?

Insgesamt sähe ein To-Feld dann irgendwie so aus:

$to = '"' .

mb_encode_mimeheader($name, mb_detect_encoding($name), 'Q') .
      '" <' .
      $adresse . // ← muss irgendwie codiert werden (\n \r < >)
      '>';

  
Die Adresse muss nur kontrolliert und ggf. entsorgt werden, weil sie (bisher) nur 7-bit ASCII enthalten durfte. Ob das nun, seitdem die Domainnamen auch unsinnig aufgeblasen wurden, auch geändert wurde, weiß ich noch nicht. Wäre aber für Deine Überlegungen mMn wichtig.  
  
Und dann darf sie eben keine Whitespaces enthalten.  
  
  
Ein harzliches Glückauf  
  
Tom vom Berg  
  
<http://bergpost.annerschbarrich.de>  
.

-- 
Nur selber lernen macht schlau  

[dedlfix]

echo $begrüßung;

"Robert Bienert" =?US-ASCII?Q?=3Croot=40localhost=3E=0D=0ABCC=3A=20Spam?=
=?US-ASCII?Q?=40receiver=2Ecom?=
Das sieht ja schon recht gut aus.

Nein, das ist falsch.

Nur bin ich jetzt irritiert, ob das
  To: Robert Bienert root@localhost;
überhaupt so codiert werden muss, wie Du es oben gezeigt hast.

Eben deswegen, so darf es nicht behandelt werden.

Also den Namen würde ich schon so codieren, schließlich können da ja haufenweise Zeichen vorkommen, die mit 7-Bit ASCII nicht darstellbar sind. Wie sieht es eigentlich mit der Emailadresse aus?

Versuch es doch nicht mit Rätselraten, schau dir dir RFC an. Für Mail ist es die RFC 2822, da ist bis aufs einzelne Zeichen aufgelöst, welcher Teil was genau enthalten darf.

Unabhängig von deinen Bestrebungen, die Userangaben normgerecht und sicher zu verpacken, würde ich beim Auftreten eines Zeilenumbruchs in der Benutzerangabe den Vorgang kurz und schmerzvoll beenden[1], denn auch normgerecht und sicher verpackter Spam bleibt Spam. Der Versuch ist strafbar.

[1] kommentarlos oder mit recht kurzem Kommentar die Ausführung abbrechen. Einem Spambot ist es egal, was für eine Antwort er ignoriert.

echo "$verabschiedung $name";

[Tom]

Hello,

[1] kommentarlos oder mit recht kurzem Kommentar die Ausführung abbrechen. Einem Spambot ist es egal, was für eine Antwort er ignoriert.

Das sehe ich auch so!
Und für sich selber sollte man da einen Logeintrag erzeugen mit allen verfügbaren Daten.
Vielleicht wird man dann doch mal einem dieser Burschen habhaft.

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.

[Robert Bienert]

Moin!

Versuch es doch nicht mit Rätselraten, schau dir dir RFC an. Für Mail ist es die RFC 2822, da ist bis aufs einzelne Zeichen aufgelöst, welcher Teil was genau enthalten darf.

Das ist genau das, was ich wissen wollte. Nein, mal im Ernst, ich suche nicht _die perfekte_ Lösung, nur etwas, was schnell und sicher ist und sich nicht mit der rekursiven Definition einer formal gültigen Emailadresse herumschlägt.

Schönen Sonntag,
Robert

[dedlfix]

echo $begrüßung;

Versuch es doch nicht mit Rätselraten, schau dir dir RFC an. Für Mail ist es die RFC 2822, da ist bis aufs einzelne Zeichen aufgelöst, welcher Teil was genau enthalten darf.

Das ist genau das, was ich wissen wollte. Nein, mal im Ernst, ich suche nicht _die perfekte_ Lösung, nur etwas, was schnell und sicher ist und sich nicht mit der rekursiven Definition einer formal gültigen Emailadresse herumschlägt.

Auch wenn du nur eingeschränkt korrekt sein willst, musst du die Regeln kennen, damit du entscheiden kannst, welchen Teil du davon gefahrlos ignorieren kannst. Die genaue Definition einer Email-Adresse ist vielleicht nicht Ziel deiner Überprüfung, aber aus der RFC kannst du erkennen, dass du eine Email-Adresse nicht verwursten darfst, weil diese im Klartext gelesen werden muss.

echo "$verabschiedung $name";

[Robert Bienert]

Moin!

Die Antwort war bei mir ganz untergegangen, ich bitte um Entschuldigung:

Auch wenn du nur eingeschränkt korrekt sein willst, musst du die Regeln kennen, damit du entscheiden kannst, welchen Teil du davon gefahrlos ignorieren kannst. Die genaue Definition einer Email-Adresse ist vielleicht nicht Ziel deiner Überprüfung, aber aus der RFC kannst du erkennen, dass du eine Email-Adresse nicht verwursten darfst, weil diese im Klartext gelesen werden muss.

D.h. das From-Feld muss auf jeden Fall gültig aufgebaut sein und die Emailadresse darf _nicht_ codiert werden. Mit anderen Worten: "Unerwünschte Zeichen" darin führen zum Verwerfen der Nachricht.

Viele Grüße,
Robert

[Sven Rautenberg]

Moin!

Vor kurzem hatte ich gefragt, ob eine simple PHP-Funktion zum Versenden von Emails sicher sei. Ich bin gerade noch einmal an dem Problem dran und habe so eben eine ganz praktische Funktion aus der mbstring-Bibliothek gefunden: mb_encode_mimeheader. Nach meinen Test werden damit nicht nur die Header Encoding-gerecht codiert, sondern gleich auch noch Header-Injektionen abgefangen.

Das stimmt so nicht. Im Gegenteil wandert der injizierte Header aus meiner Sicht eher in einen Graubereich. Ich habe die RFCs nicht auswendig drauf, von daher ist mir nicht bekannt, ob dieser Bereich spezifiziert wurde, aber letztlich wird der Spamheader nur nett verpackt - aber nicht elimniert.

Ausgabe:

"Robert Bienert" =?US-ASCII?Q?=3Croot=40localhost=3E=0D=0ABCC=3A=20Spam?=
=?US-ASCII?Q?=40receiver=2Ecom?=

In dem codierten String tauchen =0D=0A auf, das ist der Zeilenumbruch. Mails sind ein ziemlich fragiles und simples System, jede Mail ist praktisch als Textdatei zu betrachten, die einigen Konventionen genügen muß, damit die beteiligten verarbeitenden Komponenten den Text parsen können.

Die Frage ist also: Was greift zuerst? Das Auseinanderpflücken der Header, oder das Dekodieren von codierten Passagen?

Wenn letzteres, dann taucht der Zeilenumbruch und der Spamheader unversehrt wieder auf und wird dann geparst - nix mit Unschädlichkeit!

Und da man, unabhängig von einer möglichen Spezifikation nicht davon ausgehen kann, dass alle Software das "richtig" macht, würde ich mich auch nie auf solch einen Zweifelsfall verlassen.

Deshalb gibt es nur eins:
Header-Injection kann nur dadurch verhindert werden, dass ein einzelner Headerinhalt keinerlei Zeilenumbrüche enthält - und zwar schon nicht in seinen Rohdaten. Ob der Versuch mit Abbruch oder Entschärfung (ersetzen durch Leerzeichen) bestraft wird, ist Abwägungssache je nach Anwendung.

Danach ist selbstverständlich das Encoding in passender Form erforderlich, da heutzutage mutmaßlich der UTF-8-Zeichenbereich in vielen Namen Verwendung findet.

- Sven Rautenberg

[Robert Bienert]

Moin!

Ich fasse also mal zusammen:

• Zeichen, die nach Newline aussehen, werden in Headern generell nicht zugelassen (Verwerfen der Email).

• Der Betreff wird ggf. codiert (mb_encode_mimeheader).

• Der Absendername wird in " eingeschlossen und ggf. codiert.

• Die Emailadresse des Absenders darf der Einfachheit halber (da wir keine perfekte Mailfunktion hier implementieren wollen) nur die Zeichen [a-zA-Z0-9.@-_]+ enthalten.

Ist das OK?

Schönen Sonntag,
Robert

[Tom]

Hello,

Ich fasse also mal zusammen:

• Zeichen, die nach Newline aussehen, werden in Headern generell nicht zugelassen (Verwerfen der Email).

• Der Betreff wird ggf. codiert (mb_encode_mimeheader).

• Der Absendername wird in " eingeschlossen und ggf. codiert.

• Die Emailadresse des Absenders darf der Einfachheit halber (da wir keine perfekte Mailfunktion hier implementieren wollen) nur die Zeichen [a-zA-Z0-9.@-_]+ enthalten.

Ist das OK?

Das sieht nun schon _fast_ gut aus.

Das Codieren mit mb_encode_mimeheader() muss berücksichtigen, wie die Zeichen bereits codiert sind, wenn sie Dein Script erreichen.

Was ist mit From:, Cc:, Bcc: ?

Und die Zeichen der Meldung müssen dann auch noch auf das Content-Encoding geprüft und ggf. einem Transfer-Encoding unterzogen werden.

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.

[Robert Bienert]

Moin!

Das Codieren mit mb_encode_mimeheader() muss berücksichtigen, wie die Zeichen bereits codiert sind, wenn sie Dein Script erreichen.

Der Funktion kann man doch die Ausgangscodierung als zweiten Parameter übergeben. Entweder weiß ich die, ansonsten kann mir mb_detect_encoding weiterhelfen.

Was ist mit From:, Cc:, Bcc: ?

From gebe ich vor und die anderen beiden sind skriptseitig nicht vorgesehen. Diese kleine Wrapperfunktion soll in einem Kontaktformular eingesetzt werden können, d.h. andere Leute schreiben mir, und sonst niemandem.

Und die Zeichen der Meldung müssen dann auch noch auf das Content-Encoding geprüft und ggf. einem Transfer-Encoding unterzogen werden.

Stimmt, da war doch was. Notiz an mich: Im Archiv nachschauen.

Schönen Sonntag,
Robert

[Tom]

Hello,

Stimmt, da war doch was. Notiz an mich: Im Archiv nachschauen.

Und wenn Du schon mal dabei bist, könntest Du doch auch gleich noch ein Attachment ermöglichen. Das setzt aber wieder eine Session und eine Vorgangsbearbeitung voraus, da beim Upl,oad ja 'was schief gehen könnte und der Text dann nicht alleine geschickt werden soll.

usw...

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.

[Robert Bienert]

Moin!

Und wenn Du schon mal dabei bist, könntest Du doch auch gleich noch ein Attachment ermöglichen.

Wieso sollte mir jemand einen Anhang per Kontaktformular schicken wollen? Das Skript ist GPL, da kann jeder diese Funktionalität nachrüsten, wenn er sie braucht ;-)

Schönen Sonntag,
Robert

[dedlfix]

echo $begrüßung;

Das Codieren mit mb_encode_mimeheader() muss berücksichtigen, wie die Zeichen bereits codiert sind, wenn sie Dein Script erreichen.
Der Funktion kann man doch die Ausgangscodierung als zweiten Parameter übergeben. Entweder weiß ich die, ansonsten kann mir mb_detect_encoding weiterhelfen.

Darauf würde ich micht nicht verlassen. Im Gegenteil, würde ich den Einsatz einer solchen Funktion für ein System, das komplett automatisch arbeiten soll, aufgrund der vielen Unwägbarkeiten nicht in Erwägung ziehen. Ihr Name verspricht viel mehr, als sie am Ende zu leisten vermag. Abgesehen von dem in den Userkommentaren der Handbuchseite zu mb_detect_encoding() erwähnten Fehler, der in PHP 5.2.6 auch noch enthalten ist, steht die MB-Erweiterung eventuell nicht überall zur Verfügung, was daran liegt, dass sie vor noch nicht allzulanger Zeit noch das Experimentell-Kennzeichen trug. Des weiteren ist eine Erkennung der Kodierung technisch bedingt nur mit sehr starken Einschränkungen und auch dann nicht in allen Situationen fehlerfrei möglich. Ein Dokument ist ja im Grunde genommen nichts weiter als eine Aneinanderreihung von Bytewerten. In einigen Kodierungen sind bestimmte Bytefolgen nicht erlaubt. Man kann deshalb ausschließen, dass ein Text in dieser Kodierung vorliegt. Doch jeglicher Multibyte-Text, einschließlich UTF-8, ist immer auch gültiger ISO-8859-x-Text. Eine Aneinanderreihung der einzelnen Bytes eines Zeichens aus einer Multibytekodierung ist in den meisten Fällen eine gültige ISO-8859-Kodierung. Selbst wenn Bytes auftauchen, die in einzelnen ISO-8859 nicht definiert sind, findet sich garantiert eine Windows-irgendwas-Kodierung, die diese Lücke auffüllt. Ganz vorbei ist es dann, wenn man zwischen den einzelnen ISO-8859-Kodierungen unterscheiden muss. Das Zeichen mit dem Bytewert 230 (0xE6) kann beispielsweise je nach Kontext æ, ć, ĉ, ц, ζ, ๆ, ę und noch zwei weitere Zeichen mit "falscher" Schreibrichtung bedeuten (die machte mir hier beim Zitieren Probleme, weswegen ich die beiden Zeichen wegließ). Ohne Inhaltsanalyse ist da nichts zu machen. Die dürfte für einen Menschen schwer genug ausfallen, wenn es sich, wie bei Email-Adressen nicht unüblich, um Zeichenkombinationen handelt, die nicht im Wörterbuch vorkommen. Steht dieser Funktion ein Wörterbuch sämtlicher Sprachen zur Verfügung? Wohl kaum. Die Intelligenz eines Computers ist also auch ziemlich überfordert, besonders bei so kurzen Texten, wie sie in Email-Headern üblicherweise stehen.

Im Firefox und sicher auch in anderen Browser gibt es eine Funktion, die die Kodierung zu erkennen versucht, wenn die Webseite oder der Server keine Angaben dazu mitliefert. Hier ist das Ziel, den dekodierten Text einem Menschen vorzulegen. Dieser kann dann immer noch entscheiden, dass die geratene Kodierung nicht stimmt und sich im Menü eine passendere auswählen. In deinem Anwendungsfall ist eine solche Korrekturmöglichkeit jedoch nicht vorgesehen.

echo "$verabschiedung $name";

[Robert Bienert]

Moin!

Ich fasse mal kurz zusammen: Das Encoding, welches ich im form-Tag setze und daher weiß, nutze ich auch am Besten im Skript.

Schönen Sonntag,
Robert

[Tom]

Hello,

Ich fasse mal kurz zusammen: Das Encoding, welches ich im form-Tag setze und daher weiß, nutze ich auch am Besten im Skript.

Du hoffst, dass der Client Dir dasselbe zurückschickt.
Tut er es aber nicht, hast Du mehrere Möglichkeiten:

• Du hast selber einen Fehler bei der Formulierung Deiner Bitte an den Client gemacht
• Der Client ist doof oder zu alt
• Der Client ist ein Bot
• Du hast Dich bei der Auswertung im Script geirrt und eigentlich stimmen die Daten vom Client
• irgendwas ganz anderes.
    Diese Ursache wird leider in Fehleranalysen meistens vergessen, was dann
    zur wichtigsten Sicherheitslücke von Systemen wird

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.

[Robert Bienert]

Moin!

Ich fasse mal kurz zusammen: Das Encoding, welches ich im form-Tag setze und daher weiß, nutze ich auch am Besten im Skript.

Du hoffst, dass der Client Dir dasselbe zurückschickt.

Jaja, im Internet ist man nur Bittsteller, ich vergaß.

Aber wo wäre das Problem, wenn der Client z.B. für UTF-8 zu „doof“ ist und stattdessen irgendetwas Anderes schickt? Wenn ich das Encoding im Skript vorher definiere und dann nur auf die Definition zugreife, habe ich diese Fehlerquelle schon einmal erschlagen.

Schönen Sonntag,
Robert

[Dennis]

Hi Robert,

• Zeichen, die nach Newline aussehen, werden in Headern generell nicht zugelassen (Verwerfen der Email).

Nach Newline aussehen? Wieso nicht einfach Zeichen, die Newlines sind? ;-) Also speziell CR (\r) und LF (\n).

• Der Betreff wird ggf. codiert (mb_encode_mimeheader).

Ja, solltest du machen - aber auch hier gilt bei mir: Keine Newline-Zeichen zulassen.

• Der Absendername wird in " eingeschlossen und ggf. codiert.

Willst du den im From-Header angeben? Ich würde ja eher den From-Header vom Server generieren lassen und die Daten des Users lediglich in Reply-To schreiben.

• Die Emailadresse des Absenders darf der Einfachheit halber (da wir keine perfekte Mailfunktion hier implementieren wollen) nur die Zeichen [a-zA-Z0-9.@-_]+ enthalten.

Hm… Das mit den E-Mail Adressen ist wieder so ein Problem. So ist "Hallo Welt"@example.org eine gültige E-Mail Adresse.

Wie sieht das eigentlich mit "@@@"@example.org aus - wäre das auch eine gültige E-Mail Adresse?

Viele Grüße,
  ~ Dennis.

[Vinzenz Mai]

Hallo Dennis,

Wie sieht das eigentlich mit "@@@"@example.org aus - wäre das auch eine gültige E-Mail Adresse?

ja. Siehe Selfforumssieb.

Freundliche Grüße

Vinzenz

[Robert Bienert]

Moin!

• Der Betreff wird ggf. codiert (mb_encode_mimeheader).

Ja, solltest du machen - aber auch hier gilt bei mir: Keine Newline-Zeichen zulassen.

Das mit den Newlines bezog sich auf alle Felder, in denen Eingaben vom Nutzer landen.

• Der Absendername wird in " eingeschlossen und ggf. codiert.

Willst du den im From-Header angeben? Ich würde ja eher den From-Header vom Server generieren lassen und die Daten des Users lediglich in Reply-To schreiben.

Was wäre denn der Grund dafür?

• Die Emailadresse des Absenders darf der Einfachheit halber (da wir keine perfekte Mailfunktion hier implementieren wollen) nur die Zeichen [a-zA-Z0-9.@-_]+ enthalten.

Hm… Das mit den E-Mail Adressen ist wieder so ein Problem. So ist "Hallo Welt"@example.org eine gültige E-Mail Adresse.

Das mag formal sein, aber

• welcher Otto Normal weiß das (und für den soll dieses Skript sein)?
 • bei welchem Provider kannst du eine solche Adresse einrichten?

Schönen Wochenanfang,
Robert

[Dennis]

Hi Robert,

Willst du den im From-Header angeben? Ich würde ja eher den From-Header vom Server generieren lassen und die Daten des Users lediglich in Reply-To schreiben.

Was wäre denn der Grund dafür?

Im Zuge von Anti-Spam Maßnahmen könnte ein Mailserver auf die Idee kommen zu prüfen, ob dein Server (welcher diese Mail verschickt) überhaupt berechtigt ist Mails von diesem Absender zu schicken. SPF wäre ein Beispiel für eine solche Technik.

Der empfangende Mailserver lehnt dann möglicherweise deine Mail ab, weil du die Mail unter dem Absender „[e-mail]” losgeschickt hast, jedoch dein Server nicht als solcher gelistet ist, welcher Mails von „example.org” verschicken darf.

Das mag formal sein, aber

• welcher Otto Normal weiß das (und für den soll dieses Skript sein)?
• bei welchem Provider kannst du eine solche Adresse einrichten?

Hier schließe ich mich der Aussage von Manuel an (siehe SELFHTML Weblog)

Ein Script, das bewusst zukünftige Entwicklungen begrenzt,
  ist IMHO eine völlige Fehlplanung

Ich wollte mir schon mal eine E-Mail Adresse "@@@" machen, in der Hoffnung, dass darüber weniger Spam kommt, auch wenn ich die überall in allerlei Foren benutze ;-)

Allerdings habe ich es nicht geschafft, meinem Postfix beizubringen, diese E-Mail Adresse aus den MySQL-Tabellen auszulesen *g* Vielleicht weiß ja hier jemand, worauf ich dabei achten muss?

Viele Grüße,
  ~ Dennis.

[Tom]

Hello Dennis,

Allerdings habe ich es nicht geschafft, meinem Postfix beizubringen, diese E-Mail Adresse aus den MySQL-Tabellen auszulesen *g* Vielleicht weiß ja hier jemand, worauf ich dabei achten muss?

Solltest Du derjenige sein, der mir helfen kann, unseren Postfix zum laufen zu bringen?

• Postfix
• mit Postfox-MySQL
• Postfix-Admin
• Dovecot oder ein anderes POP3/IMAP-Paket
• Postgrey

Das wichtigste, was ich nun wohl vollkommen vergurkt habe, ist die Authentifizierung für Virtuelle Domains / User und Relaying...

Der Stapel mit dem (gelesenen) Papier auf dem Tisch wiegt bestimmt schon fünf Kilogramm.

Also am besten nochmal von vorne anfangen.
Alles wieder runterrupfen und apt-get nochmal quälen.
Ich würde dabei gerne vermeiden, in irgendeinem Modul patchen zu müssen.

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.

[Dennis]

Hi Tom,

Das wichtigste, was ich nun wohl vollkommen vergurkt habe, ist die Authentifizierung für Virtuelle Domains / User und Relaying...

Das funktioniert bei mir problemlos, allerdings nutze ich nicht Postfix-Admin, sondern eine Eigenlösung. Diese nutzt aber auch die MySQL-Anbindung von Postfix.

Ich würde dabei gerne vermeiden, in irgendeinem Modul patchen zu müssen.

Ich weiß ja nicht welche Linux Distribution du verwendest, aber unter Debian ist in dem Packet postfix-mysql die MySQL-Anbindung für Postfix enthalten.

Wo genau liegt denn dein Problem?

Viele Grüße,
  ~ Dennis.

[Tom]

Hello,

Wo genau liegt denn dein Problem?

...dass ich inzwischen nicht mehr nachvollziehen kann, was denn jetzt mit wem zusammen arbeitet und wie...

Ich habe Debian 4.0 auf dem Host und das von Dir erwähnte postfix-mysql einstalliert, aber leider erst, nachdem der Postfix-Admin installiert war.

Ich werde wohl alles wieder runterrupfen und ese dann nochmal "geordnet" einspielen...

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.

[Robert Bienert]

Moin!

Im Zuge von Anti-Spam Maßnahmen könnte ein Mailserver auf die Idee kommen zu prüfen, ob dein Server (welcher diese Mail verschickt) überhaupt berechtigt ist Mails von diesem Absender zu schicken. SPF wäre ein Beispiel für eine solche Technik.

Der empfangende Mailserver lehnt dann möglicherweise deine Mail ab, weil du die Mail unter dem Absender „[e-mail]” losgeschickt hast, jedoch dein Server nicht als solcher gelistet ist, welcher Mails von „example.org” verschicken darf.

Der Grund leuchtet mir sofort ein, vielen Dank für diesen Hinweis. So sicher und sinnvoll sollte das ganze dann schon sein.

Ein Script, das bewusst zukünftige Entwicklungen begrenzt,
  ist IMHO eine völlige Fehlplanung

Andererseits sieht es allerdings so aus, dass du zur (formalen) Validierung von Emailadressen eigentlich einen richtigen Parser schreiben musst. Nicht nur, dass dieser Aufwand für eine _bewusst kleine_ Skriptlösung in keinem Verhältnis dazu steht, nein, als Hacker könnte man sogar auf die Idee kommen, eine Emailadresse zu kreieren, die so lang und verschachtelt ist, dass der Server erst einmal eine Runde rechnen geht. Das kann ja auch nicht Sinn der Sache sein, oder?

Viele Grüße,
Robert