Wegvallen van inhoud bij versturen nieuwsbrief

[Anoniem: 411726]

Ik ben recent begonnen met versturen van een nieuwsbrief via een eigen geschreven php script. Probleem is dat bij een enkeling de inhoud slechts gedeeltelijk getoond word. Vooralsnog kan ik geen patroon ontdekken waarom dat gebeurt. Deze nieuwsbrief wordt verstuurd naar >1000 personen. De opzet van het script is zeer simpel en standaard mijn inziens.

1. Het mail script haalt gebruikers op uit de Mysql database (150 per keer). De cronjob voor het versturen loopt */2
2. vervolgens lees ik de content in middels 'file_get_contents'. De inhoud van de nieuwsbrief is al eerder weggeschreven naar een html file die dus ingelezen wordt.
3. Met het mail commando van PHP worden vervolgens de nieuwsbrieven verstuurd

$headers = "From: xxx <[e-mail]> \r\n";
$headers .= "MIME-Version: 1.0 \r\n";
$headers .= "Content-Type: text/html; charset=utf-8 \r\n";

// Mail
mail("$naam <".$email.">", $subject, $content, $headers);

Mis ik iets? Alvast bedankt voor de eventuele hulp.

[Kuhlie]

Kan je een van die mensen die maar een deel krijgen vragen of ze je de source van de mail kunnen eeh mailen?

[Anoniem: 411726]

Was ik net van plan, maar ben benieuwd of ze deze bewaard hebben (zijn 'gewone' mensen)

[juiced01]

"Gewone" mensen bewaren inderdaad geen mail Kan het zijn dat je een lange regel HTML hebt? Kan gebeuren dat een hele lange lap code wordt afgebroken.

[Anoniem: 411726]

juiced01 schreef op dinsdag 21 juni 2011 @ 11:26:
"Gewone" mensen bewaren inderdaad geen mail Kan het zijn dat je een lange regel HTML hebt? Kan gebeuren dat een hele lange lap code wordt afgebroken.

De inhoud is 24.4 kb groot. Dat valt toch mee? Maar het vreemde is dat diezelfde email wel correct zichtbaar is door mijzelf in Gmail, Hotmail en Yahoo mail. Deze abonnee heeft een @home adres. Zou @home er iets mee doen?

[The Lord]

Plaatjes e.d. moet je embedden als alternative.

En je zal je moeten verdiepen in welke client wat wel en wat niet ondersteunt. De 1 stript CSS, de ander juist embedded styles.

Ik kan je uit eigen ervaring vertellen dat hier heel erg veel werk in gaat zitten als je een brede selectie aan ontvangers hebt. En 1 html als bron gebruiken is erg lastig aangezien sommige clients een totaal andere opmaak vereisen om het er enigzins uit te laten zien zoals bedoeld.

Nog een tip: vergeet niet ook een echte tekst versie mee te sturen. Dat is wel zo lief voor mensen met weinig bandbreedte, met instelling om slechts een deel van bericht binnen te halen of een client die geen HTML ondersteunt.

[kKaltUu]

Anoniem: 411726 schreef op dinsdag 21 juni 2011 @ 11:32:
[...]

De inhoud is 24.4 kb groot. Dat valt toch mee? Maar het vreemde is dat diezelfde email wel correct zichtbaar is door mijzelf in Gmail, Hotmail en Yahoo mail. Deze abonnee heeft een @home adres. Zou @home er iets mee doen?

Kunnen altijd extra headers toegevoegd zijn, laat ze het mailtje als bijlage toevoegen en pluk het uit elkaar. Ik heb ook mail heel netjes in Gmail gekregen, maar als het door ME en Exchange is geweest dat de headers er gewoon uitlopen. (HTML mail btw).

[Anoniem: 411726]

The Lord schreef op dinsdag 21 juni 2011 @ 11:35:
Plaatjes e.d. moet je embedden als alternative.

