Log message #4261324

# At Username Text
# Apr 13th 2021, 20:18 phantomwatson Automatically, I mean.
# Apr 13th 2021, 20:18 phantomwatson If I understand it correctly, it's being yanked out of `app_local.php`.
# Apr 13th 2021, 20:08 greg138 I'm curious where the return path is coming from.
# Apr 13th 2021, 20:03 phantomwatson Oh, there's a daily and a weekly version of the emails, but both have the same issue.
# Apr 13th 2021, 20:02 greg138 And your screen shot before has "Today in" as the subject, not "Upcoming Week in". They are both exhibiting the issue?
# Apr 13th 2021, 20:02 phantomwatson Set in `app_local.php`.
# Apr 13th 2021, 20:02 phantomwatson The return-path is being pulled from the `Email.default.returnPath` configuration option, I think.
# Apr 13th 2021, 20:00 greg138 Hmm, you're not setting the return path anywhere, yet it's in the "bad headers" (ones with a space before them).
# Apr 13th 2021, 19:59 kevin.pfeifer how about enabling output buffering and checking if something prints somewhere?
# Apr 13th 2021, 19:58 phantomwatson Good thought, but `app_local.php` looks fine. Nothing before `<?php`.
# Apr 13th 2021, 19:58 greg138 But the spaces are coming before the header *name*, not the value.
# Apr 13th 2021, 19:57 kevin.pfeifer since your using the Configure classes here do you have some spaces in your `config/app_local.php` probably?
# Apr 13th 2021, 19:57 greg138 We must be getting close...
# Apr 13th 2021, 19:56 phantomwatson I could try ditching the `Mailer` class system and sending emails just with `new Email(); ... send()` to see if that works, but that's not ideal, and I'd like to figure out what suddenly broke these messages.
# Apr 13th 2021, 19:55 slackebot Week in Muncie: $date") ->setViewVars([ 'events' => $events, 'recipient' => $recipient, 'settingsDisplay' => $this->getSettingsDisplay($recipient), ]) ->setEmailFormat('both') ->setDomain('muncieevents.com'); }```
# Apr 13th 2021, 19:55 phantomwatson But nothing about the `Mailer` class code looks unusual. ```public function weekly($recipient, $events) { $this->viewBuilder()->setTemplate('weekly'); $date = (new FrozenTime('now', Configure::read('localTimezone')))->format('l, M j'); $this ->setTo($recipient->email) ->setFrom(Configure::read('automailer_address'), 'Muncie Events') ->setSubject("Upcoming
# Apr 13th 2021, 19:53 phantomwatson Nope, the ones that work just create an `Email` object and then `->send()` it.
# Apr 13th 2021, 19:52 greg138 You said there's emails sent from your site that work okay? Do they use the same Mailer class?
# Apr 13th 2021, 19:41 kevin.pfeifer well then i would look for some strangely encoded strings or whitespace before `<?php` in your custom Mailer.php
# Apr 13th 2021, 19:41 phantomwatson But I don't see anything in my Mailer class code that seems unusual, or which deviates from what's in the docs.
# Apr 13th 2021, 19:39 phantomwatson The plot thickens. These emails are only bugged when I use a `Mailer` class, but not when I just create a new `Email` object and `->send()`.
# Apr 13th 2021, 18:56 phantomwatson Actually, crap, that may have just been an artifact of how I was generating debug output. :( `print_r($headers); echo "\nMESSAGE BELOW\n"; print_r($message); echo "\nEND OF MESSAGE\n";` generates ```Content-Transfer-Encoding: 8bit MESSAGE BELOW --1c2e6618b5d00c393f7043526a0b5fdf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit (actual content)```
# Apr 13th 2021, 18:50 phantomwatson _But_, the source of the message that the recipient receives _does_ include this double line break:
# Apr 13th 2021, 18:48 phantomwatson So it looks like the headers are missing a double-line-break before the gibberish boundary line.
# 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)?