[exim] UTF8 support wreaking havoc with temporary deferrals

Hi,

We are using Exim that has utf8 internationlisation support compiled in. We do not advertise SMTPUTF8 support, as we have smtputf8_advertise_hosts set to an empty list.

However, Exim appears to still accept utf8 messages even if they aren't advertised at EHLO time. I assume this is due to misbehaving senders as these messages appear to all be spam.

When this happens, and our server forwards these messages to a remote smtp recipient, we are often receiving a "utf8 support required but not offered for forwarding" error in the Exim error log. However, instead of this being treated as a permanent 5xx error, it's treated as a 4xx error. This causes the remote host to enter into a retry-period for all other messages, and repeats indefinitely as the offending messages remain in the queue.

I can't find a way to blackhole these messages when they arrive, as the $message_smtputf8 variable doesn't seem to be set on these messages. And I can't find a way to make these errors generate an immediate 5xx fail, and I can't find a way to stop them from being accepted.

I'm not necessarily suggesting this is a bug, but it's strange to me that these delivery failures are treated as temporary. If the remote server doesn't support utf8, why would it an hour from now?

Not sure which of these might best solve our problem here:

- Make the "utf8 support required but not offered for forwarding" a 5xx fatal error

- Make downconversion the default in ALL cases

- Outright rejection of utf8 messages if smtputf8_advertise_hosts does not match the current host

- A new transport option forcing downconvert on smtp transports

If anyone can shed some light on how we can work around this for now, would appreciate it.

Thanks,

Dean Brooks
dean@???