Jeff wrote:
> Is there any easy^H^H^H^H not incredibly hard way to find from which
> user the spam really originates?
I have had similar headaches, as it's extremely difficult to trace locally
generated emails (when they don't require auth) to user accounts if you also
allow some form of address rewriting (which is common for a webhosting
company to do). The only real issue I had was tracing PHP scripts, since
PHP was an Apache module it ran as apache, so I wasn't able to trace what
website/script/user had generated the email (Perl and other CGI languages
were ok since I used suexec).
To "fix" this problem, I came up with an Exim patch that allowed you to
access any environment variable, which in turn I would set so I could trace
users. The patch is here:
http://www.elisand.com/downloads/other/exim-4.53-env_vars.patch. It was
never officially accepted in to Exim for the fact that you may try to rely
on env vars which may not be present (if you don't use this patch properly,
that could happen).
It is used like this:
acl_not_smtp:
warn condition = ${if def:env_SERVER_ADDR {yes}{no}}
add_header = X-CGI-Server: $env_SERVER_NAME
(${env_SERVER_ADDR})
logwrite = CGI Server: $env_SERVER_NAME
(${env_SERVER_ADDR})
warn condition = ${if def:env_SCRIPT_NAME {yes}{no}}
add_header = X-CGI-Script: $env_SCRIPT_NAME
(${env_SCRIPT_FILENAME})
logwrite = CGI Script: $env_SCRIPT_NAME
(${env_SCRIPT_FILENAME})
... and then in my Apache configuration for the vhost in question, I would
set this:
php_admin_value sendmail_path "SERVER_NAME='
www.example.org'
/usr/sbin/sendmail -t -i"
Using "php_admin_value" prevented users from overriding the setting, and it
attached the vhost name to the call to sendmail, which was then picked up by
my patch (SERVER_ADDR is defined by Apache I believe) and logged both with
the email sent, and in the email logs. The same was done with the script
that sent the email. Using this I was able to trace spam originating from
my severs quite easily (and in turn caused my workload to more than double -
finding hacked sites almost daily, etc...).
This all may or may not be relevant to your issue - but figured I would
mention it. Of course now I don't need my patch or this technique since I
am using the Apache ITK MPM which runs everything as a specified system user
so I can trace everything down to a user account easily.
> Is there any easy way to disable email from nondeliverable email
> addresses only for email originating on our server?
You could perhaps set up callouts to try and verify the sender/From: for
local submissions, though really this isn't your main issue. You need to be
able to log enough detail to trace emails originating from your system so
you can figure out where the spam is coming from (because chances are, if
it's spam it's either 1) a client you don't want, 2) a hacked site, or 3) a
hacked site that may have gotten farther than just spamming).
Eli.
