Re: [Exim] blocking fake yahoo and hotmail

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Richard.Hall
Dátum:  
Címzett: exim-users
Tárgy: Re: [Exim] blocking fake yahoo and hotmail
Hi,

This is obviously my day for being confused :-(

I'm now playing with ...

On Sat, 29 Nov 2003, Kevin Reed wrote:

> Alan J. Flavell said:
> > On Sat, 29 Nov 2003, Kevin Reed wrote:
> >
> >> Marc Haber said:
> >> > On Fri, 21 Nov 2003 06:29:36 -0500, Suresh Ramasubramanian
> >> > <linux@???> wrote:
> >> >>If HELO yahoo.com comes from an IP with non yahoo rDNS, DENY - don't
> >> >>waste time deferring it.
> >> >
> >> > Nice idea. Do you have that recipe in acl syntax for a cookbook?
> >>
> >> There is a sample of it on the forum.
> >>
> >> http://exim.got-there.com/forums/viewtopic.php?p=465#465


and I'm confused about exactly what it is trying to achieve. I don't
understand why it uses partial-lsearch, rather than lsearch, in:-

        set acl_m9  = ${lookup{$sender_helo_name} \
              partial-lsearch{/usr/local/exim/helo-check} \
              {${if eq{$value}{}{$sender_helo_name}{$value}}}{}}


when the "Contents of the helo-check flat file are:
            mail.com
            microsoft.com
            hotmail.com
            msn.com hotmail.com
            compuserve.com
            aol.com
            outblaze.com
            yahoo.com"


i.e. there are no keys in the file prefixed with '*.'


Moreover, if I add one, eg '*.hotmail.com', then both
helo hotmail.com
and
helo mc6-s10.hotmail.com
will now match - but is it safe (in practice) to assume that the rDNS for
the latter will also be mc6-s10.hotmail.com? No, it isn't:-

    2003-12-31 03:38:43 1AbXBt-0002TH-00 <= <> H=(mc6-s10.hotmail.com)
    [65.54.251.84]


    # nslookup 65.54.251.84
    Name:    mc6-s10.law1.hotmail.com
    Address:  65.54.251.84


and I end up dropping messages I shouldn't. (Or maybe I should? Hi, Greg!)

So I _think_ what I need to do is

a) retain partial-lsearch, dspite my initial misgivings
b) have entries in the check file of the form
     *.domain.com: domain.com
   for those domains for which (I believe) the rDNS will always map to
   _something_.domain.com
c) have entries in the check file of the original form
     domain.com
   for those domains for which the rDNS will be ok for
     helo domain.com
   but not necessarily ok for
     helo xyz.domain.com


Is that clear? Am I right?

If so, the final question is - which of those in the above list can safely
be put in category (b)?



> > That looks handy, thanks. However, note that the recipe contains just
> > yahoo.com, but we get quite a number of spammers HELO'ing with
> > yahoo.fr, yahoo.ca, yahoo.co.uk (possibly others too). I'm not sure
> > what host names would show up if there was ever a genuine offer from
> > one of those - all the entries that I can see in the log appear to be
> > abusive.
>
> The idea was that you can now add as many other domains you want to the
> file and it will work without changing the configuration file.
>
> I've already added yahoo.ca yahoo.co.uk to my real one. I've also added
> ones that would never be valid like:
>
> atd-clan.de
> 9bit.qc.ca
> weblnk.net
> online-bill.com
> notmydesk.com
>
> As it has the same effect.
>
> > Could we reject outright on those HELOs, I wonder?
> >
> > Genuine calls from yahoo hosts seem to present the host name (random
> > example: n26.grp.scd.yahoo.com) in the HELO. Hotmail is the opposite:
> > many different host names (random example: law11-f54.law11.hotmail.com)
> > consistently presenting just "hotmail.com" in the HELO.
>
> The ACL will accept a hotmail.com only in the helo as long as the right
> most portion of the domain from the rDNS matches it.
>
> So, helo of "hotmail.com" will match law11-f54.law11.hotmail.com


... but if I'm right, helo of "n26.grp.scd.yahoo.com" will match
*.yahoo.com: yahoo.com
- not that many spammers are going to bother putting all those extra
characters in the helo string?

>
> --
> Kevin W. Reed - TNET Services, Inc.
> Unoffical Exim MTA Info Forums - http://exim.got-there.com/forums


TIA,
Richard Hall