[Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
bernd at petrovitsch.priv.at
Thu Feb 4 07:09:28 EST 2010
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.
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:22.214.171.124" and "::ffff:1234:5678" and inet_ntop(3) produces always
the "::ffff:126.96.36.199" 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
So the "compromise version" seems perfect (without looking at more
: Exploits are also made of this.
Bernd Petrovitsch Email : bernd at petrovitsch.priv.at
LUGA : http://www.luga.at
More information about the MIMEDefang