pear / Mail

Class that provides multiple interfaces for sending emails

Home Page:http://pear.php.net/package/Mail

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Wrong header separator

peterthomassen opened this issue · comments

mail() documentation says:

additional_headers (optional) [...] Multiple extra headers should be separated with a CRLF (\r\n)

However, Mail_mail sets the header separator to PHP_EOL (if that constant is defined). On my system, this is \n (in contrast to what mail() expects).

As a result, on my system (Ubuntu 22.04, PHP 8.1), additional headers are not properly delivered: All but the first header are indented with a single space, making them a continuation of the previous header. Example message (as actually delivered):

To: recipient@local
Subject: Test subject
MIME-Version: 1.0
 Bcc: secret.recipient@local
 Sender: sender@local
 From: First Last <from@local>
 Content-Type: multipart/mixed;
 boundary="=_0a0ac24becceaae619c86104faa042c3"
Message-Id: <E1pNYm0-004IxB-D0@web.local>

This results in fully broken email display (MIME boundary does not work, Bcc header malformed and thus retained as plaintext, ...). -- Note that the first header (MIME-Version) does not have the space.

I cannot tell at which point (after calling mail()) these spaces get inserted. But I can tell that Mail_mail's practice of using PHP_EOL (\n) as a separator when passing additional_headers to mail() is in contradiction to the docs, which say that \r\n should be used.

And indeed when I override ->sep = "\r\n" on my Mail_mail instance, the problem goes away.

As things work as described in the mail() documentation, I think that the logic for setting sep is flawed, and \r\n should be used exclusively.

commented

@peterthomassen Want to make a PR and add a test? What you say makes sense, more surprised no one hit this before.

Sure. I had not opened a PR because the original commit that added the PHP_EOL magic looked like there was a reason for it, and I wanted to start a discussion first. But if there's consensus, I can go ahead and create a PR.

commented

The commit you linked seems to do it right. Did you mean a later one? I am on my phone and can't look.

@jparise has written, that we can't guarantee the use of \r\n on every system. It looks to me like he was not sure if any other system uses only \n in Mail headers. So I think, we should do some tests with a Linux and a windows system. @peterthomassen please make a PR and I will merge it into a branch, so we can test it on a bunch of system.

commented

I was just confused this is even up for debate:

Each header field is logically a single line of characters comprising
the field name, the colon, and the field body. For convenience
however, and to deal with the 998/78 character limitations per line,
the field body portion of a header field can be split into a multiple
line representation; this is called "folding". The general rule is
that wherever this standard allows for folding white space (not
simply WSP characters), a CRLF may be inserted before any WSP.

(source) — CRLF is \r\n. 🤷🏼

@till 👍 thanks
@peterthomassen please send your PR

Someone should test whether this is gonna work with PHP < 8. There's been some changes regarding this over time, e.g. https://bugs.php.net/bug.php?id=47983

@alecpl Thanks for your input. I will test this, when i do some tests on different server OS.

To follow