PHPhulp.nl
35k+ leden Over PHPhulp Offerte opdracht Contact

Email bijlage onder windows test server ok maar onder linux fout

Door Rene Wennekes op 14-01-2014 16:31 gewijzigd op 14-01-2014 16:32
4.151 views
Hallo,

ik heb een php script waarbij een pdf als e-mail bijlage moet worden verstuurd. Dit lukt 100% goed op mijn windows test server (IIS).
Maar zodra ik hetzelfde wil doen op een linux webserver (RaspberryPI) met Apache dan krijg ik de mail met heleboel tekens in de mail.

Ik zal de hele pagina besparen en alleen de mail routine vermelden.

<?php
// email fields: to, from, subject, and so on
$message = $bericht;
$from_name = "factuur ".$invoice_number;
$header = "From: ".$from_name." <".$email_from.">\r\n";

// boundary
$semi_rand = md5(time());
$mime_boundary = "==Multipart_Boundary_x{$semi_rand}x";
$header .= "\nMIME-Version: 1.0\n" . "Content-Type: multipart/mixed;\n" . " boundary=\"{$mime_boundary}\"";

// multipart boundary
$message = "This is a multi-part message in MIME format.\n\n" . "--{$mime_boundary}\n" . "Content-Type: text/plain; charset=\"iso-8859-1\"\n" . "Content-Transfer-Encoding: 7bit\n\n" . $message . "\n\n";
$message .= "--{$mime_boundary}\n";

// preparing attachments
$data = chunk_split(base64_encode(file_get_contents($attach_file)));
$message .= "Content-Type: {\"application/octet-stream\"};\n name=\"".$invoice_number.".pdf\"\nContent-Disposition: attachment;\n filename=\"".$invoice_number.".pdf\"\nContent-Transfer-Encoding: base64\n\n" . $data . "\n\n";
$message .= "--{$mime_boundary}\n";

if(mail($email_invoice, "$subject", $message, $header)) {
print "<tr><td colspan='2'><br />You will receive a invoice email.</td></tr>\n";
} else {
print "<tr><td colspan='2'><br />There is a error sending the invoice email.</td></tr>\n";
}
?>
E
Erwin H
14-01-2014 16:38 gewijzigd op 14-01-2014 16:38
Ik maak me sterk dat deze headers niet in orde zijn en dat je daar het probleem moet zoeken:

<?php
$message .= "Content-Type: {\"application/octet-stream\"};"
?>
Ivo P
14-01-2014 16:38
zo te zien scheid jij de header-regels middels \n, de meeste dan, want de FROM doe je wel met \r\n

Volgens http://php.net/mail moet dat \r\n zijn.
Kan zijn dat de ene mailserver daar wat strikter in is dan de andere.
Rene Wennekes
14-01-2014 17:00
ok ik heb de \r eronder gezet maar heeft helaas geen effect.

hieronder stukje van een mail.

--==Multipart_Boundary_x67c03b52b3483efd1250df9d979e2d98x
Content-Type: {"application/octet-stream"};

name="VAC14.pdf"
Content-Disposition: attachment;
filename="VAC14.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjMKMyAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMSAwIFIKL1Jlc291cmNlcyAy
etc. etc. etc.
Rene Wennekes
15-01-2014 00:09
Als ik van beide mails in outlook de bericht opties bekijk is het verschil dat deze regels

MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="==Multipart_Boundary_x3e13df8c34981cf8b3fc9355c1958368x"

bij de werkende mail in de bericht-opties staat en bij de andere staatie in het bericht zelf ...

even nogmaals; beide php(-bestanden) zijn gelijk.
- SanThe -
15-01-2014 00:40
Maak van al die \n en \n\n eens gewoon \r\n
Ivo P
15-01-2014 09:09
$message .= "--{$mime_boundary}\n";

Dat is een niet zo heel vaak gebruikte optie om

$message .= "--$mime_boundary\n";
of
$message .= "--".$mime_boundary."\n";

te bereiken.
Dat kan.

Maar op regel 18

$message .= "Content-Type: {\"application/octet-stream\"};\n nam

ik neem aan dat je daar van een variable voor het content-type naar een hardcoded versie bent gegaan en de { } hebt laten staan?
Rene Wennekes
15-01-2014 10:40
Met of zonder {} probleem blijft hetzelfde.

SAN: de \r\n\ heb ik enkele reacties geleden aangespast maar hielp ook niet.

Lees voorgaande reakties.

Gek is dat alleen

<?php
$header .= "\nMIME-Version: 1.0\r\nContent-Type: multipart/mixed;\r\n boundary=\"{$mime_boundary}\"";
?>

de uitvoer onder de raspberrypi zich in de mail zelf terechtkomt.

Is het gebruik van . of spatie voor de \r\n van belang?


Rene
Ivo P
15-01-2014 10:46
ook die regel begint met \n dus zonder \r

Ik zou aan willen raden, om de headers 1 voor 1 op te nemen als:

$header .= 'een of andere header' . "\r\n";
$header .= 'een andere header' . "\r\n";

En dus niet met \n of \r\n halverwege

en ook niet beginnen met een enter.

Je voegt namelijk eerst een from header toe (regel 5) die afgesloten wordt met een enter, en daarna op regel 10 doe je nog een soort van enter.

Maar een mail bericht sluit de headers af middels een dubbele enter. Zeg maar een witregel tussen de headers en de mail content.

Als nu jouw linux mail server die \n wel als enter ziet, dan zit er dus een dubbele enter na de from-header en is de rest content van de mail.



[size=xsmall]Toevoeging op 15/01/2014 10:48:08:[/size]

andere tip:
als een mail meer is dan je simpelweg in 2 regels + mail() kwijt kunt, is het vaak veel eenvoudiger om PHPMailer of Swiftmailer te gebruiken.

Dat pakket is uitgebreid getest met bergen opties. Die zal automagisch een hoop van de headers regelen, zelf de juiste enters op de juiste plek zetten en controles doen op de invoer (is het een mailadres bijvoorbeeld)
Rene Wennekes
15-01-2014 12:08
Uit php.net

Note that there is a big difference between the behavior of this function on Windows systems vs. UNIX systems. On Windows it delivers directly to an SMTP server, while on a UNIX system it uses a local command to hand off to the system's own MTA.

The upshot of all this is that on a Windows system your message and headers must use the standard line endings \r\n as prescribed by the email specs. On a UNIX system the MTA's "sendmail" interface assumes that recieved data will use UNIX line endings and will turn any \n to \r\n, so you must supply only \n to mail() on a UNIX system to avoid the MTA hypercorrecting to \r\r\n.

If you use plain old \n on a Windows system, some MTAs will get a little upset. qmail in particular will refuse outright to accept any message that has a lonely \n without an accompanying \r.

Reageren

Inloggen om te reageren