[php] Zend_Mail encoding

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik heb wat hulp nodig met het onderstaande.

Als vanuit een bepaalde server een mail wordt gestuurd via Zend_Mail dan komt deze bij mij prima aan maar niet bij de klant op een exchange omgeving met outlook 2007. Daar zien ze de mail in plain text waarbij ze de headers van de mail ook zien. Ontvangen ze de mail met bijvoorbeeld gmail, dan is er niks aan de hand.
Tevens komen mails verstuurd van deze server ook bij sommige andere mensen verkeerd aan volgens de klant alleen is dit nog niet bevestigd.

Als ik exact hetzelfde stukje code vanaf onze ontwikkelomgeving uitvoer, dan komt de mail zowel bij ons als bij de klant goed aan.

Het lijkt dus een server probleem te zijn icm exchange. Het verschil tussen onze en de externe server is in ieder geval de PHP versie. Hij wordt niet goed verstuurd in php 5.3.1 en wél in php 5.2.10. Ik vermoed niet dat daarin het probleem zit maar het is misschien de moeite waard te vermelden.

Het stukje wat uitgevoerd wordt is (de '=' tekens heb ik bewust in de body gezet):
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
$mail = new Zend_Mail('utf-8');
$mail->setBodyHtml('
Curabitur id hendrerit orci! Nulla facilisi. Maecenas
pulvinar sollicitudin tellus = tellus, ut faucibus nisi = faucibus venenatis ut. Pellentesque lectus dui, lobortis quis
pellentesque vitae, egestas eu nulla. Integer nisl lacus, facilisis ut venenatis ut, sodales at ipsum. Morbi sit amet sapien diam.
Nunc eget leo a erat mollis gravida eu sed neque.
');
$mail->setBodyText('No support');
$mail->setFrom( 'XXX'  );
$mail->setReturnPath( 'XXX'  );
$mail->addTo('XXX');
$mail->setSubject( 'Test mail: ' . date('d-m-Y H:i') );
$mail->send();

Hij komt als volgt aan bij de klant (dit is dus niet de bron maar hij komt daadwerkelijk zo aan). Extra headers heb ik even weggelaten:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
From: XXX
Date: Wed, 30 Mar 2011 16:44:29 +0200
Content-Type: multipart/alternative;
 boundary="=_7c8be784507fb83bb008b973af88140a"
MIME-Version: 1.0
Message-Id: <20110330144429.EB8277451A@XXX>

--=_7c8be784507fb83bb008b973af88140a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

No support

--=_7c8be784507fb83bb008b973af88140a
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0A        Curabitur id hendrerit orci! Nulla facilisi. Maecenas=0A    =
    pulvinar sollicitudin tellus =3D tellus, ut faucibus nisi =3D faucib=
us venenatis ut. Pellentesque lectus dui, lobortis quis=0A        pellen=
tesque vitae, egestas eu nulla. Integer nisl lacus, facilisis ut venenat=
is ut, sodales at ipsum. Morbi sit amet sapien diam.=0A        Nunc eget=
 leo a erat mollis gravida eu sed neque.=0A

--=_7c8be784507fb83bb008b973af88140a--

Iemand suggesties?

Acties:
  • 0 Henk 'm!

  • zwippie
  • Registratie: Mei 2003
  • Niet online

zwippie

Electrons at work

Misschien staat er in dit bugreport wat nuttigs. Welke vorm van mailtransport gebruik je eigenlijk (sendmail/smtp/...)?

How much can you compute with the "ultimate laptop" with 1 kg of mass and 1 liter of volume? Answer: not more than 10^51 operations per second on not more than 10^32 bits.


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik heb die regel zojuist even weggehaald. Het is even afwachten op reactie aangezien ik het probleem zelf niet kan constateren.
Onderliggend wordt gewoon de mail() functie gebruikt, de transport is dus Sendmail geloof ik.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Zojuist reactie gehad maar zonder positief resultaat.

Ik heb overigens ook base64 als encoding geprobeerd ipv quoted printable maar ook dat zonder resultaat.

Acties:
  • 0 Henk 'm!

  • stappel_
  • Registratie: Augustus 2000
  • Laatst online: 26-04 17:39
ik weet niet of dit helpt maar wij hadden laatst ook last van lege emails met php na een upgrade naar een nieuwe omgeving. We gebruiken geen Zend maar misschien help het wel. Het probleem was bij ons de newline tekens. Deze stonden op \r\n en gaven dan problemen met de postfix mta en de exchange omgeving. emails in gmail zagen er prima uit. toen alles overgezet naar \n en het werkte met exchange ook prima. Dat gelde voor de gehele message, dus ook voor de headers (het probleem was dat er te veel line breaks stonden tussen de mime parts leek het)

[ Voor 15% gewijzigd door stappel_ op 31-03-2011 15:10 ]

Ubero: #2, Euler: #1, GOT: #1, Des: #1, Zeta: #1, Eon: #3, OGR-24: #3, OGR-25: #7,
LM: #7, AP: #5, DF: #19, D2OL: #37, SOB: #50, TSC: #63, RC5: #96


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik heb net even de line endings bekeken maar deze staan in het gehele bericht op \n. Zowel op de server waar vandaan het fout gaat als op de server waarop het goed gaat.
Wellicht overbodig maar voordat de mail functie uitgevoerd worden zijn dit de gevar_dumpte params ($to, $subject, $message, $headers). Ik zie er geen problemen in maar ik weet er dan ook niet genoeg vanaf:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
string(12) "XXX"
string(27) "Test mail: 01-04-2011 09:24"
string(693) "--=_80699b71e6d36da7e827f9457db59563
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

No support

--=_80699b71e6d36da7e827f9457db59563
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Curabitur id hendrerit orci! Nulla facilisi. Maecenas=0A        pulvinar=
 sollicitudin tellus =3D tellus, ut faucibus nisi =3D faucibus venenatis=
 ut. Pellentesque lectus dui, lobortis quis=0A        pellentesque vitae=
, egestas eu nulla. Integer nisl lacus, facilisis ut venenatis ut, sodal=
es at ipsum. Morbi sit amet sapien diam.=0A        Nunc eget leo a erat=
 mollis gravida eu sed neque.

--=_80699b71e6d36da7e827f9457db59563--"
string(184) "From: XXX
Return-Path: XXX
Date: Fri, 01 Apr 2011 09:24:31 +0200
Content-Type: multipart/alternative;
 boundary="=_80699b71e6d36da7e827f9457db59563"
MIME-Version: 1.0"
Pagina: 1