You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2005/07/11 22:52:46 UTC

[Bug 4477] New: IPV6 support for spamc

http://bugzilla.spamassassin.org/show_bug.cgi?id=4477

           Summary: IPV6 support for spamc
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: spamc/spamd
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: maddenj+spamassassin@skynet.ie


I've rewritten the connection code in libspamc to be protocol independant, so
it'll support both IPV4 and IPV6. It depends on struct addrinfo and
getaddrinfo() / getnameinfo(), and I don't know how available these are. They
seem to be supported under recent Unix and Windows, but it could be a problem on
older systems.

Patch to follow.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477





------- Additional Comments From jm@jmason.org  2006-06-29 19:47 -------
I think I have that coredump fixed btw in r418122.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477


felicity@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.1.4                       |3.2.0




------- Additional Comments From felicity@apache.org  2006-06-27 04:38 -------
I think this really ought to wait for 3.2 where we could have more comprehensive
IPv6 support, and it also seems like a big patch for the stable 3.1 line.  So
I'm changing the milestone.  I'm sure someone will let me know if they disagree. ;)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477


jm@jmason.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From jm@jmason.org  2006-06-29 20:59 -------
ok, investigated some more, and fixed some of Colm's issues from comment 14
in r418135.  changed:

- use NI_NUMERICSERV to list port numbers instead of names;
- use NI_MAXHOST and NI_MAXSERV where available;
- use getaddrinfo()'s built-in support for resolving the loopback address,
  without requiring a resolver.

however the max-hosts issue and the _randomize_hosts() issue are
still outstanding; not biggies though I think.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477


jm@jmason.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




------- Additional Comments From jm@jmason.org  2006-06-29 18:07 -------
Problems on the solaris zone:

t/spamc.....................Segmentation Fault - core dumped
# Failed test 1 in t/spamc.t at line 17
	Not found: spamc =  hello world 
# Failed test 2 in t/SATest.pm at line 599

http://buildbot.spamassassin.org/t-solaris-10/builds/134/test/0



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477





------- Additional Comments From jm@jmason.org  2006-06-29 13:24 -------
I agree with Theo.  we do need to apply it to 3.2.0 though -- it's still
unapplied...



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4477





