Re: [exim] OT: Daft Question: HELO/EHLO FQDN or FQHN?

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Michael J. Tubby B.Sc G8TIC
Date:  
À: exim.ml
CC: exim-users
Sujet: Re: [exim] OT: Daft Question: HELO/EHLO FQDN or FQHN?
I have had exactly the the same issue to resolve here, i.e. should HELO
(or EHLO) be a domain name or a host name and whether you should reject
based on it...

I've works around this by:

     1. rejecting single word HELO i.e. must contain at least one dot
     2. rejecting HELO from bare IP addresses
     3. rejecting HELO from our own host name - catches a lot of bulk 
mailers
     4. rejecting HELO from domains that we relay for but that are not 
expected to send via us
     5. rejecting HELO from a range of blacklisted names in a database
     6. warning if HELO doesn't verify
     7. accepting everything else - this lets FQDN and FQHN both through


Running this on three email relay machines with circa 10,000 emails a
day and no significant problems here.

Copy of my ACL below.

Regards


Mike




acl_check_helo:

         #
         # check for single word greeting messages like "HELO COMPUTER"
         #
         deny    condition = ${if match {$sender_helo_name} {\\.} {no}{yes}}
                 message = Your HELO/EHLO greeting ($sender_helo_name) 
is a single word. \
                         According to RFC2821 you must use your 
fully-qualified domain-name. \
                         Please fix your configuration if you want to 
talk to us
                 logwrite = HELO: HELO/EHLO was not a FQDN : 
$sender_helo_name from $sender_fullhost


         #
         # check for raw IP address in greeting like "HELO 1.2.3.4"
         #
         deny    condition = ${if isip{$sender_helo_name}}
                 #condition = ${if match 
{$sender_helo_name}{^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$}{yes}{no}}
                 message = Your HELO/EHLO greeting ($sender_helo_name) 
is a plain IP address. \
                         According to RFC2821 you must use your 
fully-qualified domain-name. \
                         Please fix your configuration if you want to 
talk to us
                 logwrite = HELO: HELO/EHLO with bare IP : 
$sender_helo_name from $sender_fullhost


         #
         # check for HELO from our host name... must be a faker!
         #
         deny    condition = ${if match 
{$sender_helo_name}{$primary_hostname}{true}{false}}
                 message = Your HELO/EHLO greeting ($sender_helo_name) 
is using our name! \
                         According to RFC2821 you must use your 
fully-qualified domain-name. \
                         Please fix your configuration if you want to 
talk to us
                 logwrite = HELO: Rejected because remote host used our 
hostname: $sender_helo_name


         #
         # check for HELO from domains that we handle (local domains and 
relay domains)... if so this is fake
         #
         deny    condition = ${if 
match_domain{$sender_helo_name}{$+local_domains:+relay_to_domains}{true}{false}}
                 message = Your HELO/EHLO greeting ($sender_helo_name) 
is using one of our domains! \
                         According to RFC2821 you must use your 
fully-qualified domain-name. \
                         Please fix your configuration if you want to 
talk to us
                 logwrite = HELO: Rejected because remote host used one 
of our domains:


         #
         # check for HELO names blacklisted in our database, if we 
reject don't give too much help as to why
         #
         deny    condition = ${if 
match_domain{$sender_helo_name}{+blacklist_helo}{yes}{no}}
                 message = Your HELO/EHLO is not acceptable here
                 logwrite = HELO: Rejected HRLO: $sender_helo_name from 
$sender_fullhost - blacklisted


         #
         # attempt to verify the HELO/EHLO, if it fails just generate a 
log warning - we cannot reject
         # based on this. See also the check_content ACL where we add a 
warning to headers for invalid HELO
         #
         warn    !verify = helo
                 logwrite = HELO: Warning: cound not verify HELO/EHLO: 
$sender_helo_name from remote host: $sender_host_address ${if 
def:sender_host_name {($



         #
         # accept everything else
         #
         accept  message = Hello $sender_helo_name, pleased to meet you
                 logwrite = HELO: Accepted HELO/EHLO: $sender_helo_name 
from remote host: $sender_host_address ${if def:sender_host_name 
{($sender_host_name)








On 17/04/2012 07:37, Ron White wrote:
> Today I am beating myself up over HELO/EHLO.
>
> I've always understood that the syntax of a HELO/EHLO should be:
>
> HELO host.domain.tld - that is a FQHN.
>
> However, looking at RFC's (821/2821/1123 section 5.2.5) I'm struggling
> to get absolution on it, and fear I may have understood wrong.
>
> 2821 says Syntax:
> ehlo = "EHLO" SP Domain CRLF
> helo = "HELO" SP Domain CRLF
>
> And that would appear to suggest just a FQDN is needed.
>
> 821 says:
> HELLO (HELO)
> ...The argument field contains the host name of the sender-SMTP
> But 2821 obsoletes 821...
>
> RFC 1123 Says:
> "The sender-SMTP MUST ensure that the<domain> parameter in
> a HELO command is a valid principal host domain name for the
> client host.
>
> 'valid principal host domain name' is that a host name, a domain name, a
> host and domain name, a FQDN, a FQHN?
>
> Now, I know that the RFC's also say words to the effect of "You can
> check the HELO/EHLO argument, but must not reject based upon it" but I
> note another well known MTA offers this mechanism:
>
> "Helo command rejected: need fully-qualified hostname"
>
> So whilst it should not matter, clearly it can.
>
> It crosses my mind that not every client in the world using SMTP is
> going to be able to provide a FQDN or a FQHN. End user clients using
> SMTP to send mail from dynamic address space, and even this kind of
> thing:
>
> Received: from apache by example.null with local (Exim 4.76)
>
> I'd just like to be able to put it to bed in my mind in terms of 'best
> practice'.
>
> Apologies for the banality of the question, and the OT nature.
>
>