[6.12.1] Email notification broken

+1 its missing a title and im also unable to produce my own email warnings (the automatic ones work)

Can you post the PHP log (if existing), which can be found under Tools -> PHP settings

 

Mine is behaving a bit different- I'm not getting emails at all from my server on 6.12.1 (both my servers on 6.11.5 using the same email/authentication are still trucking along fine.)

 

I get nothing in my PHP log, but I am seeing this on my mail server for the emails coming from 6.12.1:

 

587 I=[IP_REDACTED]:54659 X=TLS1.2:AES128-GCM-SHA256:128 CV=yes DN="/CN=*.servconfig.com": SMTP error from remote mail server after end of data: 554 SMTP synchronization error DT=0.658s

I can confirm, there is nothing going into the PHP log. I set it to "All Categories", then went to Settings -> Notifications -> Test. Mail is sent successfully, nothing in the PHP log. But as said, the mail Header fields just go into the body.

 

I think the problem is that there are additional line breaks in the mail source code between some of the header lines, see attached source code (real mail domain is replaced by "example.com").

 

This designates to mail programs that now the body is following. See also this answer on Stackoverflow:

Quote

This was defined originally in RFC 822 and it is CR LF. Look at section 3.1.

Quote

3.1. GENERAL DESCRIPTION
A message consists of header fields and, optionally, a body. The body is simply a sequence of lines containing ASCII characters. It is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF).

The most recent version is RFC 5322 and the relevant section is now 2.1. It is more comprehensive, but has still the same content, i.e. the separator is CRLF.

 

unraid-notification.txt

Im happy that im just not too dumb. Email test is working fine. But when i try to use: 

   /usr/local/emhttp/webGui/scripts/notify -e "Heyho lets go" -s "wusstest du schon das du mit dem und so weiter" -m "eigentlich ist es ja total egal, aber du weisst ja..." -i "warning"
 

i get 

ssmtp: 554 For explanation visit https://postmaster.web.de/de/case?c=hi&i=ip&v=myipadress

They are looking to fix in next release.

2 hours ago, nuhll said:

Im happy that im just not too dumb. Email test is working fine. But when i try to use: 

   /usr/local/emhttp/webGui/scripts/notify -e "Heyho lets go" -s "wusstest du schon das du mit dem und so weiter" -m "eigentlich ist es ja total egal, aber du weisst ja..." -i "warning"
 

i get 

ssmtp: 554 For explanation visit https://postmaster.web.de/de/case?c=hi&i=ip&v=myipadress

Mhh.. Normally I would say either check your mail settings or that your public IP is not blacklisted (e.g. https://check.spamhaus.org/). But when the mail test from the GUI is working, there may be some other problem. Either way, do you have the possibility to try another SMTP server?

10 minutes ago, Koelle said:

Mhh.. Normally I would say either check your mail settings or that your public IP is not blacklisted (e.g. https://check.spamhaus.org/). But when the mail test from the GUI is working, there may be some other problem. Either way, do you have the possibility to try another SMTP server?

wtf how can it be blacklisted when the test functionally is 100% working omg

 

and even the error on the page shows whats up 

"Dies schließt folgende Punkte ein:

Folgende Header müssen syntaktisch richtig sein: Date, From, Sender, To

Die Header BCC, CC, Date, From, Sender, Subject und To dürfen nicht mehrfach vorkommen"

 

its just bad email

Edited June 26, 2023 by nuhll

This is an issue with PHP 8, where they changed how they handle line breaks between email headers. When used in conjunction with sendmail, this causes the headers to be malformed. Thankfully there is a config flag ( mail.mixed_lf_and_crlf = On ) to revert to the previous behavior, this will be included in 6.12.2

 

Interestingly it seems that gmail patched their servers to accept the malformed headers from PHP8/sendmail, which is why I never noticed the issue during the RC phase. Other smtp servers don't accept the malformed headers and throw a 554 error instead.

Changed Status to Solved