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.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/