A couple days ago, I suddenly got a lot bounced messages (I am a
postmaster). Looking into their envelopes further, I realized
actually they all orginated from a web server in our server cluster.
Our qmail is implemented with anti-relay mechanism, but all web
servers are selective relays - to allow users' form submissions to go
through the mail servers. But these bounces didn't look like like
from our users. I got curious and decided to track down the real
cause.
It turned out a user here thought putting up a web mail CGI program
was a fun thing to do :( However, since the poorly written web mail
CGI didn't do any authentication or verifications, so *anyone* on the
Internet can use it to send to any place, and indeed, some freaks did
just that! In a way this user defeated our anti-relay mechanism
implemented on the mail servers.
Messages generated by form submissions should be allowed to relay
through the mail servers. But the above Web mail CGI program is
certainly not in the same category. The user is notified, chastised,
and told firmly to remove the offending CGI script. But, this
incidence has left me wondering whether we can do anything to counter
(or even better, prevent) such "internal spam" via selective relays in
the future? People tend to repeat others mistakes :( We can setup
user policies, but we also know they are rarely read by users :(
I have been thinking how to deal with this, but a fact, that messages
from the web servers generally only have the web server's identity
(e.g. [EMAIL PROTECTED]) in the From line, makes it difficult to
single the offending ones.
Of course, we can run double qmail queues, with a message checking
process runing between the two queues filtering out troublesome ones.
But this is a really heavy weight approach, not to mention it will eat
into our already busy schedule. I wonder whether there are some
efficient/light weight approaches that I might have missed?
Any hints are appreciated.
Regards,
Chin Fang
[EMAIL PROTECTED]
