[Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")

[Bernd Petrovitsch]

On Mit, 2010-02-03 at 12:32 -0800, - wrote:
[...]
> Using the latter-above code, $2 is the IPv4, and if $1 is anything
ACK, for real world use the "(" must be annotated so that $1 always is
the IPv4 address (or it's empty).
>  other than "::", then the address was not machine generated and it's
> likely that the message was manually tampered with (and thus spam).
Even if that´s the case, it shouldn't cause the software to fail or do
the wrong thing[0].

Apart from my believe into inet_ntop(3)/inet_pton(3) (similar to the
resident maintainer), I stumbled over too much buggy/broken software and
future changes to rely on text in standards or "this string always comes
out from $FUNCTION which is per definition correct".
Mainly because the last sentence really needs at least a "now" to be
correct and God knows what´s put in next year.

As for some real experiments:
inet_pton(3) on my F-12 glibc-2.11.1 actually accepts both of
"::ffff:1.2.3.4" and "::ffff:1234:5678" and inet_ntop(3) produces always
the "::ffff:1.2.3.4" version.
For normal/pure IPv6 addresses, inet_pton(3) also accepts both as long
as the dotted quad is at the end and inet_ntop(3) produces always the
pure IPv6 notation (is there a special name for it?).
So just finding a "." in the string doesn't qualify for the above IPv4
mapping.
So the "compromise version" seems perfect (without looking at more
source).

	Bernd

[0]: Exploits are also made of this.
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at