Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
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
":::1.2.3.4" and ":::1234:5678" and inet_ntop(3) produces always
the ":::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 : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
- wrote: [A bunch of silly nitpicks] Feel free to fork the code if you like. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
--- On Wed, 2/3/10, David F. Skoll wrote:
> Date: Wednesday, February 3, 2010, 12:56 PM - wrote:
> > Comments:
> >> if (strchr(data->hostip, '.')) {
>
> > This conditional is redundant.
>
> No, it is not. inet_ntop does not *have* to use the form
> :::a.b.c.d for IPv4-compatible addresses. It's allowed to do
> that, but not mandated to. It could use :::aabb:ccdd
That's not how I read the IPv6 RFC's. The routines must accept the alternate
forms for input, but the BNF specifies for these addresses that the mapped IPv4
address be shown. Such was NOT specified for the embedded address for 6to4.
RFC 1884, Section 2.2, especially subsection 3 (text formats). Although the
text may suggest agreement with you, it also highly suggests that IPv4 values
be expressed as per subsection 3 instead of the generic format of subsection 1.
RFCs 2373 and 3513 don't change this. However,
draft-main-ipaddr-text-rep-00.txt (May 2003) does say (section 4.2):
"For general-purpose use, common practice is to use lowercase, use
nearly the shortest possible representation, and to represent
IPv4-compatible and IPv4-mapped addresses using the embedded IPv4
address representation. This format has shown to be nearly optimal
for human comprehension of an address presented in isolation, and so
is RECOMMENDED when there are no strong considerations promoting a
different format. To generate this format:
o Use the embedded IPv4 address format for addresses in
:::0:0/96 (IPv4-mapped addresses), and in ::/96
(IPv4-compatible addresses) except for :: (the unspecified
address) and ::1 (the loopback address) which are not
IPv4-compatible addresses."
Therefore, although not a requirement, all value->text converters SHOULD be
using the dotted format for generation of these IPv4 mappings.
Technically, the syntax is incomplete and derives from general usage. Usage
says that for these IPv4 embedded addresses, use the format that shows the IPv4
address (inside the IPv6 address), which is NOT a requirement for 6in4
(2002::/16).
RFC 4291 did not insist on a preference and parroted RFC 3513 except for
depreciating the IPv4-compatibles. It does refer IPv4-mapped usage to RFC
4038, but that RFC doesn't address this case. RFC 3986 didn't express a
preference either.
> If an implementation's inet_ntop does not do it... well, too bad. The
> Perl code ends up seeing an IPv6 address.
True, but it could be an embedded IPv4 address. As you didn't provide decoding
for such, you're not really treating the subsection 3 format as an "optional"
format and should be decoding both. For input, we must accept both formats,
yet your code only accepts specification #3.
A strong implication from these RFCs is that the best human-readable form be
chosen for any address. Therefore, for an IPv4-mapped address, the form
showing the IPv4 address is what should be generated over any other.
As we're using standardized functions, what do they say:
inet_ntop(3) - bugs:
AF_INET6 converts IPv6-mapped IPv4 addresses into an IPv6 format.
inet_pton(3) - bugs:
AF_INET6 does not recognize IPv4 addresses. An explicit IPv6-mapped IPv4
address must be supplied in src instead.
Therefore, we will either always or never see the IPv4-literal-embedded format,
and furthermore, trying to manipulate the text output is BAD.
> >
> >
> char const *lastcolon =
> strrchr(data->hostip, ':');
> > if
> (lastcolon)
> >
> strncpy((char
> *)data->hostip,++lastcolon,16);
> > }
> >
>
> > We don't need the while loop which is UNBOUNDED by length.
>
> Again... I trust inet_ntop. And I don't write code that tries to cope
> with hardware faults because that's impossible by definition.
>
> strncpy(), btw, is a horrible function because it's not guaranteed to
> zero-terminate the result. Yes, I know that can "never" happen in this
> case, but an unbounded loop can also "never" happen.
Which is easier to read? Which is faster?
If we're going to be consistent WITHOUT regard to which text representation is
used, I suggest that we take the IPv6 text, convert it to its internal 128-bit
representation in network order, extract the 32 LSBs, and convert that back to
text using the IPv4 conversion routines. I think that's the ONLY way we can
guarentee a consistent conversion 100% of the time.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
- wrote:
> Comments:
>> if (strchr(data->hostip, '.')) {
> This conditional is redundant.
No, it is not. inet_ntop does not *have* to use the form
:::a.b.c.d for IPv4-compatible addresses. It's allowed to do
that, but not mandated to. It could use :::aabb:ccdd
If an implementation's inet_ntop does not do it... well, too bad. The
Perl code ends up seeing an IPv6 address.
>
> char const *lastcolon = strrchr(data->hostip, ':');
> if (lastcolon)
> strncpy((char *)data->hostip,++lastcolon,16);
> }
>
> We don't need the while loop which is UNBOUNDED by length.
Again... I trust inet_ntop. And I don't write code that tries to cope with
hardware faults because that's impossible by definition.
strncpy(), btw, is a horrible function because it's not guaranteed to
zero-terminate the result. Yes, I know that can "never" happen in this case,
but an unbounded loop can also "never" happen.
Regards,
David.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
--- On Wed, 2/3/10, David F. Skoll wrote:
> Here's my compromise on the IPv4-mapped IPv6 address question:
>
> if (tmp) {
> if (IN6_IS_ADDR_V4MAPPED(&in6sa->sin6_addr) ||
> IN6_IS_ADDR_V4COMPAT(&in6sa->sin6_addr)) {
> if (strchr(data->hostip, '.')) {
> char const *lastcolon = strrchr(data->hostip, ':');
> char *dst = data->hostip;
> while(lastcolon) {
> lastcolon++;
> *dst++ = *lastcolon;
> if (!*lastcolon) break;
> }
> }
> }
> }
Comments:
> if (strchr(data->hostip, '.')) {
This conditional is redundant. IF we have a V4 embedded address, we already
know this is true (for all machine-generated text address forms).
char const *lastcolon = strrchr(data->hostip, ':');
if (lastcolon)
strncpy((char *)data->hostip,++lastcolon,16);
}
We don't need the while loop which is UNBOUNDED by length. Text IPv4 addresses
are never longer than 16 characters including the terminator. With memory
corruption, your while loop could run forever/indefinently, while strncpy will
always terminate. If it weren't for the fact that the address source is from a
library routine, I would have suggested length checking too.
I wasn't certain if the type-casting on data->hostip was needed, so I did it
anyway.
> So we only do the evil hack if IN6_IS_ADDR_V4MAPPED or
> IN6_IS_ADDR_V4COMPAT returns true. I think that should be pretty
> safe... if we can't trust our system's own inet_ntop function, we're
> in trouble anyway.
I agree.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
--- On Wed, 2/3/10, Bernd Petrovitsch wrote:
> On Die, 2010-02-02 at 17:49 -0800, - wrote:
> > Try this regex for detecting an IPv4-compatible IPv6 address:
> >
> > ... =~ qr/^:::(\d{1,3}(\.\d{1,3}){3})$/i ...
>
> To get even more anal: No one forbids to avoid the leading "::" or
> write the optional "0" before and(or after it. So that could be
> snip
> ... =~
> qr/^((0+:)*::(0+:)*|(0+:){6}):(\d{1,3}(\.\d{1,3}){3})$/i
> ...
A human may write that, but the routines for converting IPv6 to text never
will. They will output only in the first format appearing above, even if the
latter is a possible equivalent. The leading zero-quads will never appear in a
machine generated address.
Using the latter-above code, $2 is the IPv4, and if $1 is anything other than
"::", then the address was not machine generated and it's likely that the
message was manually tampered with (and thus spam).
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
Hi,
Here's my compromise on the IPv4-mapped IPv6 address question:
if (tmp) {
if (IN6_IS_ADDR_V4MAPPED(&in6sa->sin6_addr) ||
IN6_IS_ADDR_V4COMPAT(&in6sa->sin6_addr)) {
if (strchr(data->hostip, '.')) {
char const *lastcolon = strrchr(data->hostip, ':');
char *dst = data->hostip;
while(lastcolon) {
lastcolon++;
*dst++ = *lastcolon;
if (!*lastcolon) break;
}
}
}
}
So we only do the evil hack if IN6_IS_ADDR_V4MAPPED or
IN6_IS_ADDR_V4COMPAT returns true. I think that should be pretty
safe... if we can't trust our system's own inet_ntop function, we're
in trouble anyway.
Comments welcomed.
Regards,
David.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
On Mit, 2010-02-03 at 07:01 -0500, David F. Skoll wrote: > Bernd Petrovitsch wrote: > > > Perhaps reason enough to simply use Net::IP. > > What, from C? :) Oops, sorry, I had the impression it´s in the perl part. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
Bernd Petrovitsch wrote: > Perhaps reason enough to simply use Net::IP. What, from C? :) As I said... patches (in C) accepted happily. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
- wrote:
> Try this regex for detecting an IPv4-compatible IPv6 address:
> ... =~ qr/^:::(\d{1,3}(\.\d{1,3}){3})$/i ...
How about some C code rather than perl?
-- David.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
On Die, 2010-02-02 at 17:49 -0800, - wrote:
> Try this regex for detecting an IPv4-compatible IPv6 address:
>
> ... =~ qr/^:::(\d{1,3}(\.\d{1,3}){3})$/i ...
To get even more anal:
No one forbids to avoid the leading "::" or write the optional "0"
before and(or after it. So that could be
snip
... =~ qr/^((0+:)*::(0+:)*|(0+:){6}):(\d{1,3}(\.\d{1,3}){3})$/i ...
snip
Caveat emptor 1: Not tested etc.
Caveat emptor 2: Since (normal) regexps can't calculate, we cannot avoid
getting false positives with too many 0 with "(0+:)*::(0+:)*" for an
IPv6 address.
Perhaps reason enough to simply use Net::IP.
And if Net::IP gets it wrong, we can blame them (and send a patch).
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly [offtopic]
--- On Tue, 2/2/10, Michiel Brandenburg wrote: >... > Oh no .. don't tell me there is another conversion coming > up .. damn there goes my holiday. If you're calling it a "holiday" instead of a vacation, you've already converted (or have been converted). ;-) ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible "patch")
Try this regex for detecting an IPv4-compatible IPv6 address:
... =~ qr/^:::(\d{1,3}(\.\d{1,3}){3})$/i ...
That should be more precise than strchr(...,'.'); $1 should be the IPv4
address that was extracted.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly [offtopic]
On Tue, Feb 02, 2010 at 09:22:40PM +0100, Michiel Brandenburg wrote: Btw .. (this might hurt) any word on integrating File-VirusScan into mimedefang :) ? As I remember there was some talk about it way back. Heh... not for the next release. Or, depending on your point of view, it's already there -- File::VirusScan is, pretty much, the guts of the MIMEDefang virus scanning integration refactored into a more modular and extensible framework. Unfortunately, it doesn't yet plug back in to MIMEDefang. Cheers, Dave -- Dave O'Neill Roaring Penguin Software Inc. +1 (613) 231-6599http://www.roaringpenguin.com/ For CanIt technical support, please mail: supp...@roaringpenguin.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly
On Die, 2010-02-02 at 13:09 +0100, Michiel Brandenburg wrote: > On 2-2-2010 11:34, Bernd Petrovitsch wrote: > >> # taken from Net::IP, and converted to use no external, and handle no > >> padding > > > > Hmm, any special reason for not using Net::IP directly? > > Or did I miss something? > That could be done without a problem but I did not want to bloat > mimedefang.pl anymore than strictly needed. I have checked all modules > that are used by default and none seem to need Net::IP so to add another > dependency just to reverse some addresses was pointless. > > On a side note Net::IP is not installed per default (at least on my > debian machines) so adding another package there .. . Well, I don't think that the default packages of some Linux distribution (even if it's Debian - which is not the whole world) should decide if one either copies the code (and bugs) or uses the lib/module. Apart from that RHEL5/CentOS-5 (and thus Fedora since F6) have it in the core repo (if I interpret the output from `rpm -qi perl-Net-IP` correctly. But I activate/use usually also the kbsingh, epel, rpmfusion and rpmforge repos - if only for CPAN modules). > It would be good to use some more functions from Net::IP notably tests > to see what is ipv6 / ipv4 cause all beat /:/ and /\./ :) That could be the other to use it in the core MD code too. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly [offtopic]
On 2-2-2010 20:49, David F. Skoll wrote: Ah, true. Well... the database I use (PostgreSQL) has a "network" type that accepts both IPv4 and IPv6 addresses. I'm not sure what the database I don't use (MySQL) does (or if it even has a network type.) Yea I noticed that too MySQL can store ipv4 (as a numeric value) and there is some hacked support for ipv6 but PostgreSQL wow .. damn why did I not take a look at that before, gonna save me soo much work. We'll all be using IPv6 when the United States uses SI units in everyday commerce. :( Oh no .. don't tell me there is another conversion coming up .. damn there goes my holiday. Don't worry about it... I've integrated a modified version of your patch into our development version. I'm travelling next week, but hope to release a (final?) MIMEDefang 2.68-beta after I return. Can't wait, will try to see if I can add some extra patches :) hehe. Btw .. (this might hurt) any word on integrating File-VirusScan into mimedefang :) ? As I remember there was some talk about it way back. Regards, -- Michiel ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly
- wrote: > I really don't like that code, even if it happens to work. Patches accepted. Get your patch in while 2.68 is still in beta... :) Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly
--- On Tue, 2/2/10, David F. Skoll wrote:
> ...
> Actually, the Perl code will never see an IPv6-mapped IPv4 address,
> because the mimedefang.c code converts such an address to "pure"
> IPv4:
>
> /* Convert IPv6-mapped IPv4 address to pure IPv4.
> That is: :::xxx.yyy.zzz.www to simply xxx.yyy.zzz.www */
> if (tmp) {
> if (strchr(data->hostip, '.')) {
> char const *lastcolon = strrchr(data->hostip, ':');
> char *dst = data->hostip;
> while(lastcolon) {
> lastcolon++;
> *dst++ = *lastcolon;
> if (!*lastcolon) break;
> }
> }
> }
I really don't like that code, even if it happens to work. One should really
check for the "^:::" prefix followed by 3 dots between 4 sequences of
numbers "\d{1,3}" which individually should be checked for range (0-255). I'll
let you build the proper regex.
The while loop is unnecessary. Once we have "lastcolon" not null, shouldn't
this work: "strncpy(dst, ++lastcolon, 16);"? 16 => 15 text characters plus
the terminator. To have a valid result, we should have 7 <= strlen(dst) <=15.
If less than 7 or more than 15, the string can't be a valid IPv4.
I think that the code is a bit too trusting in that only an embedded IPv4 will
be the ONLY IPv6 address with an embedded period. There may be something else
in the future that could be created:
e.g. 2002:192.0.2.0::1 (a new way of specifying 6in4 - currently not allowed).
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly
Michiel Brandenburg wrote: > Well database and code could only assume that they get ipv6 addresses. Ah, true. Well... the database I use (PostgreSQL) has a "network" type that accepts both IPv4 and IPv6 addresses. I'm not sure what the database I don't use (MySQL) does (or if it even has a network type.) > But then I guess there is no one stopping you encoding all ipv4 as 6 :) Right. I think that's what PostgreSQL may do... not sure. I'd have to test to see if it preserves IPv4-ness vs. IPv6-ness for the same address depending on the input syntax. > and I guess we can revisit when more of the world is using ipv6 .. like > in 100 years :) We'll all be using IPv6 when the United States uses SI units in everyday commerce. :( > I will see when I can get the patch altered not to take into account the > ipv6 mapped ipv4, as the c code handles that part. Don't worry about it... I've integrated a modified version of your patch into our development version. I'm travelling next week, but hope to release a (final?) MIMEDefang 2.68-beta after I return. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly
On 2-2-2010 19:01, David F. Skoll wrote: In other words, what is the difference between an SMTP client coming from ":::192.168.10.1" or "192.168.10.1" ? or :::c0a8:a01. Well not a lot I would guess except that one is ipv6 the other ipv4. Guess it all depends on semantics .. probably nothing functional but I thought I would bring it up. I made the C code recognize mapped IPv4 addresses and convert them to plain IPv4 addresses to simplify the filter code. If you get an IPv4 address, fine... you can handle it. Similarly, if you get an IPv6 address, you don't need to worry about the (IMO hackish and ugly) IPv4-mapped special case. No questions remarks there :) Say you are on a ipv4 only network you would never receive those addresses while if you are on a ipv6 only network all of a sudden you might get data from an ipv4 address (but you are ipv6 only), that might throw a spanner in the works. How so? Well database and code could only assume that they get ipv6 addresses. But then I guess there is no one stopping you encoding all ipv4 as 6 :) and I guess we can revisit when more of the world is using ipv6 .. like in 100 years :) I doubt any RBL would list the IPv6-variant without also listing the IPv4 variant. I have yet to use RBL's that even deal with ipv6 let alone ipv4 mapped variants. I will see when I can get the patch altered not to take into account the ipv6 mapped ipv4, as the c code handles that part. Regards, -- Michiel Brandenburg ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly
Michiel Brandenburg wrote: > Is that a good approach btw ? Ipv6 mapped ipv4 address are ipv6 not ipv4 > addresses in the strictest terms, no? In what way are they not? In other words, what is the difference between an SMTP client coming from ":::192.168.10.1" or "192.168.10.1" ? I made the C code recognize mapped IPv4 addresses and convert them to plain IPv4 addresses to simplify the filter code. If you get an IPv4 address, fine... you can handle it. Similarly, if you get an IPv6 address, you don't need to worry about the (IMO hackish and ugly) IPv4-mapped special case. > Say you are on a ipv4 only network you would never receive those > addresses while if you are on a ipv6 only network all of a sudden you > might get data from an ipv4 address (but you are ipv6 only), that might > throw a spanner in the works. How so? > For checking RBL lists it might be interesting to check both the ipv4 > and the ipv6 variant of the same address. But to do that you would need > the ipv6 variant :), dunno if it's worth changing or how much would > break if it were changed. I doubt any RBL would list the IPv6-variant without also listing the IPv4 variant. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly
On 2-2-2010 15:37, David F. Skoll wrote:
+if( $ip[$_] =~ /\./ ) {
+# ipv4 mapped as ipv6
+my @extraOcts = unpack('H4H4', pack('C4C4C4C4', split(/\./,
Actually, the Perl code will never see an IPv6-mapped IPv4 address, because
the mimedefang.c code converts such an address to "pure" IPv4:
Ahh good to know ... there u go .. in a mixed environment ( c and perl )
u never know where to look :)
Is that a good approach btw ? Ipv6 mapped ipv4 address are ipv6 not ipv4
addresses in the strictest terms, no? I though the only way you could
receive these types of hybrid addresses were if you are ipv6 only and
your client is ipv4 only (with a transparent ipv4 -> ipv6 gateway in
between somewhere).
Say you are on a ipv4 only network you would never receive those
addresses while if you are on a ipv6 only network all of a sudden you
might get data from an ipv4 address (but you are ipv6 only), that might
throw a spanner in the works.
The ipv6 mapped ipv4 should only happen on a hybrid or ipv6 only stack.
For checking RBL lists it might be interesting to check both the ipv4
and the ipv6 variant of the same address. But to do that you would need
the ipv6 variant :), dunno if it's worth changing or how much would
break if it were changed.
Lemme know what you guys think, my ipv6 knowledge is not that up to
date, I can refactor the patch if needed, or better yet change the patch
so we can check both ipv4 and ipv6 if we want.
--
Michiel
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly
Michiel Brandenburg wrote:
+if( $ip[$_] =~ /\./ ) {
+# ipv4 mapped as ipv6
+my @extraOcts = unpack('H4H4', pack('C4C4C4C4', split(/\./,
Actually, the Perl code will never see an IPv6-mapped IPv4 address, because
the mimedefang.c code converts such an address to "pure" IPv4:
/* Convert IPv6-mapped IPv4 address to pure IPv4. That is:
:::xxx.yyy.zzz.www to simply xxx.yyy.zzz.www */
if (tmp) {
if (strchr(data->hostip, '.')) {
char const *lastcolon = strrchr(data->hostip, ':');
char *dst = data->hostip;
while(lastcolon) {
lastcolon++;
*dst++ = *lastcolon;
if (!*lastcolon) break;
}
}
}
Regards,
David.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly
On 2-2-2010 11:34, Bernd Petrovitsch wrote: # taken from Net::IP, and converted to use no external, and handle no padding Hmm, any special reason for not using Net::IP directly? Or did I miss something? That could be done without a problem but I did not want to bloat mimedefang.pl anymore than strictly needed. I have checked all modules that are used by default and none seem to need Net::IP so to add another dependency just to reverse some addresses was pointless. On a side note Net::IP is not installed per default (at least on my debian machines) so adding another package there .. . It would be good to use some more functions from Net::IP notably tests to see what is ipv6 / ipv4 cause all beat /:/ and /\./ :) -- Michiel Brandenburg ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] [Patch] relay_is_* not ipv6 friendly
Hi! On Mon, 2010-02-01 at 21:26 +0100, Michiel Brandenburg wrote: [...] > I recently noticed the relay_is_* functions within mimdefang.pl do not > playing nice with ipv6 addresses. This patch fixes it. Not that a lot > of mail is running ipv6 over here but there is always hope :) ># taken from Net::IP, and converted to use no external, and handle no padding Hmm, any special reason for not using Net::IP directly? Or did I miss something? Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] [Patch] relay_is_* not ipv6 friendly
Hiya all,
I recently noticed the relay_is_* functions within mimdefang.pl do not
playing nice with ipv6 addresses. This patch fixes it. Not that a lot
of mail is running ipv6 over here but there is always hope :)
--
Michiel Brandenburg
--- mimedefang.pl.original 2010-01-31 23:10:14.0 +0100
+++ mimedefang.pl 2010-02-01 01:58:43.0 +0100
@@ -1487,6 +1487,104 @@ sub action_notify_administrator ($) {
}
#***
+# %PROCEDURE: ip_expand_address
+# %ARGUMENTS:
+# ip -- IPv6 / IPv4 address.
+# ip_version -- what kind of ip is it ? 4 or 6
+# pad -- pad fully optional 1 or 0 (only for ip 6) defaul 0
+# %RETURNS:
+# the fully expanded version of ipv6
+# %EXAMPLE:
+# 2001:888:1f59::1:7d,6 => 2001:888:1f59:0:0:0:1:7d
+# 2001:888:1f59::1:7d,6,1 => 2001:0888:1f59::::0001:007d
+# :::192.168.89.9,6 => 0:0:0:0:0::c0a8:5909
+#***
+# taken from Net::IP, and converted to use no external, and handle no padding
+sub ip_expand_address
+{
+my $ip = shift;
+my $ip_version = shift;
+my $pad = shift || 0;
+
+unless( $ip_version ) {
+return $ip;
+}
+
+# v4 : add .0 for missing quads
+if ($ip_version == 4) {
+my @quads = split /\./, $ip;
+my @clean_quads = (0, 0, 0, 0);
+foreach my $q (reverse @quads) {
+unshift(@clean_quads, $q + 1 - 1);
+}
+return (join '.', @clean_quads[ 0 .. 3 ]);
+}
+
+# reuse our pad var.
+if ( $pad ) { $pad = 4;}
+else { $pad = 1; }
+
+# tag ::
+$ip =~ s/::/:!:/;
+my @ip = split(/:/,$ip);
+my $num = scalar(@ip) - 1;
+foreach( 0 .. (scalar(@ip) -1 )) {
+if( $ip[$_] =~ /\./ ) {
+# ipv4 mapped as ipv6
+my @extraOcts = unpack('H4H4', pack('C4C4C4C4', split(/\./,
ip_expand_address($ip[$_], 4;
+# remove leading 0's if not padding to 4
+if ( $pad eq 1 ) {
+$extraOcts[0] =~ s/^0*(.+)$/$1/;
+$extraOcts[1] =~ s/^0*(.+)$/$1/;
+}
+$ip[$_] = join(':', @extraOcts);
+# converting creates one more octet increase to compensate
+$num++;
+next();
+}
+$ip[$_] = ('0' x ($pad - length($ip[$_]))) . $ip[$_];
+}
+$ip = join(':', @ip);
+# handle the :: (now converted to 000! or stayed !)
+my $search = '0' x ($pad - 1) . '!:';
+my $missing = ( ('0' x $pad . ':') x (8 - $num));
+$ip =~ s/$search/$missing/;
+return $ip;
+}
+
+#***
+# %PROCEDURE: reverse_addr
+# %ARGUMENTS:
+# addr -- IPv4 / IPv6 Address
+# %RETURNS:
+# the fully expanded reverse of addr suitable for rbl lookups
+# %EXAMPLE:
+# 2001:888:1f59::1:7d =>
+#6.2.4.1.0.2.e.f.f.f.1.2.3.1.2.0.b.e.d.0.2.0.2.0.8.b.1.4.1.0.0.2
+# 127.0.0.1 => 1.0.0.127
+#***
+sub reverse_addr
+{
+my ($addr) = @_;
+my $type = 4;
+if ( $Features{"Net::DNS"} && Net::DNS::Resolver::Base::_ip_is_ipv6($addr)
) {
+ $type = 6;
+}
+elsif ( !$Features{"Net::DNS"} && $addr =~ /:/) {
+ # no Net::DNS available guessed instead
+$type = 6;
+}
+if ( $type eq 6 ) {
+$addr = ip_expand_address($addr, 6, 1);
+$addr =~ s/://g;
+return join('.', split(//, reverse($addr)));
+}
+# ipv4
+my($a, $b, $c, $d) = split(/\./, $addr);
+return "$d.$c.$b.$a";
+}
+
+#***
# %PROCEDURE: relay_is_blacklisted
# %ARGUMENTS:
# addr -- IP address of relay host.
@@ -1497,8 +1595,7 @@ sub action_notify_administrator ($) {
sub relay_is_blacklisted ($$) {
my($addr, $domain) = @_;
# Reverse IP address
-my($a, $b, $c, $d) = split(/\./, $addr);
-$addr = "$d.$c.$b.$a.$domain";
+$addr = reverse_addr( $addr ) . ".$domain";
my $hn;
$hn = gethostbyname($addr);
return 0 unless defined($hn);
@@ -1543,8 +1640,7 @@ sub relay_is_blacklisted_multi (;$)
my %sock_to_domain;
# Reverse the address
-my($a, $b, $c, $d) = split(/\./, $addr);
-$addr = "$d.$c.$b.$a";
+$addr = reverse_addr($addr);
# If user did not pass in a Net::DNS::Resolver object, generate one.
unless (defined($res and (UNIVERSAL::isa($res, "Net::DNS::Resolver" {
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
