From: jhsys on
I get a Segmentation fault when trying to send auto-replies back to a
couple of domains
(such as bigboobfund.com, bighotpay.com, fundtreesite.com).

--8<--
Running /var/spool/mqueue/problem/nAPA9rM1031062 (sequence 1 of 1)
<testmail(a)bighotpay.com>... Connecting to bighotpay.com. via esmtp...
Segmentation fault

--8<--

What I have found, these domains have a LOT of A records (around 64)
for their domain, and no mx.

I am running the latest updates for
Red Hat Enterprise Linux ES release 4 (Nahant Update 8)
sendmail-8.13.1-3.3.el4

What is going wrong with sendmail in this case?
Possible fixes? (could be sendmail 8.14, but not highest on the todo
list yet)
From: Claus Aßmann on
jhsys wrote:
> I get a Segmentation fault when trying to send auto-replies back to a

Don't (auto)reply to spammers...

> Red Hat Enterprise Linux ES release 4 (Nahant Update 8)

There's your problem...

> What is going wrong with sendmail in this case?

Nothing. The problem is in the Linux resolver library.
It returns a host entry without addresses.

8.14.4 will have a workaround for that -- check ftp.sendmail.org
(next week?) for Beta2, or try this patch:

diff -u -r sendmail-8.14.4.Beta1/sendmail/daemon.c sendmail-8.14.4.Beta2/sendmail/daemon.c
--- sendmail-8.14.4.Beta1/sendmail/daemon.c Wed Feb 13 16:20:26 2008
+++ sendmail-8.14.4.Beta2/sendmail/daemon.c Tue Oct 27 10:02:39 2009
@@ -2342,7 +2343,7 @@
}
}
gothostent:
- if (hp == NULL)
+ if (hp == NULL || hp->h_addr == NULL)
{
#if NAMED_BIND
/* check for name server timeouts */

From: Nik on
On Nov 26, 7:18 am, jhsys <jhsy...(a)gmail.com> wrote:
> I get a Segmentation fault when trying to send auto-replies back to a
> couple of domains
>  (such as bigboobfund.com, bighotpay.com, fundtreesite.com).
>
> --8<--
> Running /var/spool/mqueue/problem/nAPA9rM1031062 (sequence 1 of 1)
> <testm...(a)bighotpay.com>... Connecting to bighotpay.com. via esmtp...
> Segmentation fault


I've been seeing this too; just got around to debugging it. Looks
like a resolver bug that only happens with INET6 (possibly due to DNS
config of these bozos) and 32 bit binaries. If the test program below
is built on a 64 bit system, or if it's not asked to return INET6,
then h_addr_list[0] is a valid pointer and thus no segv.

Thanks for the patch Claus. Were you going to poke the Linux resolver
people?



#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <netdb.h>
#include <resolv.h>

int main(int argc, char* argv[]) {
struct hostent *hp = 0;
res_init();
_res.options |= RES_USE_INET6;
hp = gethostbyname("hotnewsin.com.");
if (!hp) {
printf ("No return, h_errno = %d\n",h_errno);
} else {
printf("Success; hp->h_addrtype = %d\n",hp->h_addrtype);
printf("hp->h_length = %d\n",hp->h_length);
printf("hp->h_addr_list[0] = %lx\n",hp->h_addr_list[0]);
}
}
From: Claus Aßmann on
Nik wrote:

> I've been seeing this too; just got around to debugging it. Looks
> like a resolver bug that only happens with INET6 (possibly due to DNS
> config of these bozos) and 32 bit binaries. If the test program below
> is built on a 64 bit system, or if it's not asked to return INET6,
> then h_addr_list[0] is a valid pointer and thus no segv.

Thanks for tracking this down!

> Thanks for the patch Claus. Were you going to poke the Linux resolver
> people?

Please feel to do so as you wrote a nice small program to demonstrate
the problem. I have no intentions to do this myself but there might be
others that will do so based on the mails I got. If there are several
"complaints", (the Linux resolver) people might listen.
From: Nik on
On Dec 3, 8:15 pm, Claus Aßmann <ca+sendmail(-no-copies-please)
@mine.informatik.uni-kiel.de> wrote:

> Nik  wrote:
> > Thanks for the patch Claus.  Were you going to poke the Linux resolver
> > people?
>
> Please feel to do so as you wrote a nice small program to demonstrate
> the problem. I have no intentions to do this myself but there might be
> others that will do so based on the mails I got. If there are several
> "complaints", (the Linux resolver) people might listen.

One of our support staff has filed a bugzilla -
https://bugzilla.redhat.com/show_bug.cgi?id=545160

Nothing interesting there yet...