Tracking Email routing

[Stephen Smith]

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[31241]: 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[31245]: 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[18842]: 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[18846]: k3KL4Oxf018842: to=<username at cox.net>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30655, relay=mx1.west.cox.net. [68.6.19.3], dsn=5.0.0, stat=Service unavailable
Apr 20 15:04:32 McFeely sendmail[18846]: 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).

Andy
--
[-----------[system uptime]--------------------------------------------]
  2:48pm  up 22 days,  6:10,  1 user,  load average: 1.00, 1.01, 1.00