------- Additional Comments From maddenj+spamassassin@skynet.ie  2005-07-11 13:55 -------
Created an attachment (id=3018)
 --> (http://bugzilla.spamassassin.org/attachment.cgi?id=3018&action=view)
IPV6 support for spamc

A short snip from a debug log :
Jul 11 21:28:58 localhost spamc[10589]: dbg: create socket(PF_INET6)
Jul 11 21:28:58 localhost spamc[10589]: dbg: connect(AF_INET6) to spamd (host
::1, port spamd) (try #1 of 3)
Jul 11 21:28:59 localhost spamc[10589]: dbg: create socket(PF_INET)
Jul 11 21:28:59 localhost spamc[10589]: dbg: connect(AF_INET) to spamd (host
127.0.0.1, port spamd) (try #1 of 3)
Jul 11 21:28:59 localhost spamc[10589]: dbg: connect(AF_INET) to spamd done
Jul 11 21:28:59 localhost spamd[7217]: connection from localhost.localdomain
[127.0.0.1] at port 56087

Speaking of which, DEBUG_LOG isn't defined anywhere, so I defined it to
LOG_DEBUG at the top of libspamc.c for the above output.

Appreciate any feedback. Anyone working on IPV6 for spamd?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Re: [Bug 4477] IPV6 support for spamc

Posted by Colm MacCarthaigh <co...@stdlib.net>.
Bugzilla is crawling along right now for me, forgive the direct mail;

The attached patch looks sorta o.k., but there are some easy fixes that
should be included;

Instead of 

+      char host[255]; /* hostname, for logging */
+      char port[255];

there should be;

	char host[NI_MAXHOST];
	char port[NI_MAXSERV];

those constants should be used in the call to getnameinfo() itself too
(dropping the sizeof(char) multiplications is safe too).

Based on the comments in the patch, it chooses returns service-names
where available (ie registered in /etc/services or whatever). Usually
this confuses users, but I'll leave that up to you guys as to whether
you want this or not. If not, ORing the last argument to getnameinfo
with NI_NUMERICSERV.

The lines;

+        getaddrinfo("localhost", port, &hints, &res);
+        tp->hosts[0] = res;

Don't really gel with what RFC3493 has in mind. Also by using the name
it depends on name-services working, which is a new dependency.
IN6ADDR_LOOPBACK_INIT may be better choices for this INADDR_LOOPBACK,
but that would considerable change to how the hosts array is managed.

There are two other things I thought I'd mention. One is how the
max-hosts stuff is done, eg;

	if(tp->nhosts == TRANSPORT_MAX_HOSTS) {

the patch makes hosts an array of linked-lists (which is what the
addrinfo structures are). When for example a DNS record with multiple A
records is used, the linked list will be expanded to that list of
records. So, even though the array may contain less than
TRANSPORT_MAX_HOSTS entries, there may be more actual hosts than that
stored overall, and hence more attempted connections.

This has a particularly strong effect on _randomize_hosts, which
basically becomes pointless for multi-entry DNS RRs. To keep traditional
behaviour, there really needs to be more changes to how hosts are
stored. Either store the hosts as a single large linked list, or a
single large array, but not a mixture of both :-)

On Mon, Jun 05, 2006 at 03:55:20PM +0000, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477
> 
> 
> felicity@apache.org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>    Target Milestone|3.1.3                       |3.1.4
> 
> 
> 
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> 

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477


felicity@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.1.3                       |3.1.4






------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477





------- Additional Comments From jm@jmason.org  2006-06-29 17:58 -------
hey Colm -- thx for the note.

let's see how we go with this -- I'd appreciate if everyone with access to
an odd platform, could give it a try; a simple "svn co", "perl Makefile.PL",
"make" should show up any major problems.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477


jm@jmason.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From jm@jmason.org  2006-06-29 17:57 -------
checked in, with trivial fix to spamc_l.t.

Sending        spamc/libspamc.c
Sending        spamc/libspamc.h
Sending        t/spamc_l.t
Transmitting file data ...
Committed revision 418101.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477


Bug 4477 depends on bug 4956, which changed state.

Bug 4956 Summary: IPv6 support for spamd
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4956

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477





------- Additional Comments From spamassassin@dostech.ca  2006-04-13 21:43 -------
I'd think that 3.1.2 would be way too early for any enhancements to spamd,
especially if we want to make a release in the next week or two.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477





------- Additional Comments From jm@jmason.org  2006-06-29 18:06 -------
hmm.  this may need some work still.  here's COlm's comment I missed:

> The attached patch looks sorta o.k., but there are some easy fixes that
> should be included;
>
> Instead of
>
> +      char host[255]; /* hostname, for logging */
> +      char port[255];
>
> there should be;
>
>         char host[NI_MAXHOST];
>         char port[NI_MAXSERV];
>
> those constants should be used in the call to getnameinfo() itself too
> (dropping the sizeof(char) multiplications is safe too).
>
> Based on the comments in the patch, it chooses returns service-names
> where available (ie registered in /etc/services or whatever). Usually
> this confuses users, but I'll leave that up to you guys as to whether
> you want this or not. If not, ORing the last argument to getnameinfo
> with NI_NUMERICSERV.
>
> The lines;
>
> +        getaddrinfo("localhost", port, &hints, &res);
> +        tp->hosts[0] = res;
>
> Don't really gel with what RFC3493 has in mind. Also by using the name
> it depends on name-services working, which is a new dependency.
> IN6ADDR_LOOPBACK_INIT may be better choices for this INADDR_LOOPBACK,
> but that would considerable change to how the hosts array is managed.
>
> There are two other things I thought I'd mention. One is how the
> max-hosts stuff is done, eg;
>
>         if(tp->nhosts == TRANSPORT_MAX_HOSTS) {
>
> the patch makes hosts an array of linked-lists (which is what the
> addrinfo structures are). When for example a DNS record with multiple A
> records is used, the linked list will be expanded to that list of
> records. So, even though the array may contain less than
> TRANSPORT_MAX_HOSTS entries, there may be more actual hosts than that
> stored overall, and hence more attempted connections.
>
> This has a particularly strong effect on _randomize_hosts, which
> basically becomes pointless for multi-entry DNS RRs. To keep traditional
> behaviour, there really needs to be more changes to how hosts are
> stored. Either store the hosts as a single large linked list, or a
> single large array, but not a mixture of both :-)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477





------- Additional Comments From colm@apache.org  2006-06-29 17:51 -------
getnameinfo() is not implemented ubiquitously, but as near as. http://svn.apache.org/repos/asf/apr/apr/
trunk/network_io/unix/apr_sockaddr.c has apr_getnameinfo though, which has a bunch of autoconf-
dependend workarounds for the remaining platforms (including the Windows/os2/beos flavours - ignore 
the unix in the directory name). 



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477





------- Additional Comments From radek@pld-linux.org  2006-06-20 19:02 -------
There was a comment on the dev list, linking for completness:
http://thread.gmane.org/gmane.mail.spam.spamassassin.devel/38391/focus=43854

Also, bug #4956 provides support for spamd.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477





------- Additional Comments From jm@jmason.org  2006-06-29 17:34 -------
scratch that -- it's a trivial fix to the test script, not a real bug...



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477


jm@jmason.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |4956






------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477





------- Additional Comments From maddoc@maddoc.net  2006-06-29 18:05 -------
Works for RH 7.2 an old platform but still in use quite a few places.

-Doc(In reply to comment #12)
> hey Colm -- thx for the note.
> 
> let's see how we go with this -- I'd appreciate if everyone with access to
> an odd platform, could give it a try; a simple "svn co", "perl Makefile.PL",
> "make" should show up any major problems.





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477


jm@jmason.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Undefined                   |3.1.2




------- Additional Comments From jm@jmason.org  2006-04-13 20:42 -------
oops, this got lost ;)  aiming at 3.1.2 (optimistically) so it gets another look



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477


jm@jmason.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.1.2                       |3.1.3




------- Additional Comments From jm@jmason.org  2006-04-14 09:55 -------
fair enough.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4477] IPV6 support for spamc

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477


jm@jmason.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #3018 is|0                           |1
           obsolete|                            |




------- Additional Comments From jm@jmason.org  2006-06-29 17:32 -------
Created an attachment (id=3564)
 --> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3564&action=view)
redo of patch against current svn trunk

here's an update of that patch, since part of it failed to apply against latest
svn trunk. my issues:

1. "struct addrinfo", getnameinfo() -- are those APIs widely-enough implemented
that we can count 100% on them being available on all platforms?  this code
doesn't have a fallback if they're not available, and spamc being unbuildable
counts as a critical issue...

2. spamc/libspamc.h should be including all header files required for "struct
addrinfo" to be declared.  I think that is the case as far as I can tell.

3. more seriously, "make test" fails: 

t/spamc_l....	Not found: connfailed =  spamc: connect(AF_INET) to spamd at
127.0.0.1 failed, retrying (#1 of 3): Connection refused
# Failed test 3 in t/SATest.pm at line 599
Output can be examined in: log/spamc_l.out
FAIL: Some other process running on port 8?  Test assumes nothing is listening
on port 8. at t/spamc_l.t line 6.
t/spamc_l....FAILED test 3
	Failed 1/3 tests, 66.67% okay

't/log/spamc_l.out' contains:

spamc: connect to spamd failed, retrying (#1 of 3): Connection refused
spamc: connect to spamd failed, retrying (#2 of 3): Connection refused
spamc: connect to spamd failed, retrying (#3 of 3): Connection refused
spamc: connection attempt to spamd aborted after 3 retries
hello world

anyway, I can't apply it with test failures :(



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.