Exim Logs-- What is this?

[wscreate]

It seems Exim and sendmail are plagued with errors. I have been monitoring logs, and found a ton of entries like this one...

== [email protected] T=remote_smtp defer (-44): retry time not reached for any host 2

What does smtp_defer mean? What about retry time not reached?

Thanks

 

[AlaskanWolf]

how can we go about fixing this, i get this too and users @charter.net cant get any email sent from our servers

 

[feanor]

It means that exim gave up connecting to that particular SMTP host coz it deemed it \"unworthy\" for a variety of possible reasons. Some older machines don\'t communicate well with the TLS-enabled exim that all of us CPanel people have now....

The very FIRST time it tried to connect, the error in the exim_mainlog would have been much more verbose. But when it gets to that point it means that it tried to connect a few times and then it finally ignores connecting to that subnet/IP/host (depending on how you have it configured)..... for a limited time.

Try running exim with these flags:

exim -qf

Should flush/ignore that blocked cache, and/or at least let you get a better entry in the log. Try connecting (sending a message) via raw sendmail, to the address in question.... if that box turns up crap for errors coz it is still permanently on the ignore list, try a box nearby. Then you can go to the ISP that controls the box and tell them why the SMTP servers are incompatible and see if there is a resolution they can provide.

In essence, it\'s an exciting time had by all. :P

 

[Annette]

The issue with charter.net mail is an Exim issue, as it is likely not picking up the lack of certificate on the recipient end and advertising tls to them. The error message is always the same.

2001-12-15 08:21:11 16FEkZ-0002zw-00 == [email protected] T=remote_smtp defer (0): SMTP error from remote mailer after STARTTLS: host mail.charter.net [209.225.8.223]: 454 domain has no certificate

This problem does not occur under sendmail. The solution:

In /etc/exim.conf, under the Transports configuration section, add the following line under the remote_smtp block. This is generally the first line of real configuration statements under the Transports section.

hosts_avoid_tls = mail.charter.net

So the section would look like this:

######################################################################
# TRANSPORTS CONFIGURATION #
######################################################################
# ORDER DOES NOT MATTER #
# Only one appropriate transport is called for each delivery. #
######################################################################

# A transport is used only when referenced from a director or a router that
# successfully handles an address.


# This transport is used for delivering messages over SMTP connections.

remote_smtp:
driver = smtp
hosts_avoid_tls = mail.charter.net


Restart Exim. If you have a large number of messages bottlenecked for charter.net, run
/usr/sbin/exim -qff

This will unthaw everything in the queue and attempt delivery.

If Exim fails to start, check to ensure you have put the option in the right place and that you have inserted the full server name for the remote mail server.

That\'s it.

 

[AlaskanWolf]

did everything above, i still get (suggestions?)

2001-12-15 13:50:11 16FLl5-0000rj-00 <= [email protected] H=203-213-237-24-cable.anchorageak.net (pepsicoke) [24.237.213.203] P=asmtp A=fixed_login:[email protected] S=1109 id=005e01c185a9$ffa95820$6401a8c0@pepsicoke
2001-12-15 13:50:12 16FLl5-0000rj-00 ** [email protected] R=lookuphost T=remote_smtp: retry time not reached for any host after a long failure period
2001-12-15 13:50:12 16FLl6-0000rz-00 <= <> R=16FLl5-0000rj-00 U=root P=local S=1945
2001-12-15 13:50:12 16FLl5-0000rj-00 Error message sent to [email protected]
2001-12-15 13:50:12 16FLl5-0000rj-00 Completed
2001-12-15 13:50:12 16FLl6-0000rz-00 => garyp <gar[email protected]> D=virtual_user T=virtual_userdelivery

 

[rpmws]

so you guys saying charter.net is why we see hundreds of \"frozen dilevery messages\"? Is it true we can\'t send to charter.net? How long has this been like this?

 

[Annette]