En je zal je moeten verdiepen in welke client wat wel en wat niet ondersteunt. De 1 stript CSS, de ander juist embedded styles.

Ik kan je uit eigen ervaring vertellen dat hier heel erg veel werk in gaat zitten als je een brede selectie aan ontvangers hebt. En 1 html als bron gebruiken is erg lastig aangezien sommige clients een totaal andere opmaak vereisen om het er enigzins uit te laten zien zoals bedoeld.

Nog een tip: vergeet niet ook een echte tekst versie mee te sturen. Dat is wel zo lief voor mensen met weinig bandbreedte, met instelling om slechts een deel van bericht binnen te halen of een client die geen HTML ondersteunt.

Tja... ik had al vermoedens in die richting. Ik heb de HTML super-standaard gehouden maar zelfs dat kan inderdaad wel eens niet genoeg zijn. Maar wat bedoej je met 'vergeet niet ook een echte tekst versie mee te sturen'?

[Creepy]

Je zal een multipart mail moeten maken met een HTML deel en een platte tekst deel. Zo kunnen ontvangers die geen HTML willen of kunnen ontvangen toch de inhoud lezen.

Een hoop e-mail clients houden zich simpelweg niet aan de standaard of strippen een heleboel. Externe CSS is een absolute no-go en je ziet vaak al dat style tags worden verwijderd of zelfs alles in de head tag wordt gestript. Dit verschilt ook nog eens per e-mail client . Vaak is het genoeg om alle styling in style attributen op te nemen maar zelfs dan kan je nog wel eens voor verassingen komen te staan.

[kKaltUu]

Of je doet heel ranzig en laat je nieuwsbrief omzetten naar afbeeldingen, embed ze met een cid link naar elke afbeelding. Weet je zeker dat je klanten de afbeeldingen krijgen te zien

[Anoniem: 96523]

Ik ben bang dat met de summiere informatie over wat er exact word verzonden en exact wordt ontvangen, we weinig hulp kunnen bieden.

Daarnaast kan ik nu al een tiental dingen noemen die missen of die fout kunnen zijn... Daarom wil ik aanraden om een te kijken naar PHPMailer; een handige class om je mail mee te versturen. Scheelt een hoop kopzorgen bij het genereren van de juiste headers en inhoud van de daadwerkelijke e-mail.

En lees je goed in over HTML mailings (wat wel en niet kan):
- http://mailchimp.com/resources/
- http://www.campaignmonitor.com/resources/

kKaltUu schreef op dinsdag 21 juni 2011 @ 12:01:
Of je doet heel ranzig en laat je nieuwsbrief omzetten naar afbeeldingen, embed ze met een cid link naar elke afbeelding. Weet je zeker dat je klanten de afbeeldingen krijgen te zien

En dan weet je ook zeker dat je niet door spamfilters heen komt en binnen de kortste keren op een blacklist staat...

[Voor 24% gewijzigd door Anoniem: 96523 op 21-06-2011 12:04]

[TJHeuvel]

Weet je welke mailclients deze 'gewone' mensen gebruiken?

[Anoniem: 411726]

CyCloneNL schreef op dinsdag 21 juni 2011 @ 12:59:
Weet je welke mailclients deze 'gewone' mensen gebruiken?

Ik wacht nog op antwoord.

[Anoniem: 411726]

Anoniem: 96523 schreef op dinsdag 21 juni 2011 @ 12:03:
Ik ben bang dat met de summiere informatie over wat er exact word verzonden en exact wordt ontvangen, we weinig hulp kunnen bieden.

Daarnaast kan ik nu al een tiental dingen noemen die missen of die fout kunnen zijn... Daarom wil ik aanraden om een te kijken naar PHPMailer; een handige class om je mail mee te versturen. Scheelt een hoop kopzorgen bij het genereren van de juiste headers en inhoud van de daadwerkelijke e-mail.

