A recent Exim upgrade added this to the default acl_smtp_data
ACL:
.ifndef NO_CHECK_DATA_VERIFY_HEADER_SYNTAX
deny
!acl = acl_local_deny_exceptions
!verify = header_syntax
message = header syntax
log_message = header syntax ($acl_verify_message)
.endif
This causes some messages to be rejected. For instance, the following header from a spam message:
2020-03-02 09:22:48 1j8hHk-0000gS-3Y H=(static-181-143-69-27.une.net.co) [181.143.69.27] F=<[email protected]> rejected after DATA: header syntax (unqualified address not permitted: failing address in "From:" header is: =?utf-8?B?IkRhbmlrYSIgPERhbmlrYUB1bmUubmV0LmNvPg==?=): unqualified address not permitted: failing address in "From:" header is: =?utf-8?B?IkRhbmlrYSIgPERhbmlrYUB1bmUubmV0LmNvPg==?=
Decoding the offending header, we get:
00000000 22 58 69 6d 65 6e 61 22 20 3c 58 69 6d 65 6e 61 |"Ximena" <Ximena|
00000010 40 76 69 6c 2e 63 6f 6d 2e 75 61 3e |@vil.com.ua>|
0000001c
Which looks like a perfectly fine value for a From
header to me.
Do I risk rejecting legitimate mail by using verify = header_syntax
, or are headers such as the one above invalid and safe to reject?
Delving into RFC 2047:
It appears that an
encoded-word
can be used for the text preceding the address in a header, but not for an address itself. So it's safe to useverify = header_syntax
, as long as we assume that legitimate mail will not contain headers that violate RFC 2047 by sneaking addresses into the encoded part of headers.On the other hand... what about RFC 6854? This allows headers such as:
to be fair, the RFC also says that this syntax "is only for Limited Use" ("appropriate for use only in limited or unique circumstances", e.g., experimentation, per RFC 2026). So I won't lose much sleep over it!
RFC2047 has been misapplied
section 5 allows three different ways that encoded words can be used this conforms to none of them.
The most that an encoded word can cover is a "phrase" or an "atom"