421 Lost incoming connection

[soulshepard]

Dear directadmin collegues,

I recently had some "421 Lost incoming connection" reports from clients on my server.

unfortunatly my server had to process a lot of spam, and was under high load.
you can semi tune the amount of workers for spamassasin and exim to get or not get this highload. but what worried me is dat the message bounced and did not get a retry.

after dealing with the spam traffic, i found some topics related to this message but none really answering my question (bounce vs retry)

finaly on issues.apache.org/SpamAssassin way down in the bottom was the solution to make exim/spamassasin retry the message in stead on making an hard bounce thus resulting in a mail not meing deliverd.

the suggested change is under the sections : local_sa_delivery and virtual_sa_userdelivery in the exim config.

temp_errors = *

i did search the forums but i do realise i did not search the directadmin help to verify if this is known. so my appologies if i make an double post now

With kind regards,

Soul

 

[soulshepard]

BUT setting the suggested gives an error saying.. "unknown option" arg.. makeing me look nice. but still it stands it should not bounce but retry.

searching..

 

[soulshepard]

added the temp_errors = * to the spamcheck: sections as suggested somewere else here in the forum. but still should this not be default?

Soul

 

[nobaloney]

I'd be happy to add it it's really a good idea. What are the ramifications? What may happen if we always return temporary errors? Will others see us as bad neighbors?

Can you find documentation on which errors it will mark as temporary? For example, if a user doesn't exist, will that still be a temporary error?

Jeff

 

[soulshepard]

I'd be happy to add it it's really a good idea. What are the ramifications? What may happen if we always return temporary errors? Will others see us as bad neighbors?

Can you find documentation on which errors it will mark as temporary? For example, if a user doesn't exist, will that still be a temporary error?

Jeff

jeff i missed to reply to this post my appologies for this.

from the top of my head. i had those questions also. but this error was
caused by the spamassasing deamon not responding related to its pipeing process to the deamon. due to errors resources etc.

the temp_error = * is explained in the exim.conf.

[The pipe transport]
http://www.exim.org/exim-html-current/doc/html/spec_html/ch29.html

i only added this to the spamcheck: section in the exim.conf so i am under the assumption it would only count for the passing to the spamassasin deamon and only counting for the error related to the piping process. not for user does not exist. but you are right it is food for tought.

wil investigate this as soon as i can. what i do know is that with "temp_error =" can come an additional error code. so supplying the 421 code in its format that exim will accept would eliminate the bug that mail will permenant fail instant if your spam check deamon fails for what reason. BUT what holded me off for this is then you also need to supply the correct list of temp error, and i did search for it. but it took too long for my issue at that time. but i assume this list of error codes would be a dig up of the rfc's

if we have that list then its properly solved i guess..

on the other hand to look at it simpel : i run now for a year with this setting, still not being reported as bad neighbor.

i think we all are just lucky that the directadmin set, spam assasin/ exim /clamav is a really stable combination. thats why i guess allmost nobody has ran into this. but if we do.. then if one hosts a lot of domains then it is still a shame as hoster to have directly bounced the mail as permenant error instead of temporairy.

Soul

 

[soulshepard]

ps: this also counts if clamd or any process in the piping processes fail.

this weekend i did a directadmin server migration, made a basic install, restored backups, got the system live, but made a typo in the clamd socket line. effectively due to the setting the errors were temporairy in stead of permanent. this saved me a lot of lost email and possible complaining customers.



soul

 

[sky]

I think i have the same problem on a server.

How to solve the problem because i have no emails now.

Thx
Gunning Sky

 

[nobaloney]

Shut down and restart clamd. Often you can do this by restarting exim.

Jeff

 

[sky]

Hello

Thanks to smtalk who found the problem : a bad IP in resolv.conf
No idea why there whas a bad IP in that file (the bad IP whas the principal IP of the server)

Thx,
Sky

 

[soulshepard]

and to stay on topic, if you would apply the temp_error setting then atleast your mail would have bounced and retried later instead of rejected and never recent again

soul