Default Exim config causes valid mail to be rejected

Omines

Verified User
Joined
Dec 17, 2007
Messages
48
Ran into the same issue today as a while back, and did the dive into RFCs to trace it to an issue in DirectAdmin stock exim configs.

The following config section in exim.conf attempts to protect from spammers:
Code:
#EDIT#27:
  # 1st deny checks if it's a hostname or IPV4 address with dots or IPV6 address
    deny message = R1: HELO_SHOULD_BE_FQDN
         !authenticated = *
         condition   = ${if match{$sender_helo_name}{\N^\[\N}{no}{yes}}
         condition   = ${if match{$sender_helo_name}{\N\.\N}{no}{yes}}
  ## 2nd deny makes sure the hostname doesn't end with a dot (invalid)
  #  deny message = R2: HELO_SHOULD_BE_FQDN
  #       !authenticated = *
  #       condition   = ${if match{$sender_helo_name}{\N\.$\N}}
  # 3rd deny makes sure the hostname has no double-dots (invalid)
    deny message = R3: HELO_SHOULD_BE_FQDN
         !authenticated = *
         condition   = ${if match{$sender_helo_name}{\N\.\.\N}}
  ## 4th deny make sure the hostname doesn't end in .home (invalid domain)
  #  deny message = R4: HELO_SHOULD_BE_FQDN
  #       !authenticated = *
  #       condition  = ${if match{$sender_helo_name}{\N\.home$\N}}
However, every time we update/install exim_conf through DirectAdmin we then have issues with local PHP websites sending emails:
Code:
2018-04-24 14:47:53 H=localhost [127.0.0.1] F=<[email protected]> rejected RCPT <[email protected]>: R1: HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1)
The affected sites use SwiftMailer, pretty much the standard mail sending library for PHP. By default it identifies itself like this:
Code:
HELO [127.0.0.1]
This is valid per section 4.1.3 of RFC 2821 governing SMTP:
Sometimes a host is not known to the domain name system and
communication (and, in particular, communication to report and repair
the error) is blocked. To bypass this barrier a special literal form
of the address is allowed as an alternative to a domain name. For
IPv4 addresses, this form uses four small decimal integers separated
by dots and enclosed by brackets such as [123.255.37.2], which
indicates an (IPv4) Internet Address in sequence-of-octets form.
This is therefore wrongly banned by section #27 of the default configuration, and I would recommend removing it altogether since it's pretty useless as spam protection as well with modern spambots. Right now it's only causing disgruntled customers losing hours of contact requests until we discover this problem is playing up again every time an update to exim conf is released.
 
No it's not an Exim issue, it's a Swiftmail issue.

This is a literal helo as by your example, which would be correct and should not be refused:
Code:
HELO [127.0.0.1]

Now lets look at your own helo string:
Code:
H=localhost [127.0.0.1]
Which is completely different. Localhost is a hostname, so Exim expects a FQDN there and correctly refuses the mail.

It should read:
Code:
H=[127.0.0.1]

So something in Swiftmail is messing things up and using the hostname (localhost) instead of only the ip in brackets.
 
Back
Top