Results 1 to 2 of 2

Thread: Default Exim config causes valid mail to be rejected

  1. #1
    Join Date
    Dec 2007
    Posts
    47

    Default Exim config causes valid mail to be rejected

    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=<no-reply@omines.com> rejected RCPT <info@omines.com>: 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.

  2. #2
    Join Date
    Jul 2008
    Location
    Maastricht
    Posts
    3,506
    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.
    Greetings, Richard.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •