Re: [Exim] Exim not transferring outgoing mail

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Phil Pennock
Datum:  
To: Tomasz Kosinski
CC: exim-users
Betreff: Re: [Exim] Exim not transferring outgoing mail
On 2002-05-05 at 23:09 -0400, Tomasz Kosinski wrote:
> 5.) I send a test message to myself at the account (panix.com) where
> this post is originating from, and it goes undelivered, again with
> message about "Spool file is locked (another process is handling this
> message)".


Ungh. Two things occur to me. One is that the clock has been set back
on your system, and you daily have the kind of luck to drive most
mortals to weeping suicide.

We can't help you if this is the case.

The other, I'll describe below.

>   /var/spool/exim/input:
>   drwxr-x---    2 mail     mail         8192 May  5 22:09 .
>   drwxr-x---    5 mail     mail         4096 May  5 19:28 ..
>   -rw-------    1 mail     mail            0 Apr 30 02:50 172RSn-00005L-00-D
>   -rw-------    1 mail     mail           24 May  3 22:23 173pDK-0000WV-00-D
>   -rw-------    1 mail     mail          729 May  4 22:38 173pDK-0000WV-00-H


Empty message, no controlling headers. Something is seriously screwed.
Just remove that 172RSn-00005L-00-D file manually.

> 8.) One or two days pass by while I try to figure this out, when all of
> a sudden there are 83 new junk mail message in the queue. If I try to
> check out with -Mvh where they are coming from, I get, for example:


Okay, so a spammer is injecting email via your system. Do you have a
web-server? Are there any CGI scripts?

> 147P Received: from mail by localhost with local (Exim 3.32 #1 (Debian))
>         id 173w7f-0001KG-00
>         for <atigzgk@???>; Sat, 04 May 2002 05:46:35 -0400



> The "From" header of the junk mail is my localhost name (not a fqdn), so
> would that mean that most mail servers would not accept the mail?


No. Those servers which attempt to verify the sender, such as Exim in
some configurations, might reject the mail. It will often get through.

In that Received: line which I left quoted above, the "with local" means
that something invoked exim directly, probably by the name
/usr/sbin/sendmail or /usr/lib/sendmail.

So something on your system is invoking exim/sendmail, and sending spam.
Something being run by the user "mail".


Do you have another Exim running, using a slightly different
configuration? But with the same mail-spool? For instance, exim being
run out of inetd? There have been problems with Exim run from inetd
being an open relay, because of complicated interactions and just _how_
Exim is supposed to figure out that this is what is happening. I think
that this happened on Debian systems.


Exim is up to 3.36. I think that a solution was implemented for this.
Try this:
* fetch Exim 3.36
* build it (configure and "make")
* Shut down previous Exim. Drain all the mail out. Ensure Exim not
run from inetd
* # mv /var/spool/exim /var/spool/exim.out
* install new Exim (3.36)
* start new Exim

If using Exim from inetd, please _try_ running Exim as a standalone
daemon (the -bd option) and see if doing this solves all the problems.

If this seems to solve things, then you can try moving Exim back to
being run from inetd.


Hrm. I would have expected more in the way of trace headers, though, if
it were exim-from-inetd causing this. Can you think of anything else
which might run on your system, as user "mail"? It could be a webserver
and suexec, it could be something else.
--
End-to-End Security (n.): see IT SECURITY.
IT (n.): Sex.
IT Security (n.): Safe sex.