En lees je goed in over HTML mailings (wat wel en niet kan):
- http://mailchimp.com/resources/
- http://www.campaignmonitor.com/resources/


[...]

En dan weet je ook zeker dat je niet door spamfilters heen komt en binnen de kortste keren op een blacklist staat...

Zeer nuttig allemaal. Thansk voor de info.

[FragFrog]

Anoniem: 411726 schreef op dinsdag 21 juni 2011 @ 11:32:
De inhoud is 24.4 kb groot. Dat valt toch mee?

Aangezien we toch aan het gokken zijn: zitten er wel linebreaks in die content? Zelf wel eens gehad met een nieuwsbrief (vnl ook richting @home adressen) dat linebreaks weg waren in een HTML mail en alles na de eerste X karakters weggegooid werd. RFC5322 specificeerd iets dergelijks ook.

Een degelijke mail library zou dat trouwens ook moeten oppikken

[Anoniem: 411726]

FragFrog schreef op dinsdag 21 juni 2011 @ 13:23:
[...]

Aangezien we toch aan het gokken zijn: zitten er wel linebreaks in die content? Zelf wel eens gehad met een nieuwsbrief (vnl ook richting @home adressen) dat linebreaks weg waren in een HTML mail en alles na de eerste X karakters weggegooid werd. RFC5322 specificeerd iets dergelijks ook.

Een degelijke mail library zou dat trouwens ook moeten oppikken

mmm...dat klinkt als een mogelijkheid. Ik gebruik nu alleen maar <br> maar jij zegt gebruik ook \n ?

[FragFrog]

Mits die er niet in zitten? Ja. In mijn situatie kwam het door TinyMCE's HTML generator (gebruikers kunnen een opgemaakte nieuwsbrief versturen) die zoveel &nbsp;'s achter elkaar plempte dat er regels van duizenden tekens tussenzaten. Op het punt waar voor het eerst de limiet overschreden werd waren de mailtjes afgekapt. En doordat dit probleem deels server-afhankelijk is ging het bij sommige gebruikers wel goed en bij anderen niet, raar maar waar

[Anoniem: 96523]

FragFrog schreef op dinsdag 21 juni 2011 @ 16:28:
Mits die er niet in zitten? Ja. In mijn situatie kwam het door TinyMCE's HTML generator (gebruikers kunnen een opgemaakte nieuwsbrief versturen) die zoveel &nbsp;'s achter elkaar plempte dat er regels van duizenden tekens tussenzaten. Op het punt waar voor het eerst de limiet overschreden werd waren de mailtjes afgekapt. En doordat dit probleem deels server-afhankelijk is ging het bij sommige gebruikers wel goed en bij anderen niet, raar maar waar

Hier heb ik ook last van gehad.

Wanneer een e-mail wordt verstuurd gebeurd dit middels een bepaalde standaard die aangeeft dat een regel maximaal een x aantal karakters heeft.

There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

Normaal gesproken is dit geen probleem, omdat spaties e.d. standaard worden omgezet naar linebreaks.

In mij geval had ik erg lange URI's (ivm externe afbeeldingen en tracken van clicks), waardoor deze halverwege werd afgebroken en dus de e-mail stopte. De HTML klopte wel, maar de mailclient kon er niets mee.


Dit is dus ook de reden waarom in PHPMailer aanraad, omdat deze automatisch dit soort problemen voor je oplost.

[Anoniem: 411726]

Thanks guys! Ik ga met alle tips aan de slag.

[raptorix]

Wij hebben laatst Campagne monitor ingezet, echt supergoede service, mailings worden vaak beetje onderschat, tenzij je heel goed weet waar je mee bezig bent loont het om dit zelf te gaan doen.

[Anoniem: 411726]

Ter info voor wie na mij komen. Het programma waar het mis ging was Windows Live Mail en na toevoegen van regelmatig een \n\n in de code is het nu helemaal goed :-)