[Exim] [OT]: HELO verification

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Phil White
日付:  
To: exim-users
題目: [Exim] [OT]: HELO verification
OK. i lied. Only partially OT. (this may be the first of many posts..)

First, there have been MANY posts before about ACL header verification.

As I see it, I break down the problem as follows:
  1) No HELO at all
  2) Syntactically invalid HELO
  3) Erronous configuration:
     rDNS = host.domain.com
     helo = mailserver.domain.com
  4) Downright lie
     rDNS = h24-81-68-158.vs.shawcable.net
     helo = mailserver.yahoo.com
  5) No rDNS entry
all of which will be flagged if we use the ACL
     !verify         = helo
WITH THE EXCEPTION that if $sender_helo_name resolved to the same ip-address
as $sender_host_address, verification passes.


Looking at a fortnights spam logs, HELO verification, on a percentage basis,
would eliminate a large percentage of unwanted mail. However, the casualty
rate would be unacceptably high - even though the actual number is small.

All (so far) of the casualties fit into the (3) and (5) categories, mostly the
former, and it does seem a little unfair to reject mail if this is the case
(yes, I know it's against RFC's)

So, I devised the following:

warn    message         = X-Warning: BAD HELO
        !verify         = helo
    condition       = ${if def:sender_helo_name {yes}{no}}
    #### NOTE ####### Uncommenting out the next line relaxes the rules a little
        condition       = ${if match {$sender_host_name} \
                        {${if match{$sender_helo_name}{\N.+?\.(.+)\N}{$1}}} \
                            {no}{yes}}


First question: is my categorisation of the various options correct? Any other
permutations?

Second question: Is there a bug in Exim 4.22?
exim -bh 194.203.96.242 -d-all+acl+expand works correctly, and does not warn
in case (3). However, a real submission over telnet DOES get flagged. (or
have I made a balls-up?)

Any comments?

Now the off-topic bit.

This ACL was triggered by one specific host, which I cannot afford to reject
under any circumstances. I could omit the check for that one host, but it has
occurred with others, and I feel ATM that this check is reasonable to
include.

I have been in contact with the relevant postmaster of the other mailserver,
who is reluctant to change their configuration. "It has worked well for the
last 3 years, and we won't change it now". But, I think, if I persist, I
might win... (no harm in a little optimism!)

Except that their host uses SENDMAIL. Before I go to the other mail-list to
ask help, is there anyone here that understands sendmail config files? If so,
could you contact me off-list?

Their config is as follows:

One host, 1 real and 2 virtual IP-addresses, each with a seperate sendmail
daemon & config files. All mail currently gets sent out on the main
ip-address, whilst listening on the correct virtual ip. HELO names are
correct for each one. Therefore, each daemon needs to send out on the correct
interface.

If anyone can help, I'd be grateful. Thanks.

Phil.