Re: exim not sending email

[dman <dsh8290@rit.edu>]

On Wed, Jan 16, 2002 at 10:09:40PM -0800, Mike Egglestone wrote:
| Hello,
| I'm having trouble sending email from my potato box.
| This is part of the log from /var/log/exim/mainlog
| Can anyone tell me whats happening?

| 2002-01-16 21:59:34 16Qztk-0002M9-00 == jlirette@dunster.sd57.bc.ca
|                           routing defer (-42): retry time not reached

The message with id "16Qztk-0002M9-00" is currently deferred as a
result of some error earlier.  At this point in time, the retry time
(the delay before trying again) hasn't been reached.  Running "exim
-qff" will force it to try delivering right now.

| 2002-01-16 21:59:34 16QsgG-0000Zg-00 == gudrun.heiming@arbeitsamt.de
|               T=remote_smtp defer (-44): retry time not reached for any host

Same for this message.  The "T=" here refers to the transport that
exim is supposed to use for this message.

| 2002-01-16 22:04:37 16QhUU-00009p-00 == megglestone@sd57.bc.ca
|                   T=remote_smtp defer (-19):
|                   Remote host fc.sd57.bc.ca [199.175.16.118]
|                   closed connection after end of data

This message is being delivered with the "remote_smtp" transport.  It
connected to the remote host, specified the envelope (mail from and
rcpt to) and also sent the data section (the contents of the envelope,
the actual message itself).  However the remote machine closed the
TCP socket (connection) prior to acknowledging that it has the message
and accepts responsibility for it.  Thus the transfer is considered to
have not happened, and exim will defer the message until it tries
again later.

Either you have something misconfigured that causes the remote systems
to reject your messages (but they should give a real error message
rather than simply dropping the connection), or the problem is not
your fault.

I recommend trying to send a message manually (use telnet) and see
exactly what the interaction with the remote host is.  Aternatively,
you can run exim with the -v option to see the SMTP interaction on
stderr.
eg :
    $ /usr/sbin/exim -v <remote_addr> < file_with_rfc822_message

If it turns out that, for whatever reason, it is not possible to
deliver messages directly from your system, try using your ISP as a
smarthost and let them deal with getting the message to the
destination.

HTH,
-D

-- 

Failure is not an option.  It is bundled with the software.