[PHP] mail body incorrect bij ontvanger

[Pascal Saul]

Ik heb, denk ik, een redelijk bekend mail-probleem.

In de body verzend ik

code:

UNA:+.? 'UNB+UNOA:2+XXXXX+YYYYY+061128:1226+20061128122621'UNH+1+IFTSTA:D:96A:UN'BGM+701'DTM+137:20061128:102'NAD+CS+LUCAS::ZZZ'CNI+1'STS++27'GID+1+1'PCI+1'GIN+VV+WDB9066531S139891'CNI+1'STS++27'GID+1+1'PCI+1'GIN+VV+WDB9066331S140006'CNI+1'STS++27'GID+1+1'PCI+1'GIN+VV+WDB9066331S139422'UNT+20+1'UNZ+1+20061128122621'

maar wordt als

code:

UNA:+.? 'UNB+UNOA:2+XXXXX+YYYYY+061128:1226+20061128122621'UN=
H+1+IFTSTA:D:96A:UN'BGM+701'DTM+137:20061128:102'NAD+CS+LUCAS::ZZZ'CNI+1=
'STS++27'GID+1+1'PCI+1'GIN+VV+WDB9066531S139891'CNI+1'STS++27'GID+1+1'PC=
I+1'GIN+VV+WDB9066331S140006'CNI+1'STS++27'GID+1+1'PCI+1'GIN+VV+WDB90663=
31S139422'UNT+20+1'UNZ+1+20061128122621'

ontvangen.

Ik heb al een wordwrap toegepast op 75 teken maar dat mocht niet baten.

Volgens de RFC mag een woord maximaal x aantal tekens lang zijn maar wordt nogal eens verkeer geimplementeerd. Nu is het geval dat bij de ontvanger het wel volgens de RFC is geimplementeerd. Hoe kan ik er nu voor zorgen dat die vervelend = tekens niet in de body gezet gaan worden. Ik heb ook al gelezen dat met de encoding "quoted-printable encoding" het automatisch naar zoveel tekens wordt afgebroken maar gebeurt niet geloof ik.

Wanneer ik mezelf mail zie ik het volgende in de headers.

code:

Content-Type: text/plain;
    charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Ik maak gebruik van xpertmailer.

[ Voor 9% gewijzigd door Pascal Saul op 29-11-2006 12:21 ]

[Creepy]

Misschien testen dan?
Snel je bericht aanpassen dat je het al hebt gestet he?

Daarnaast heb je nog een probleem dat de client kant er ook voor kan kiezen om zomaar woorden af te breken op bijv de ' of +. Dit is echt mail client afhankelijk. Als je zelf de mail opvist zal dat geen probleem zijn.

Daarnaast zou je ook nog kunnen problemen om i.p.v. plain text er een mime-part van te maken die je dan bijv. base64 encode. Zo kan je dus prima 75 tekens per regel kwijt en met het ophalen van het mime-part en vervolgens base64 decoden wordt alles weer achter elkaar geplakt. Een binary attachment wordt bijv. ook op deze manier verstuurd.

Als laatste lijkt het me ook niet z'n probleem om elke =<regel einde> eruit te filteren.

[ Voor 16% gewijzigd door Creepy op 29-11-2006 12:25 ]

[Pascal Saul]

Creepy schreef op woensdag 29 november 2006 @ 12:22:
Misschien testen dan?
Snel je bericht aanpassen dat je het al hebt gestet he?

Daarnaast heb je nog een probleem dat de client kant er ook voor kan kiezen om zomaar woorden af te breken op bijv de ' of +. Dit is echt mail client afhankelijk. Als je zelf de mail opvist zal dat geen probleem zijn.

Daarnaast zou je ook nog kunnen problemen om i.p.v. plain text er een mime-part van te maken die je dan bijv. base64 encode. Zo kan je dus prima 75 tekens per regel kwijt en met het ophalen van het mime-part en vervolgens base64 decoden wordt alles weer achter elkaar geplakt. Een binary attachment wordt bijv. ook op deze manier verstuurd.

Als laatste lijkt het me ook niet z'n probleem om elke =<regel einde> eruit te filteren.

Als ik er een mimepart van zou maken. Wie zegt mij dat de ontvanger dit decode?


Als laatste lijkt het me ook niet z'n probleem om elke =<regel einde> eruit te filteren.

Jawel, de ontvanger gaat niet zijn code aanpassen om het aan mijn zin te laten voldoen
Het is al bewezen dat het werkt en ik ben nieuw dus zal het dan zelf moeten oplossen....

[Osiris]

Misschien handig om te vertellen wát de ontvanger is? Is 't een normale mail-client of is het een geautomatiseerd scriptje of iets dergelijks?

Probeer anders eens handmatig een "Content-Transfer-Encoding: 7bit"-header erin te proppen? Wellicht dat de MTA dan met z'n klauwen van je mail af blijft.

[GX]

de =<regel einde> is gewoon een linewrap-escape-character welke bij veel mailclients automatisch gebruikt word. Een simpele s/=(\n|\r)//g is voldoende, en ieder normaal mailprogramma moet daar rekening mee houden..

[Pascal Saul]

Osiris schreef op woensdag 29 november 2006 @ 12:33:
Misschien handig om te vertellen wát de ontvanger is? Is 't een normale mail-client of is het een geautomatiseerd scriptje of iets dergelijks?

Probeer anders eens handmatig een "Content-Transfer-Encoding: 7bit"-header erin te proppen? Wellicht dat de MTA dan met z'n klauwen van je mail af blijft.

Het heeft al wel effect in mijn eigen mail client. Nu wordt alles afgekapt, zonder een = teken

Hopelijk gaat het nu ook goed aan de andere kant....

Het zijn berichten die van/naar een X400-netwerk afkomen/gaan.

Inmiddels een bericht terug:
"the file from today 12:42 is right! Fuer Rueckfragen stehen wir gerne zur Verfuegung."

Bedankt allen!

[ Voor 9% gewijzigd door Pascal Saul op 29-11-2006 13:13 ]

[Osiris]

Wat heeft effect, de '7bit' CTE-header? Want in dat geval moet je dus wel oppassen dat je géén 8-bit, maar ook daadwerkelijk 7 bit ASCII gaat versturen, dus met het msb van de 8 bitjes niet geset. Althans... Dat lijkt me logisch, aangezien dat nou eenmaal volgens de RFC's moet ofzo, stomme mailservers Overigens ondersteunen veel mailservers ook wel de 8-bit CTE. Zie ook MIME: Content-Transfer-Encoding op Wikipedia.

Géén idee wat er gebeurt als je toch lekker extended ASCII (ISO-8859-1 bijv) gebruikt, maar 't "mag" niet ofzo