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: [EMAIL PROTECTED], 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=<[EMAIL PROTECTED]>, ctladdr=<[EMAIL PROTECTED]> (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=<[EMAIL PROTECTED]>, size=825, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, proto=ESMTP, daemon=MTA, relay=[192.168.1.8] Apr 20 15:04:31 McFeely sendmail[18846]: k3KL4Oxf018842: to=<[EMAIL PROTECTED]>, 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:[EMAIL PROTECTED] Sent : 4/24/2006 2:48:41 PM To : [EMAIL PROTECTED] Cc : [email protected] 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 /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
