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, [EMAIL PROTECTED] wrote:
> http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4477
>
>
> [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
