--
On Sun, May 26, 2002 at 06:44:15PM -0500, Kevin Jensen wrote:
| I am getting an error in my /var/log/maillog
|
| Although I'm getting this error, mail is still processing fine. I don't
| know if it is blocking spam, I haven't got any yet at least :)
| "May 24 07:54:03 clarkserver spamc[21276]: connect() to spamd failed:
| Connection refused"
It's not blocking spam at all. You can tell by looking at the headers
of the messages -- if SA processed it it will have some X-Spam
headers.
The error message means exactly what it says :-) -- connection to
spamd failed because the connection was refused.
| Does anyone know what is causing this?
I'd guess that you didn't run spamd first. Fortunately for you, spamc
will pass the message on unharmed when there is a problem interacting
with spamd.
| I've pasted the log below:
|
| May 24 07:40:03 clarkserver exim[21012]: 2002-05-24 07:40:03 Start
| queue run: pid=21012
exim started processing the queue
| May 24 07:40:03 clarkserver exim[21013]: 2002-05-24 07:40:03 17BAip-
| 0003wp-00 Message is frozen
[...]
That message is frozen. The log will tell why the message was frozen
at the time it was frozen (earlier than this message). Messages are
frozen only if there is some serious error with the delivery or if the
system filter specifies to freeze it.
| May 24 07:40:03 clarkserver exim[21012]: 2002-05-24 07:40:03 End
| queue run: pid=21012
The queue processing is done. (nothing happened since all queued
messages were frozen)
| May 24 07:54:02 clarkserver exim[21271]: 2002-05-24 07:54:02 17BEa1-
| 0005X5-00 <= aacmrjnw@??? H=(dxbmail.dxb.norr.co.ae
| ) [195.229.213.178] P=esmtp S=9524
A message arrived (details given in very terse form)
| May 24 07:54:03 clarkserver spamc[21276]: connect() to spamd failed:
| Connection refused
spamc couldn't connect to spamd. See above.
| May 24 07:54:03 clarkserver exim[21274]: 2002-05-24 07:54:03 17BEa3-
| 0005X8-00 <= aacmrjnw@??? U=mail P=spam-scanned S=9
| 682 id=E17BEa1-0005X5-00@???
A "new" message arrived. This is really the message shown above but
after spamc's processing (or lack thereof due to spamd problems).
| May 24 07:54:03 clarkserver exim[21278]: 2002-05-24 07:54:03 17BEa3-
| 0005X8-00 ** jtabor@???: unknown local-pa
| rt "jtabor" in domain "kinetic-media.com"
The message (same as above) was addressed to a non-existant local
user. You really want to adjust your configuration so that these
messages aren't accepted in the first place. It may just be a matter
of adding 'no_verify' to your director that invokes spamc, but it
depends on what is in your current config.
| May 24 07:54:03 clarkserver exim[21279]: 2002-05-24 07:54:03 17BEa3-
| 0005XD-00 <= <> R=17BEa3-0005X8-00 U=mail P=local S=105
| 13
A DSN (delivery status notification, in this case error) message is
injected into the system in response to the above message (see how the
message id is the same?). This is half of why you want to reject
unknown recipients earlier. You've just wasted resources running the
message through SA (if spamd had been running) and you've had exim
doing lots of work processing it and it is filling up your log files,
AND you now have the responsibility of sending back a bounce message
(and hoping the return address is valid). If you rejected the
recipient in the first place you wouldn't have spent any resources on
it.
| May 24 07:54:03 clarkserver exim[21278]: 2002-05-24 07:54:03 17BEa3-
| 0005X8-00 Error message sent to aacmrjnw@???
| May 24 07:54:03 clarkserver exim[21278]: 2002-05-24 07:54:03 17BEa3-
| 0005X8-00 Completed
Instead of the normal delivery for the original message (as it arrived
from the output of spamc), an error message has been sent to
aacmrjnw@??? and now exim sees that the delivery had been
completed.
| May 24 07:54:03 clarkserver exim[21272]: 2002-05-24 07:54:03 17BEa1-
| 0005X5-00 => jtabor <jtabor@???> D=spamch
| eck_director T=spamcheck
| May 24 07:54:03 clarkserver exim[21272]: 2002-05-24 07:54:03 17BEa1-
| 0005X5-00 Completed
The original message (follow the msg id to keep track of them) has
been delivered via the spamcheck_director director and has completed
delivery.
| May 24 07:54:04 clarkserver exim[21280]: 2002-05-24 07:54:04 17BEa3-
| 0005XD-00 => aacmrjnw@??? R=lookuphost T=remote_smt
| p H=mailin-03.mx.aol.com [64.12.137.121]
The bounce message has been sent out via remote_smtp to the original
sender.
The log format is documented in the spec, and though it is quite
terse, IMO it is quite logical and not too hard to read (considering
all the detailed information packed into it). When following the flow
of the messages, keep in mind that the setup you're using (presumably
from the docs I've published) works recursively like a stack. That
is, the first message arrives, and as it is in the process of being
delivered (through BSMTP) a "new" message arrives (push one frame on
the stack), and since that delivery falied another new (bounce)
message arrives (push one more frame on the stack). The last message
is queued, and now the second message is finished with delivery. The
second exim process now terminates, and the orginial sees that the
delivery was successful and logs that. Sometime later the bounce
message is processed off the queue and it finishes delivery.
HTH,
-D
--
Whoever gives heed to instruction prospers,
and blessed is he who trusts in the Lord.
Proverbs 16:20
GnuPG key :
http://dman.ddts.net/~dman/public_key.gpg
--
[ Content of type application/pgp-signature deleted ]
--
