On 2019-03-12 11:39:54 -0400, Wietse Venema wrote:
> Bill Cole:
> > On 12 Mar 2019, at 10:29, Wietse Venema wrote:
> > 
> > > Bill, I think that an IPv6 address ending in 0000 will work only in
> > > a cidr access map, because all other maps use string comparison.

After looking at the postfix source, I think that it might work with
2 tests if they are written in the "right" way (see below).

> > Did you notice the demo I included, using a hash map?
> 
> The postmap command does not know how the Postfix SMTP daemon converts
> an IPv6 address to string, which means that IPv6 address tests with
> the postmap command are valid only when using cidr maps.
> 
> The Postfix SMTP daemon looks up the same address form as the form
> that it logs in information about the remote SMTP client. For
> example, 2604:8d00:0:1::4 or 2001:41d0:1:88ce:: (these are real
> samples from my maillog files).

IMHO, the access(5) man page should be clarified to mention that
and also how truncating is done. So, what is in canonical form is
not the access map lookup key, but the IPv6 address. After that,
this is just a sequence of purely string operations.

The ":octetpair" in the man page is not clear because when the
IPv6 address is in compressed form, one may wonder what this means
when reaching a "::". If I understand correctly, the code that does
the checks is check_addr_access in src/smtpd/smtpd_check.c, which
has:

#ifdef HAS_IPV6
    if (strchr(addr, ':') != 0)
        delim = ':';
    else
#endif
        delim = '.';
[...]
    do {
[...]
    } while (split_at_right(addr, delim));

So, what is removed in the truncation is the last sequence starting
with ":", whatever it means (not necessarily an octet pair).

On my example, 2a04:5200:fff4::fe would be successively transformed
into:

2a04:5200:fff4:
2a04:5200:fff4
2a04:5200
2a04

(even though the first key, which ends with ":", is not in some usual
form). Am I right? If yes, this would mean that

2a04:5200:fff4:0 REJECT Blacklisted
2a04:5200:fff4:  REJECT Blacklisted

would be equivalent to 2a04:5200:fff4::/64 in a cidr table, because
"2a04:5200:fff4:0" would match an uncompressed 0 in the 4th octet
pair and "2a04:5200:fff4:" would match a compressed 0 in the 4th
octet pair.

BTW, I'm wondering why a canonical form is used for the match
instead of a form without compressed zeros. Wouldn't the latter
be more useful in practice, while not slower?

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Reply via email to