Mail rejected with smtpstatus=552 by server

[copain60]

A few days ago the mail server of my provider started to reject messages with this error code:

smtpstatus=552 smtpmsg='552 5.2.0 Message contains bare CR and is violating 822.bis section 2.3'

I am using msmtp 1.8.23 on RPi bookworm to send mail from system cron jobs.

Before, it had been working flawlessly. There were no updates or configuration changes made on the system.

This is what I found about the same issue. Maybe it is of some use to experts. https://github.com/domoticz/domoticz/issues/5993

Is there a problem with msmtp? How can it be resolved?

Many thanks.

[marlam]

The bare CR does not come from msmtp - it is likely part of the message that you send via msmtp. Which means the program that generates the mail is the one that violates the RFCs.

[balejk]

@copain60 Have you been able to solve the problem?

Can you share how exactly (using which program and version) you are generating the invalid messages?

You could try exporting the raw message and checking whether it really already contains bare CRs before it is passed to msmtp and then report that to the developers of that program.

As for why it stopped working on its own, based on the discussion you linked (the second post in particular), it sounds like your provider might have stopped accepting bare CRs because of some recently discovered security vulnerability.

[copain60]

There is no solution!

That is what happened, the provider changed the policy.

The mails are generated by executing bash scripts for ftp transfer on an up-to-date debian 12 raspi. I have no knowledge about what modules generate these system messages.

Maybe you know more? And how a possible solution could look like and be initiated?

[balejk]

copain60, 2024-04-13T04:02:42-07:00:

The mails are generated by executing bash scripts for ftp transfer on an up-to-date debian 12 raspi. I have no knowledge about what modules generate these system messages.

What bash scripts?

Maybe you know more? And how a possible solution could look like and be initiated?

I'm sorry, but I probably do not. I think your best bet is to track down where the invalid emails originate, confirm that they indeed contain bare CRs and then either try to get that fixed or, if that proves impossible, try to introduce some middle agent where you will preprocess the emails (so likely sed those CRs into CRLFs) before they are passed to msmtp.

From what I was able to find, the error message is actually probably coming rather from the recipient's server, rather then yours. It is thus also possible that the problem is introduced at your provider's server, such as via an antivirus check, see for instance [1], although that deals with bare LFs instead. I definitely recommend looking at the page that article references [2]. And you might also find this [3] useful -- who is your provider anyway? Have you tried asking them whether the problem might occur on their end?

Assuming that you don't currently have the possibility to see the messages before they are sent, you could also first try temporarily replacing the msmtp binary with a script which would save a copy of whatever is being piped into msmtp and then forward it into the real msmtp (if you can, it should be sufficient to just introduce something like tee -a file into the command chain). Then inspect file and see if it contains bare CRs or not -- if not, the problem is likely to originate at you provider's server. If yes, see what I wrote two paragraphs earlier.

Since those articles mention that these problems may also occur when you try to send long lines, it might be useful if you mention what your emails look like: in particular, whether they might contain some really long lines, which doesn't seem unlikely, since it sounds you are generating them automatically.

[1] https://www.techtarget.com/searchwindowsserver/tip/Beware-of-bare-linefeeds-in-Exchange-Server-email [2] http://cr.yp.to/docs/smtplf.html [3] https://community.virginmedia.com/t5/Email/Emails-Bouncing-Back-quot-Message-contains-bare-CR-quot/td-p/5469417

[marlam]

Since this does not look like an msmtp issue, I'll close this now - but please re-open if you disagree.