Gary, I\'d try dumping anything in the queue (just by an rm), restart exim, and then send another test through. The above works on every server that we changed, and I had sent the fix to Aletia after somebody pointed a thread out to me on their forum - worked for them, too. So in practice, we know that adding the statement to cease TLS attempts for mail.charter.net does work. It\'s just a matter of getting exim to \'forget\' what it knows about charter for a minute so it will send the mail.

And in response to the immediately preceding: no, charter would not be the sole cause of delivery queueing. You need to go through the logs and find one of the first instances of the attempt to deliver/queue, or check in /var/spool/exim/msglog for one of the messages you know is frozen to try and get the first failure instance. Alternately, restart exim while watching the log roll, or do a /usr/sbin/exim -qff while watching the log roll to look at the error messages generated when exim unthaws things and tries to deliver them. Failures are for any number of reasons (mailbox is full, recipient doesn\'t exist, bad domain addressing) and without an exact error message, it would be impossible to tell what\'s going on. This issue with charter seems to have started just after some of the breaks with @home - within the last week or so, and within the past three days for certain based on our first reports from clients.

[Edited on 12/15/01 by Annette]

 

[AlaskanWolf]

thanks for the help so far, cleaned out the cache, and restarted, resetn and get this (same error)


2001-12-15 21:08:26 16FSbC-0007m2-00 <= [email protected] H=203-213-237-24-cable.anchorageak.net (pepsicoke) [24.237.213.203] P=asmtp A=fixed_login:[email protected] S=1111 id=003c01c185e7$501ea610$6401a8c0@pepsicoke
2001-12-15 21:08:26 16FSbC-0007m2-00 ** [email protected] R=lookuphost T=remote_smtp: retry time not reached for any host after a long failure period
2001-12-15 21:08:26 16FSbC-0007m8-00 <= <> R=16FSbC-0007m2-00 U=root P=local S=1947
2001-12-15 21:08:26 16FSbC-0007m2-00 Error message sent to [email protected]
2001-12-15 21:08:26 16FSbC-0007m2-00 Completed

Heres my exim.conf

# This transport is used for delivering messages over SMTP connections.

remote_smtp:
driver = smtp
hosts_avoid_tls = mail.charter.net

 

[rpmws]

[quote:e61b34aa93]Gary, I\'d try dumping anything in the queue (just by an rm), restart exim, and then send another test through. The above works on every server that we changed, and I had sent the fix to Aletia after somebody pointed a thread out to me on their forum - worked for them, too. So in practice, we know that adding the statement to cease TLS attempts for mail.charter.net does work. It\'s just a matter of getting exim to \'forget\' what it knows about charter for a minute so it will send the mail.

And in response to the immediately preceding: no, charter would not be the sole cause of delivery queueing. You need to go through the logs and find one of the first instances of the attempt to deliver/queue, or check in /var/spool/exim/msglog for one of the messages you know is frozen to try and get the first failure instance. Alternately, restart exim while watching the log roll, or do a /usr/sbin/exim -qff while watching the log roll to look at the error messages generated when exim unthaws things and tries to deliver them. Failures are for any number of reasons (mailbox is full, recipient doesn\'t exist, bad domain addressing) and without an exact error message, it would be impossible to tell what\'s going on. This issue with charter seems to have started just after some of the breaks with @home - within the last week or so, and within the past three days for certain based on our first reports from clients.

[Edited on 12/15/01 by Annette] [/quote:e61b34aa93]

Thanks Annette! ..seems every board I see you on you seem to be the one person that contributes the most real useable input. I want to personally thank you for sharing what you have learned with the rest of us.

 

[AlaskanWolf]

Likewise, thanks Annette

I\'ve tired everything, extended the retry times and everything, i cant figure this out on why you guys got it to work and not me

[Edited on 12/16/01 by AlaskanWolf]

 

[bdraco]

[quote:466534b1c9]Likewise, thanks Annette

I\'ve tired everything, extended the retry times and everything, i cant figure this out on why you guys got it to work and not me

[Edited on 12/16/01 by AlaskanWolf] [/quote:466534b1c9]

Try flushing out everything

exim -qff -v

 

[radhost]

Here if anyone wants to send charter a email on this, I have spent hours on the phone with them listening to them say they do not have a problem. Finally they gave me a email addy that is above tier 3 support. All parties that are having problems should email there problems here.
[email protected]

 

[bdraco]

The root of the problem is that charter.net is advertising they can do a starttls but don\'t actually have a certificate.

bdraco@bd [~]# telnet mail.charter.net 25
Trying 209.225.8.223...
Connected to mail.charter.net.
Escape character is \'^]\'.
220 dc-mx03.cluster1.charter.net ESMTP CommuniGate Pro 3.4.6
>>EHLO cpanel.net
250-dc-mx03.cluster1.charter.net your name is not cpanel.net
250-HELP
250-PIPELINING
250-ETRN
250-DSN
250-ATRN
250-STARTTLS
250-SIZE 104857600
250-AUTH=LOGIN
250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5
250-8BITMIME
250 EHLO
>>STARTTLS
454 domain has no certificate


Since the server is running a 4XX response its telling exim to try again and the situation is temporary (hopefully charter will make a crt for their server).

 

[Annette]

I sent a note to the charter tech folks, and I wouldn\'t want to be the one holding my breath waiting for them to repair it. When I did the test connection after the first client report, their MTA wasn\'t advertising TLS, so I figure it was just exim being exim. Since you\'ve gotten an advertise for it now, though, I may have overlooked it during that initial test. The workaround is holding us until they acknowledge the problem or get with the program.

To the rest: just trying to add what I can and pick up on things I didn\'t know. Thanks for your kind words.

Happy holidays everybody, no matter what holiday belongs to you. :D

 

[AlaskanWolf]

WOW! they fixed it! sent a test email to @charter.net and it went right though

Thanks for all the help everyone

 

[smachol]

So is the only fix to get the receiving host to make the changes? I tried the exim.conf fix and everything else in this thread but the problem persists. In my case the receiving host is \'mail.cybertrails.com\'. They deny there are any problems on their end.

 

[feanor]

That is the default response for systems adminsitrators that don\'t give a sh*t. And/or are completely swamped and have no time to deal with you?

Either way it\'s not c00l and they are living in the incompatible stoneage.

Give them the output from the error in the handshake between your smtp server (exim) and theirs..... and then give them a link to this thread and, provided the cause of the problem is the same as the charter.net issue.... more likely than not the admin(s) on the other end will provide you a solution.

 

[Seven77]

This is maybe a stupid question:

If I have more then one mailserver with this problem, i have it to do like this

remote_smtp:
driver = smtp
hosts_avoid_tls = mail.charter.net
hosts_avoid_tls = mail.jet.net
and so on

or

hosts_avoid_tls = mail.charter.net, mail.jet.net, and so on

Thanks for any help!

Seven

 

[SupaDucta]

I have the same problem with remote_smtp defer. I have messages queued but can't be dispatched. Exim is reported as failed in WHM, although it is running.

WHM running processes:

24273 (exim) /usr/sbin/exim /var/spool/exim
/usr/sbin/exim -bd -q60m


--------------------------------------------------------------------------------
24279 (exim) /usr/sbin/exim /var/spool/exim
/usr/sbin/exim -bd -oX 26


--------------------------------------------------------------------------------
24286 (exim) /usr/sbin/exim /var/spool/exim
/usr/sbin/exim -tls-on-connect -bd -oX 465


--------------------------------------------------------------------------------
24416 (antirelayd) /usr/bin/perl /
antirelayd

Is there a problem with -tls-on-connect and how to fix this?

If I try exim -qff -v

All connections are refused.

T=remote_smtp defer (111): Connection refused

and

R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host

Guys, help me please I haven't slept in two days sdearching around and trying to fix this

 

[SupaDucta]

Fixed. Turns out that SMTP Tweak in WHM, which was working correctly before new update, blocked connections to Exim after the cPanel update. Our support guys turned it off and now everything works.