| # |
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. |
| # |
Apr 13th 2021, 17:53 |
phantomwatson |
There wasn't any change to any relevant code, as far as I can tell. At around the same time, the CSS rules for email messages were updated, but I can't imagine that that would be related, plus it looks like the first weird email was sent out before the CSS update was deployed. I'm not sure how to check on how the mail server handles newline characters, but that's a good point. |
| # |
Apr 13th 2021, 17:49 |
greg138 |
Guessing that maybe there's a lack of line feed between headers? Did you just start sending as 'both' instead of 'html' or 'text'? Or was there an update to the mail server being used, maybe there was a change from something that expects just `\n` at the end of headers to `\r\n` or vice versa? |
| # |
Apr 13th 2021, 17:24 |
slackebot |
charset=UTF-8 > Content-Transfer-Encoding: 8bit > > sender@domain.com, it's that, plus 9ae97814549244449fea8a769ad79e1c@domain.com, plus "8bit <>". Has anyone ever seen something like this? |