Valdis,
Thanks a lot for your response--I haven't fixed the problem, but maybe
I've pinpointed it a little better. Here's where it stands:
> The most suspicious thing I see here is this:
>
> | Nov 7 16:45:35 relay=davenport0 [192.168.0.200]
> | Nov 7 16:45:35 relay=vm.se.lsoft.com. [24.147.1.10]
>
> So your address is in the 192.168/16 NAT space from RFC1918, and the
> destination is in a public address space. This certainly sounds like
> your NAT gateway has gotten good and seriously hosed up, and is refusing
> to NAT certain addresses correctly. The quick counter-check for this is
> to just run 'telnet 24.147.1.10 25' and see if you get an SMTP banner
> back. If this works, then your NAT and network are in OK shape.
I tried 'telnet 24.147.1.10 25', and sure enough, it failed. But the IP
address looked kind of familiar, and when I did a reverse DNS lookup, I
found out that 24.147.1.10 is an address that belongs to AT&T Broadband,
which is my ISP. The IP for vm.se.lsoft.com is actually 194.52.19.4,
which I can telnet to and get the SMTP banner. After looking through the
maillog, it turns out that for *all* rejected emails, sendmail had
substituted 24.147.1.10 for the relay's actual IP address. What's going
on here?!?
I thought sendmail might be hosed, so I stopped and restarted it (don't
know why I didn't think to try that before). I check /var/log/maillog and
voila!, backed up emails are getting delivered:
| Nov 13 10:09:15 davenport0 sendmail[26110]: alias database /etc/aliases rebuilt by bkuo
| Nov 13 10:09:15 davenport0 sendmail[26110]: /etc/aliases: 75 aliases, longest 75 bytes, 3103 bytes total
| Nov 13 10:09:15 davenport0 sendmail[26122]: starting daemon (8.11.6): SMTP+queueing@01:00:00
| Nov 13 10:09:25 davenport0 sendmail[26125]: gAD400u24588: to=<[log in to unmask]>, delay=11:09:24, xdelay=00:00:00, mailer=esmtp, pri=1110307, relay=vms.dc.lsoft.com. [209.119.1.27], dsn=2.0.0, stat=Sent (Ok, message queued (544 bytes))
| Nov 13 10:09:28 davenport0 sendmail[26125]: gACLjWu23531: to=<[log in to unmask]>, delay=17:23:56, xdelay=00:00:01, mailer=esmtp, pri=1741512, relay=vm.lsoft.se. [194.52.19.4], dsn=2.0.0, stat=Sent (Mail Delivered)
| Nov 13 10:09:44 davenport0 sendmail[26125]: gAC400u20960: to=<[log in to unmask]>, delay=1+11:09:44, xdelay=00:00:01, mailer=esmtp, pri=3270307, relay=vms.dc.lsoft.com. [209.119.1.27], dsn=2.0.0, stat=Sent (Ok, message queued (544 bytes))
| .
| .
| .
| Nov 13 10:12:01 davenport0 sendmail[26125]: gA8LjLu29395: to=<[log in to unmask]>, delay=4+17:26:40, xdelay=00:00:01, mailer=esmtp, pri=10381506, relay=vm.lsoft.se. [194.52.19.4], dsn=2.0.0, stat=Sent (Mail Delivered)
Problem is solved...? Nope. If I try to send email to a test mailing
list, the emails are refused again because it is trying to use 24.147.1.10
as the correct relay IP address again. Restarting sendmail allows the
email to get delivered.
Just to confirm that the problem only happens with Listserv email, I do
the following: I create a test list with one recipient,
[email]@post.harvard.edu.
I first send a test message directly to [email]@post.harvard.edu. It goes
through fine, and the IP address of post.harvard.edu used in relaying is
correct [128.103.219.45]:
| Nov 13 10:52:09 davenport0 sendmail[26912]: gADFq9H26912: from=<[log in to unmask]>, size=283, class=0, nrcpts=1, msgid=<[log in to unmask]>, proto=ESMTP, relay=bkuo@localhost
| Nov 13 10:52:09 davenport0 sendmail[26914]: gADFq9H26912: to=<[email]@post.harvard.edu>, ctladdr=<[log in to unmask]> (500/500), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=30283, relay=post.harvard.edu. [128.103.219.45], dsn=2.0.0, stat=Sent (KAA10710 Message accepted for delivery)
Next, I send a message to the test list, which receives and processes it:
| Nov 13 10:52:20 davenport0 sendmail[26921]: gADFqKg26921: from=<[log in to unmask]>, size=297, class=0, nrcpts=1, msgid=<[log in to unmask]>, proto=ESMTP, relay=bkuo@localhost
| Nov 13 10:52:20 davenport0 sendmail[26922]: gADFqKg26922: clone gADFqKg26921, owner=owner-test
| Nov 13 10:52:20 davenport0 LSV:lsv_amin[26923]: Mail for test (from 8/503) delivered to LISTSERV.
| Nov 13 10:52:20 davenport0 sendmail[26922]: gADFqKg26922: to="|/usr/local/bin/lsv_amin /home/listserv/spool test", ctladdr=<[log in to unmask]> (8/0), delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=30028, dsn=2.0.0, stat=Sent
Listserv attempts to forward the message to [email]@post.harvard.edu,
which refuses it, because for some reason, sendmail is trying to use
24.147.1.10 as the relay address for post.harvard.edu:
| Nov 13 10:52:21 davenport0 sendmail[26924]: gADFqKu26924: from=<[log in to unmask]>, size=730, class=0, nrcpts=1, msgid=<[log in to unmask]>, proto=ESMTP, daemon=MTA, relay=davenport0 [192.168.0.200]
| Nov 13 10:52:21 davenport0 sendmail[26926]: gADFqKu26924: to=<[log in to unmask]>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=30730, relay=post.harvard.edu. [24.147.1.10], dsn=4.0.0, stat=Deferred: Connection refused by post.harvard.edu.
Restarting sendmail allows it to deliver the email using the correct IP
address for post.harvard.edu.
| Nov 13 10:53:22 davenport0 sendmail[26953]: alias database /etc/aliases rebuilt by bkuo
| Nov 13 10:53:22 davenport0 sendmail[26953]: /etc/aliases: 75 aliases, longest 75 bytes, 3103 bytes total
| Nov 13 10:53:22 davenport0 sendmail[26965]: starting daemon (8.11.6): SMTP+queueing@01:00:00
| Nov 13 10:53:23 davenport0 sendmail[26968]: gADFqKu26924: to=<[log in to unmask]>, delay=00:01:02, xdelay=00:00:01, mailer=esmtp, pri=120730, relay=post.harvard.edu. [128.103.219.45], dsn=2.0.0, stat=Sent (KAA11004 Message accepted for delivery)
At least I can get the emails delivered by stopping and restarting
sendmail, but obviously, that isn't a long-term solution. I don't know
what goes on behind the scenes between Listserv and sendmail, but it seems
like the problem is with Listserv, right?
Thanks again for any help.
Bob
|
