Tracking Email routing
scsmith1451 at totacc.com
Tue Apr 25 09:29:08 MDT 2006
Apologies for the first response, the ISP apparently stripped out the original pasted messages.
The first two entries are from our Oracle server, vader, which is configured to relay to our domain email server mcfeely.
"Apr 20 15:01:34 vader sendmail: k3KL1YJQ031241: to=username at cox.net, ctladdr=cis (502/502), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30309, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (k3KL1Yn5031243 Message accepted for delivery)
Apr 20 15:01:40 vader sendmail: k3KL1Yn5031243: to=<username at cox.net>, ctladdr=<cis at localhost.localdomain> (502/502), delay=00:00:06, xdelay=00:00:06, mailer=relay, pri=30466, relay=mcfeely.gwic.net. [192.168.254.2], dsn=2.0.0, stat=Sent (k3KL4Oxf018842 Message accepted for delivery)"
These seem to be the corresponding entries on mcfeely to relay the requrest to the final destination.
"Apr 20 15:04:30 McFeely sendmail: k3KL4Oxf018842: from=<cis at localhost.localdomain>, size=825, class=0, nrcpts=1, msgid=<20060420210134.GA31227 at vader.gwic.net>, proto=ESMTP, daemon=MTA, relay=[192.168.1.8]
Apr 20 15:04:31 McFeely sendmail: k3KL4Oxf018842: to=<username at cox.net>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30655, relay=mx1.west.cox.net. [188.8.131.52], dsn=5.0.0, stat=Service unavailable
Apr 20 15:04:32 McFeely sendmail: k3KL4Oxf018842: k3KL4Wxf018846: DSN: Service unavailable"
It appears to me, the unlearned, that the Service unavailable is with the mx1.west.cox.net. It that right?
Stephen C Smith
------- Original Message -------
>From : Andy Bradford[mailto:amb-1064524778 at bradfords.org]
Sent : 4/24/2006 2:48:41 PM
To : scsmith1451 at totacc.com
Cc : plug at plug.org
Subject : RE: Re: Tracking Email routing
Thus said Stephen Smith on Mon, 24 Apr 2006 13:41:14 MDT:
> When email do not get delivered, no bounce notices are received and no
> errors are registered.
Where would you expect bounces to go? Normally they go to the Envelope
Sender address; is your application setting a sensible one?
> Not being an email expert, more like a novice, I could use a little
> help tracking down the issues. Is there an equivalent to traceroute
> for email, that would diagnosis routing issues?
I don't know of a traceroute-like tool, however, your best resource is
going to be the mail logs. If you don't have good logs, or even easy to
read logs, then you are in for a long debugging. You also need to have a
firm understanding of what your applications are doing. Are they using
/usr/lib/sendmail? Are they speaking SMTP with a particular mail server?
What do the logs say?
If you don't have good logs, the next best thing is tcpdump or some
other sniffer that can watch SMTP traffic. Capture a message off the
wire with tcpdump and then use tcptrace to reconstruct it (or ethereal).
2:48pm up 22 days, 6:10, 1 user, load average: 1.00, 1.01, 1.00
More information about the PLUG