----- Original Message -----
From: "Suresh Ramasubramanian" <linux@???>
To: "Rejo Zenger" <subs=exim-users@???>
> Rejo Zenger writes on 12/15/2003 4:42 AM:
>
> > I know I'm not helping you directly with this answer, but as long as you
> > haven't fixed your problem, shutdown exim immediately. You don't want to
> > keep exim running if it's being abused by spammers.
> >
> > Also, you could help others helping you by posting some more
> > information. Relevant sections of your configfile for a starter.
>
> He said -
>
> > prevent users to sendmail as nobody
>
> Which means that the spammer is likely abusing a cgi script on his site
> - and that'd call exim from the commandline, not speak smtp to port 25.
>
> srs
>
***WARNING*** The following is brainstorm activity, not necessarily
helpful...
What would be the impact of deleting the following line from rcpt ACL?
accept hosts = :
If I understand correctly, deleting this line would remove the "free pass" for
local "command line" injected messages, and instead apply the rest of the rcpt
ACL, including, for example, authentication tests.
I suggest this only as a temporary stop-gap measure. I'm not expert enough to
know if it would work without breaking other fundamental things. Any comments
from the experts? What "features" break if you delete this line from the ACL?
It would also stop any users with legitimate reasons to inject messages via
local scripts. (Pretty much anything injected by the webserver, I imagine).
So, it might be just as bad as Ankush's already rejected blocking of "nobody."
But at least it might stop the spammer while the problem gets solved, without
taking down the entire mailserver.
Another suggestion:
Could one add a log line to "accept hosts = :", to track the userid of anyone
using the command line to inject messages? Might this help identify the
culprit? Something like:
accept hosts = :
log_message = local injection by $originator_uid as $sender_address
From the Exim Spec:
$originator_uid: The value of $caller_uid that was set when the message was
received. For messages received via the command line, this is the uid of the
sending user. For messages received by SMTP over TCP/IP, this is normally the
uid of the Exim user.
$sender_address: When a message is being processed, this variable contains the
sender's address that was received in the message's envelope. For bounce
messages, the value of this variable is the empty string. See also
$return_path.
I suspect one would find the culprit to be "Apache." Not much help, I
suppose...
If this is the case, the solution is to be found in the webserver config, not
in Exim, I think.
Sympathetic Regards,
Jim Roberts
Punster Productions, Inc.
