Re: [Exim] helo_verify and EHLO containing *domain* name?

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Tor Slettnes
Dátum:  
Címzett: Toralf Lund, exim-users
Tárgy: Re: [Exim] helo_verify and EHLO containing *domain* name?
[Toralf: sorry for the dupe, I forgot to Cc: the list]

On Thu, 2004-03-11 at 05:27, Toralf Lund wrote:
> 2004-03-10 02:37:44 rejected EHLO from dmz158.dnv.com (dnv.com)
> [193.212.132.158]
>
> (From the reject log.) The problem appears to be that the EHLO contains
> a domain name rather than a host. Shouldn't this be accepted?


Just a different perspective on what others (Greg Wood) has already
said:

- The HELO name should correspond to a name with an DNS "A" or "AAAA" or
"A6" record, in other words, to a valid IP address (v4 or v6 - whichever
protocol is used for the inbound SMTP connection).
- That IP address should correspond to the calling party's IP address.
- The calling party's IP address should resolve (via a DNS "PTR" record)
back to the calling name.

Exim's "helo_[try_]verify_hosts" setting will, when enabled for the
calling host, check that the calling name is one of:
  - an IP literal ("[xx.yy.zz.ww]") matching the calling party's address
    (this can be turned off), or
  - the resulting name from a reverse lookup of the calling party's IP
address, or
  - a name that resolves to the calling party's IP address via a forward
lookup.



In the example above, even though a reverse lookup of the IP yields
"dmz158.dnv.com", as long as "dnv.com" resolves to 193.212.132.158 via
an "A" lookup, Exim will be able to verify the HELO name.

Rejecting a message based on this criteria is a specific violation of
RFC822, and as you have experienced, not every "legit" (but misguided)
MTA are configured correctly. I have taken a slightly more liberal
approach:

acl_check_helo:
  deny message   = Give me your name, not an IP address
       condition = ${if isip {$sender_helo_name}{1}{0}}
       delay     = 15s


  deny message   = Do not pretend to be me, impostor!
       condition = ${if eq {${lc:$sender_helo_name}}{$primary_hostname}{1}{0}}
       delay     = 15s


accept



> Exim version is 3.34. I *still* haven't upgraded, based on the simple
> prinsiple of "if it's not broken, don't fix it" (and my setup basically
> *works*, although I need to adjust policy checks etc. now and then.)


Well, if not today, then tomorrow. As your demand for sophisticated and
fine grained control grows, so does your need for Exim4.

For starters, it is my opinion that the only RIGHT way to do mail
filtering (sanity checks, virus scanning, spamfiltering) is at SMTP
time, because:
(a) you want to let the sender know if their message has been filtered
out, just in case it was legit, and
(b) you cannot rely on the "From", "Sender" headers or the "MAIL FROM"
envelope sender, so if you generate bounce message, it will often inform
innocent third parties of a virus or spam content in "their" e-mail.

On that premise, you NEED 'Exiscan-ACL' (or SA-exim, or similar).
Hence, Exim 4.

-tor