Environment: Claws Mail 3.9.1, PHP 5.4.16, Phpmailer 5.2.6 c5e9f7873f
Phenomenon: Phpmailer send mail with attachments, use AddAttachment () method directly
$mailer->addattachment ($attach _file);
There are no more settings. Claws Mail receives the letter, the view message content is blank, the attachment column displays:
message/rfc822
Multipart/mixed
The following is blank. And can normally identify the attachment of the message, the contents of the attachment column is generally:
message/rfc822
Multipart/mixed
Text/plain
Text/html (This is the MIME type of the attachment)
It is normal for Gmail and mutt to recognize such messages.
Analysis: By comparing normal and abnormal message source code, found that an abnormal message in the declaration content is a section, a number of transmission code statements, such as:
content-type:multipart/mixed;
boundary= "B1_95A848B14CB4385965320B915D5829DD"
Content-transfer-encoding:base64
The final content-transfer-encoding is a line more than normal mail.
Because this part of the message's original code is used only to declare that the subsequent mail is composed of multiple parts and defines the identification boundaries of each part boundary, there is no actual content, so it should be unnecessary to declare the encoding type. The relevant code in Phpmailer is:
Public Function Getmailmime () {
$result = ';
Switch ($this->message_type) {
Case ' inline ':
$result. = $this->headerline (' Content-type ', ' multipart/related; ');
$result. = $this->textline ("tboundary=" ". $this->boundary[1]." ");
Break
Case ' Attach ':
Case ' Inline_attach ':
Case ' Alt_attach ':
Case ' Alt_inline_attach ':
$result. = $this->headerline (' Content-type ', ' multipart/mixed; ');
$result. = $this->textline ("tboundary=" ". $this->boundary[1]." ");
Break
Case ' Alt ':
Case ' Alt_inline ':
$result. = $this->headerline (' Content-type ', ' multipart/alternative; ');
$result. = $this->textline ("tboundary=" ". $this->boundary[1]." ");
Break
Default
Catches case ' plain ': and Case ':
$result. = $this->textline (' Content-type: '. $this->contenttype. '; charset= '. $this->charset);
Break
}
RFC1341 Part 5 says 7bit are assumed if not specified
if ($this->encoding!= ' 7bit ') {
$result. = $this->headerline (' content-transfer-encoding ', $this->encoding);
}
This statement has been deliberately added because the Rfc1341,7bit encoding type is the default.
Solution: Maybe the problem is on claws Mail, but I can only modify Phpmailer to adapt to this problem for the time being. After the above question is clear, the transfer encoding declaration is not added after multipart:
RFC1341 Part 5 says 7bit are assumed if not specified
Not after multipart/mixed, Claws-mail would not recoginize attachment
if ($this->encoding!= ' 7bit ') &&!in_array ($this->message_type, Array (
' Attach ',
' Inline_attach ',
' Alt_attach ',
' Alt_inline_attach ',
)))) {
$result. = $this->headerline (' content-transfer-encoding ', $this->encoding);
}
Finally solved the problem, now we can rest assured that the use of Phpmailer to send the attachment.