0

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?

3 Answers 3

3

Delving into RFC 2047:

5. Use of encoded-words in message headers

An 'encoded-word' may appear in a message header or body part header
   according to the following rules:

[...]

(3) As a replacement for a 'word' entity within a 'phrase', for example,
    one that precedes an address in a From, To, or Cc header.  The ABNF
    definition for 'phrase' from RFC 822 thus becomes:

    phrase = 1*( encoded-word / word )

    [...]

   These are the ONLY locations where an 'encoded-word' may appear.  In
   particular:

   + An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'.

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 use verify = 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:

From: Automated System:;

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!

1

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"

  "Ximena" <[email protected]>
  "phrase" <[email protected]>
0

in Exim4

2022-12-20 12:08:55 [20316] 1p7g6p-0005Hg-7L ***************** RUNNING acl_custom_check_data ++++++++++++++

2022-12-20 12:08:55 [20316] 1p7g6p-0005Hg-7L H=(mx27.sXXXXXXXse.com) [XXX.XXX.XXX.XXX]:X I=[XXX.XXX.XXX.XXX]:25 [email protected] rejected after DATA: malformed address: [email protected]\n may not follow [email protected] : failing address in "To:" header is: [email protected] <[email protected]>

The email was being sent from a Python script. The python script set the To header as "[email protected] <[email protected]>"

I traced this rejection to the problem of having an email address string at the beginning of the To header. When changing the Python script to use "steve <[email protected]>" the email was not rejected by Exim4's header verify.

Based on the info from Sam Morris above I am interpreting the "@" symbol in the To header "name" prefix, as being an "encoded" word, and that is the reason why the message was being rejected by Exim4.

The other possibility is the json object used in the Python script to pass the parameters to the smtp api, had a line break after the "name" : "[email protected]" in the source code, and that line break was passed to the api, and encoded in the smtp message headers, which triggered the rejection in exim4.

I hope this helps someone who is experiencing the same rejection error in exim4 rejectlog.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .