Exim rewrite: malformed address: <email@domain.com> may not follow email@domain.com
After a recent cPanel update, I am getting the error on some emails:
rewrite: malformed address: may not follow email@domain.com
This looks exactly like verify = header_syntax email@domain.com is not an RFC compliant header, and that it should technically be "email@domain.com" (with quotes around the name if the name contains the @ symbol). However, that does not stop some scanners and devices from doing that outside of our control, so I need it to ignore that just like it always has before.
This has never been a problem before the most recent cPanel update.
I read on another topic here, something similiar happens if " EXPERIMENTAL: Rewrite From " is enabled, but I already have that set to the default setting of disabled.
Is there another exim config file somewhere that has verify = header_syntax enabled? Or can anyone tell me why Exim is suddenly failing when using that technically incorrect format and how I can fix it without modifying devices out there that are outside of my control, like printers and scanners?
I'm on v110.0.1
-
Hey there! The malformed address error usually happens with autoresponders, so the first thing I'd want to know is if an autoresponder is being used in this case? If you could get us more details, with any IPs and email address anonimized, that would be helpful. It would be good to know the following: -if the original sender is on your server or if they are remote -if the original recipient is on your server of if they are remote -if any addresses have an autoresponder, forwarder, or filter that could be related to this issue. I'm not personally aware of any recent updates that may have caused this, but that doesn't mean it hasn't happened, just that I haven't come across it yet. 0 -
There are no autoresponders. It's just a standard email being sent. The device is a Sharp Printer/Copy machine. The config on this device has not changed in a very long time, and the scan-to-email feature on this is used fairly often. Since there was no name set, it was setting the from to: email@domain.com The RFC states that if the name has an @ symbol, it must be in quotes, like this: "email@domain.com" To "fix" this, and since I was able to access this particular copy machine, I went into the copy machine settings and added a name, so now it sends the from as: My Company I still need to get it fixed in cPanel to ignore that for other devices though. The name no longer has an @ symbol, therefore no longer requires quotes, and so it no longer fails at Exim. It works properly every time now with the name field populated inside the printer. The only change that caused it to stop happening was a cPanel update (and likely an Exim update as part of that). I was on v108 and updated to v110 a few weeks ago. The Exim FAQ has this exact scenario listed, although I don't see anywhere in the exim.conf file where this validation is enabled, so I don't know why it is checking for invalid headers at all: email@domain.com The original sender and receiver are on my server with local email accounts. 0 -
Since you have a way to reproduce this and access to all the logs, could you submit a ticket to our team so we can investigate this directly? 0 -
I just had this same issue this morning. For us, it was a setting in the sharp that has been empty for years. Today it started causing fits. I went to the sharp admin interface System Settings->Image Send Settings->Scan Settings Fill in the Default sender with anything you would like (I used Sharp Copier) Fill in the Reply Email with the same email address used by the sharp copier to send the email. Click Submit It immediately started working for us. I have no idea what changed. I didn't even go looking. Once it started working I moved on to my next headache! :) Good luck 0
Please sign in to leave a comment.
Comments
4 comments