Re: [Exim] Exim not transferring outgoing mail

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Jason Robertson
Datum:  
To: Phil Pennock
CC: exim-users
Betreff: Re: [Exim] Exim not transferring outgoing mail
Don't forget Debian does run LIDS, which may be causing problems with
exim. But more then not, it sounds like a major case of
misconfiguration like, but again it would be nice to see the logs, and
such.. as well as a sanatized configuration file.

Also the message logs I think it's exim -Mvl <message-id> (though I
don't use it often)

Jason


On 6 May 2002 at 12:23, Phil Pennock wrote:

Date sent:          Mon, 6 May 2002 12:23:03 +0200
From:               Phil Pennock <Phil.Pennock@???>
To:                 Tomasz Kosinski <mickle@???>
Copies to:          exim-users@???
Subject:            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.
>
>
>
>



--
Jason Robertson
Now at the Nation Research Council.