| # |
Apr 13th 2021, 18:47 |
 phantomwatson |
What's displayed to the recipient begins with that `--` in `Content-Transfer-Encoding: 8bit--fb8002af4ef885786feebbec6b9b709f` |
| # |
Apr 13th 2021, 18:46 |
phantomwatson |
`Content-Transfer-Encoding: 8bit--fb8002af4ef885786feebbec6b9b709f` doesn't look quite right. |
| # |
Apr 13th 2021, 18:46 |
phantomwatson |
Then after it's passed through `$this->_headersToString($headers, $eol);`: |
| # |
Apr 13th 2021, 18:45 |
phantomwatson |
Hm. Here are some of the contents of the `$headers` array: |
| # |
Apr 13th 2021, 18:41 |
kevin.pfeifer |
and it actually replaces `"\r\n", ''` in the headers |
| # |
Apr 13th 2021, 18:41 |
kevin.pfeifer |
https://github.com/cakephp/cakephp/blob/master/src/Mailer/Transport/MailTransport.php#L91 |
| # |
Apr 13th 2021, 18:41 |
kevin.pfeifer |
the default Mailt Transporter just has a wrapper for the default php `mail` function |
| # |
Apr 13th 2021, 18:35 |
greg138 |
Well then, whatever the equivalent is for the Mail transport... |
| # |
Apr 13th 2021, 18:33 |
phantomwatson |
I just tried doing that, but it looks like this isn't configured to go through SMTP. The transport `className` is unspecified in `app_local.php`, so I think it's defaulting to `Mail`. |
| # |
Apr 13th 2021, 18:31 |
greg138 |
If you can step through in a debugger, put a breakpoint in `_sendData` and look at what the header string contains. If you can't, then add logging there to enable you to see it. |
| # |
Apr 13th 2021, 18:29 |
phantomwatson |
On the CLI side, this application only has a single script that sends a few different automated emails. |
| # |
Apr 13th 2021, 18:27 |
kevin.pfeifer |
or just the contact form which is most likely triggered via a http request |
| # |
Apr 13th 2021, 18:27 |
kevin.pfeifer |
do you have another command-line script which sends mails? |
| # |
Apr 13th 2021, 18:26 |
phantomwatson |
I appreciate you two helping me work through this. It's perplexing. |
| # |
Apr 13th 2021, 18:26 |
phantomwatson |
Oddly, a different mechanism doesn't have this problem. The bug is with a command-line script that sends out emails, but a contact form that sends emails still sends them correctly. |
| # |
Apr 13th 2021, 18:25 |
kevin.pfeifer |
with that you know which side is faulty |
| # |
Apr 13th 2021, 18:24 |
kevin.pfeifer |
to totally count out the mailserver: have you tried sending the same mail via another smtp account through another mail server (if you have one available)? |
| # |
Apr 13th 2021, 18:24 |
greg138 |
It feels to me more likely that you're somehow sending bad data to the server, than that the server is at fault. |
| # |
Apr 13th 2021, 18:23 |
phantomwatson |
Totally worth checking, but nope. |
| # |
Apr 13th 2021, 18:20 |
greg138 |
No chance that the `_headersToString` function prototype in AbstractTransport got accidentally changed from `"\r\n"` to `"\r\n "`? |
| # |
Apr 13th 2021, 18:16 |
phantomwatson |
Huh. CakePHP _does_ use the all-caps `Message-ID` and not `Message-Id` when it sets email headers. But all of the headers are set like `$headers['MIME-Version'] = '1.0';`, so it doesn't make sense to me that a leading space could get introduced. Especially all of a sudden and without any code updates. |
| # |
Apr 13th 2021, 18:16 |
greg138 |
Check the `_sendData` function in the SMTP transport. |
| # |
Apr 13th 2021, 18:15 |
greg138 |
Step through the send portion of the Cake code where it assembles the headers and see what it looks like before going to the server. Or log *exactly* the string that's sent to the server to see what that looks like. |
| # |
Apr 13th 2021, 18:14 |
greg138 |
Could very well be that the spaces are coming from your code or Cake, somehow. |
| # |
Apr 13th 2021, 18:13 |
phantomwatson |
So am I right that this would be 100% a mailserver thing and unrelated to how CakePHP sends mail? |
| # |
Apr 13th 2021, 18:13 |
greg138 |
The first copy of those is probably ignored because of the space... |
| # |
Apr 13th 2021, 18:13 |
phantomwatson |
And now there's two Date: and Message-Id: headers when there wasn't before. |
| # |
Apr 13th 2021, 18:12 |
greg138 |
Yeah, that doesn't look great... |
| # |
Apr 13th 2021, 18:09 |
phantomwatson |
Since the bug, these header lines have started to be indented: |
| # |
Apr 13th 2021, 18:09 |
phantomwatson |
I wonder if this has something to do with a set of headers being apparently indented by a single space. I suspect they might be invalid and not applied because of that. |
| # |
Apr 13th 2021, 18:06 |
greg138 |
Potentially... |
| # |
Apr 13th 2021, 18:06 |
phantomwatson |
So that might actually be something on CakePHP's side. It might not be using the right line breaks when it's sending the message to the mailserver. |
| # |
Apr 13th 2021, 18:05 |
greg138 |
If the line breaks are wrong or missing, that explains 100% of this. One of the headers indicates what the MIME separator string will be. Without knowing that, it thinks it's all just one big text message, as you're seeing. |
| # |
Apr 13th 2021, 18:04 |
kevin.pfeifer |
sorry but i have no experience with cakephp-i18n even though its on my list of "what i will need to check out" ,:) |
| # |
Apr 13th 2021, 18:03 |
greg138 |
The email sending will have something like `implode("\r\n", $this->headers)` |
| # |
Apr 13th 2021, 18:03 |
phantomwatson |
Yeah, the content preview is treating those lines as being part of the message body, so line breaks are stripped out. |
| # |
Apr 13th 2021, 18:03 |
greg138 |
No, those should be string constants, not relying on anything in a template. |
| # |
Apr 13th 2021, 18:02 |
kevin.pfeifer |
if it is `\r` or `\r\n` related that smells to me like some windows user edited a template file which was edited with a mac before |
| # |
Apr 13th 2021, 18:02 |
phantomwatson |
Since the bug appeared, there are differences in the message headers, so I'm thinking it might be a mailserver thing. There's a `Message-ID` and `Message-Id` now with different values, for instance. |
| # |
Apr 13th 2021, 18:01 |
greg138 |
It includes it just like that? It should be: `--c4b32d6e649482ee9bbc730b0d34c628` `Content-Type: text/plain; charset=UTF-8` `Content-Transfer-Encoding: 8bit` |
| # |
Apr 13th 2021, 17:55 |
phantomwatson |
Weird. The `Content preview:` part of the headers even started including > --c4b32d6e649482ee9bbc730b0d34c628 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit (actual text content starts here) whereas before this bug appeared, it would just be the text content. |