Milter-greylist

The "domain" keyword is defined as performing a suffix search.
As coded, it actually performs a rightmost string match. This
is not what is expected and probably not what was intended.

Consider a real example:

	acl whitelist domain pix.net

fairly clear - I want to whitelist mail from "pix.net"

The surprise is that it also whitelists "epix.net"

I.e. it matches right most substrings instead of full domain "suffixes"

The biggest surprise is if you decide to have an acl based on
country code top level domains (for me a very effective acl addition)

Unfortunately, the country code domain "om" also matches "com" and that's
probably not at all what you want! (also note "et" matches "net"
and "il" "mil", etc.)

The fix is simple. I have been running it for a week with no problems.

---rick


*** acl.c.orig  Sun Oct  8 09:21:13 2006
--- acl.c       Fri Feb 23 18:38:15 2007
***************
*** 819,824 ****
--- 819,827 ----
        if (didx >= 0)
                return (0);

+       if ((hidx >= 0) && (host[hidx] != '.'))
+               return (0);
+
        return (1);
  }

Rick Adams <Rick.Adams@...> wrote:

>       acl whitelist domain pix.net
> 
> fairly clear - I want to whitelist mail from "pix.net"
> 
> The surprise is that it also whitelists "epix.net"
> 
> I.e. it matches right most substrings instead of full domain "suffixes"

Yes, that has been a known oddity for a long time. It was never changed
to avoid burning people relying on the original behavior. The easiest
workaround is probably to use a regex...

> The biggest surprise is if you decide to have an acl based on
> country code top level domains (for me a very effective acl addition

If you get the latest 3.1.6 version, you get GeoIP support, which is
more reliable than matching TLD.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

I wouldn't characterize it as an oddity. I think it's a clear bug and I wasted a lot of time tracking it down.
 
at a minimum, the unexpected behavior should be better documented. Best case it should be a configurable option. I'll code it if you'll accept it.
 
My opinion is you should force people who want substring matching to use regex, and those who want domains to get domain matching, not the other way around.
 
Making the behavior configurable seems a reasonable compromise. Then the debate is over the default on or off.
 
The GeoIP is interesting, but for me it wont be that useful. I WANT to get mail from .com domains in the UK, since I deal with them, but I want to slow down the .UK domain since its typically botnet zombies (again this is my observed pattern, not a comment on the UK domain), so longer greylist times for UK resident computers isn't exactly what I  want.

  _____  

From: milter-greylist@yahoogroups.com [mailto:milter-greylist@yahoogroups.com] On Behalf Of manu@...
Sent: Monday, March 05, 2007 2:09 AM
To: milter-greylist@yahoogroups.com
Subject: Re: [milter-greylist] Bug in domain matching in milter-greylist 3.0 (and at least 3.1.5)



Rick Adams <Rick.Adams@Cello. <mailto:Rick.Adams%40Cello.Net> Net> wrote:

> acl whitelist domain pix.net
> 
> fairly clear - I want to whitelist mail from "pix.net"
> 
> The surprise is that it also whitelists "epix.net"
> 
> I.e. it matches right most substrings instead of full domain "suffixes"

Yes, that has been a known oddity for a long time. It was never changed
to avoid burning people relying on the original behavior. The easiest
workaround is probably to use a regex...

> The biggest surprise is if you decide to have an acl based on
> country code top level domains (for me a very effective acl addition

If you get the latest 3.1.6 version, you get GeoIP support, which is
more reliable than matching TLD.

-- 
Emmanuel Dreyfus
http://hcpnet. <http://hcpnet.free.fr/pubz> free.fr/pubz
manu@netbsd. <mailto:manu%40netbsd.org> org

Rick Adams <Rick.Adams@...> wrote:

> I wouldn't characterize it as an oddity. I think it's a clear bug and I
> wasted a lot of time tracking it down.

The man page says:
       domain   This clause selects source machines based  on  their
       DNS name, performing  a  suffix search.

> at a minimum, the unexpected behavior should be better documented. Best
> case it should be a configurable option. I'll code it if you'll accept it.

Sure, a global setting would be fine. 

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...