Yes, that is intended behaviour. Version 2.5 has this in the change log:
No 7-bit/8-bit check on received message content (see NEWS file).
And in the 2.5 NEWS file:
Previous versions of E-MailRelay test message content when a message is received
and populate the "Content" field of the envelope file as either "7bit" or
"8bit". However, the SMTP client code has always largely ignored this field and
it would attempt to forward 8-bit messages to a remote server that did not
advertise 8BITMIME, albeit with a warning in the log.
In this release E-MailRelay no longer tests messages for eight-bit content,
so the envelope "Content" field will always be "8bit". If this is not the
desired behaviour then a filter script should be used to test for seven-bit or
eight-bit content and edit the "Content" value in the envelope file accordingly.
If necessary the SMTP client can now be made to behave more strictly so that it
does not try to forward eight-bit messages to seven-bit servers (see
"--client-smtp-config").
Testing for 7-bit content was a significant performance penalty and only relevant if forwarding to a 7-bit-only server. Hopefully there are none of those left in the wild.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that is intended behaviour. Version 2.5 has this in the change log:
And in the 2.5 NEWS file:
Testing for 7-bit content was a significant performance penalty and only relevant if forwarding to a 7-bit-only server. Hopefully there are none of those left in the wild.
Classic case of RTFM.
However, thank you for this great product!
Regards