[PHP] Mail uniform versturen

[Verwijderd]

Ik heb een klein probleempje met het goed en uniform versturen van e-mails in PHP. Wanneer ik alles als plain/text verstuur komt het overal aan maar verschilt de whitespace per server, wanneer ik als HTML verstuur komt de e-mail niet op alle adressen aan en worden UTF of ISO tekens niet goed getoond in het onderwerp.

Ik ben wat aan het spelen gegaan, dus de code is wellicht niet helemaal zoals het hoort maar het geeft een beetje een impressie waar ik mee bezig ben.

De variabelen die verstuurd worden worden bij een HTML e-mail zoals hieronder 'gefilterd'. Het doel is om schadelijke tekens als quote en single quotes om te zetten. Gezien htmlentities slashes toevoegd worden deze weer weggehaald (nutteloos waarschijnlijk) en als laatste wordt nl2br gebruikt omdat htmlentities volgens mij de whitespace (behalve spaties) verwijderd.

PHP:

$onderwerp = nl2br(stripslashes(htmlentities($_POST['onderwerp'], ENT_QUOTES, 'iso-8859-1')));
$inhoud = nl2br(stripslashes(htmlentities($_POST['inhoud'], ENT_QUOTES, 'iso-8859-1')));

De headers zien er op dit moment zoals hieronder uit en spreken denk ik voor zich. Ik heb UTF-8 ipv iso overigens geprobeerd maar dan wordt er niets omgezet.

PHP:

$headers = "From: [e-mail] \r\n"; 
$headers .= "MIME-Version: 1.0\r\n"; 
$headers .= "Content-type: text/html; charset=iso-8859-1\r\n";

De mailfunctie ziet er als volgt uit:

PHP:

mail($emailadres, $onderwerpc, $inhoudc, $headers);

Een hoop vragen..

- Kan het zijn dat HTML e-mails eerder geweigerd worden of in een spamfilter belanden?
- Waarom wordt in het onderwerp niet de goede tekens getoond maar wel in de content? Een onderwerp ziet er bijvoorbeeld zo uit: " Test '
- Is het beter om plain/text te gebruiken wanneer je eigenlijk geen HTML code in de mail zelf gebruikt?
- Is er een manier om whitespace, zoals ingevoerd, bij plain text altijd hetzelfde te houden onafhankelijk van server en/of ontvanger?
- Is bovenstaande een goede manier om schadelijke tekens als quotes te filteren? Of zou een preg_replace beter zijn? Zo ja welke tekens zou ik dan moeten omzetten?

Het gaat niet om een specifiek script maar het zijn wat vragen waar ik niet echt of juist tegenstrijdige antwoorden op kan vinden.

[drm]

Een hoop vragen..
- Kan het zijn dat HTML e-mails eerder geweigerd worden of in een spamfilter belanden?

Ja. HTML wordt vaak in spam gebruikt en daarmee wordt de kans dat een emailtje spam is groter als het HTML bevat. (Zo "redeneert" een spamfilter)

- Waarom wordt in het onderwerp niet de goede tekens getoond maar wel in de content? Een onderwerp ziet er bijvoorbeeld zo uit: " Test '

Ik vermoed dat dat te maken heeft met het feit dat er voor de body van een mail wel een content-encoding meegegeven wordt maar voor de headers niet. Ik zou eigenlijk niet weten hoe je dat op moet lossen, maar ik zou je aanraden daarvoor eens de SMTP RFC na te lezen (http://www.ietf.org/rfc/rfc0821.txt)

- Is het beter om plain/text te gebruiken wanneer je eigenlijk geen HTML code in de mail zelf gebruikt?

Ja, voor zover alles wat je wilt ook mogelijk is met plain text, natuurlijk

- Is er een manier om whitespace, zoals ingevoerd, bij plain text altijd hetzelfde te houden onafhankelijk van server en/of ontvanger?

Nee. Simpelweg vanwege het feit dat eindgebruikers vaak een client gebruiken die mails niet in fixed-width fonts weergeven. Ik neem aan dat de reden dat je het vraagt is omdat je zaken uit wilt lijnen?

- Is bovenstaande een goede manier om schadelijke tekens als quotes te filteren? Of zou een preg_replace beter zijn? Zo ja welke tekens zou ik dan moeten omzetten?

Doet het wat het moet doen? Of doet het net iets meer of net iets minder?

[Janoz]

...Gezien htmlentities slashes toevoegd...

Dit is niet waar. De slashes staan er waarschijnlijk al in omdat de magic_slashes_ding aanstaat.

....en als laatste wordt nl2br gebruikt omdat htmlentities volgens mij de whitespace (behalve spaties) verwijderd......

Ook niet waar. Kijk maar eens in de source van je mail. Het is juist een eigenschap van HTML dat alle whitespace (newlines en spaties) gewoon als 1 spatie wordt geinterpreteerd. Het enige dat nl2br doet is het toevoegen van <br /> tags op plekken waarin de input een newline heeft.

Tot slot vind ik het vreemd dat je dit allemaal ook met je onderwerp doet. Sowieso ondersteund het onderwerp helemaal geen html en regelovergangen zitten er al helemaal niet in.

[Verwijderd]

DRM >

Ik zal je link eens doorlezen, bedankt daarvoor.
Ik wil overigens niet echt iets uitlijnen, het gaat er alleen om dat de newlines een beetje kloppen. Dit verschilt klaarblijkelijk per server want hetzelfde script geeft bij de ene server een email waarin alles aan elkaar zit, bij de ander exact zoals het hoort en weer bij een ander worden de newlines verdubbeld. Bij de een staat dus alles aan elkaar alsof er nooit enters gebruikt zijn terwijl bij de ander er overal gaten van twee enters staan.

Janoz >

Magic_quotes staat idd aan.. Bij pain text werd er niets ge-escaped dus ben ik er vanuit gegaan dat het af stond en htmlentities het toevoegde.

Het is idd vreemd om functies als nl2br() te gebruiken bij het onderwerp. Gezien het continue niet goed aankwam tijdens het testen heb ik de functies van inhoud even gebruikt, puur om te testen eigenlijk. Ik wist niet dat het onderwerp overigens geen HTML ondersteund, is wel logisch eigenlijk.. Ik ga voor het onderwerp maar gewoon preg_replace met een array van wat allemaal niet is toegestaan gebruiken om het om te zetten.

[drm]

Als het puur om newlines gaat moet je gewoon zorgen dat de mail die je verstuurt geen \r characters bevat voor de \n characters. Vaak is het zo dat als je op windows je code schrijft dat de newlines die daar in staan (of bijvoorbeeld in de database) in een windows ascii formaat zitten waardoor alle newlines als CRLF (carriage return + line feed) characters opgeslagen worden. Sommige mailservers interpreteren een CR ook als LF en krijg je dus twee newlines. M.a.w.:

PHP:

$str = str_replace ( "\r\n", "\n", $str );

Het klopt overigens niet, want volgens de RFC horen newlines met \r\n genoteerd te worden, maar het is een (bij mij) bekend verschijnsel dat dat problemen oplevert.