gratuitous failure on host address bits not zero

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

gratuitous failure on host address bits not zero

Matthew Patton

in ./src/util/cidr_match.c there is this bit of code:

240         /*
241          * Sanity check: all host address bits must be zero.
242          */
243         for (np = ip->net_bytes, mp = ip->mask_bytes;
244              np < ip->net_bytes + ip->addr_byte_count; np++, mp++) {
245             if (*np & ~(*mp)) {
246                 mask_addr(ip->net_bytes, ip->addr_byte_count, ip->mask_shift);
247                 if (inet_ntop(ip->addr_family, ip->net_bytes, hostaddr.buf,
248                               sizeof(hostaddr.buf)) == 0)
249                     msg_fatal("inet_ntop: %m");
250                 vstring_sprintf(why ? why : (why = vstring_alloc(20)),
251                                 "non-null host address bits in \"%s/%s\", "
252                                 "perhaps you should use \"%s/%d\" instead",
253                                 pattern, mask, hostaddr.buf, ip->mask_shift);
254                 return (why);
255             }
256         }

Causing Postfix daemons to fall over and die is ridiculous just because an IP (eg. mynetworks) and provided mask doesn't result in only zeros. Print a warning, maybe. 


I don't see why cidr_match_parse() isn't written to be "liberal in what you accept, strict in what you return". It shouldn't care about stray bits during a compare, and should just memset(ip->mask_bytes, ...) and move on since the user's intent is clearly obvious. 


I love postfix but this struck me as a completely unnecessary failure mode.

 


If you wish to view the CPA Global group email disclaimer, please click here


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gratuitous failure on host address bits not zero

Wietse Venema
Matthew Patton:
> I love postfix but this struck me as a completely unnecessary failure mode.

Recent releases log this mistake as a warning:

    postfix/postmap[2328]: warning: cidr map /tmp/dict, line 1:
        non-null host address bits in "255.255.255.255/24", perhaps you
        should use "255.255.255.0/24" instead: skipping this rule

    postfix/smtpd[2355]: warning: mynetworks: non-null host address
        bits in "255.255.255.255/24", perhaps you should use
        "255.255.255.0/24" instead

    postfix/smtpd[2355]: NOQUEUE: reject: RCPT from
        tail.porcupine.org[168.100.189.3]: 451 4.3.0 <[hidden email]>:
        Temporary lookup failure; from=<> to=<wietse> proto=SMTP

The reason not to accept mail with this mistake in myetworks is
that it caused somone's system to become an open relay.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gratuitous failure on host address bits not zero

Bill Cole-3
In reply to this post by Matthew Patton
On 21 Jul 2017, at 15:50, Matthew Patton wrote:

> since the user's intent is clearly obvious.

Not always.

What is the clearly obvious intent of 192.0.2.8/28 or 192.0.2.31/27? How
should Postfix guess which part of the CIDR notation is wrong?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gratuitous failure on host address bits not zero

Matthew Patton


>> since the user's intent is clearly obvious.

> What is the clearly obvious intent of 192.0.2.8/28 or 192.0.2.31/27? How
> should Postfix guess which part of the CIDR notation is wrong?

I consider the netmask to be always primary - any bits set to the right of the mask are inconsequential and should be tossed. If the netmask is specified wrong (won't parse) or is /0 then it's automatic /32. As improbable as anything to the left of /8 would be, I don't think it's justified to meddle.


 


If you wish to view the CPA Global group email disclaimer, please click here


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gratuitous failure on host address bits not zero

Stefan Monnier
> I consider the netmask to be always primary - any bits set to the right of

Indeed, otherwise 192.168.0.0 would imply a /19


        Stefan
Loading...