On Fri, Apr 10, 2009 at 09:42:21AM +0800, Uwe Dippel wrote:
I'm running postfix as MTA on a machine with several CMS, on a chrooted
Apache. Recently, there is a huge number of spam being sent from there,
alas. When I scan the postfix-logs, all those come from 'root', meaning
they don't
On 10 April 2009 c. 05:42:21 Uwe Dippel wrote:
I'm running postfix as MTA on a machine with several CMS, on a
chrooted Apache. Recently, there is a huge number of spam being sent
from there, alas. When I scan the postfix-logs, all those come from
'root', meaning they don't come through port
Matthew Weigel unique at idempot.net writes:
Huh? I'm talking about the CMS itself authenticating to the SMTP server,
and giving each application a single set of credentials.
chroot is the name, and isolation is the game.
This should be set in
the CMS's config files, much like database
Vadim Zhukov wrote:
Do your clients have ability to connect to external hosts? If yes then
you should not even bother logging PHP mail() calls or such.
If outgoing connections are closed then you should have different system
users (i.e., different UIDs) for each client; otherwise it'll be
On 2009-04-12, Uwe Dippel udip...@uniten.edu.my wrote:
chroot is the name, and isolation is the game.
it's not all that unusual for PHP hosts to disable mail(); most of
the main CMS have some way to send mail without it, and these usually
do allow smtp-auth.
so you could install pear-Mail and
When dealing with web based submission, the best thing I have found is
to make sure the web based submission adds its own headers like what it
is and where the user came from and such so when diagnosing the problem
one can easily block based on that information. If there is an account
involved,
Uwe Dippel wrote:
I'm sorry, but I lack the experience to understand what you mean. I have
200+ users, several of them having set up (sorry, yes, written!),
who can install any CMS of their liking, using ftp; or any other script
that
sends mail. Some of them are official websites, so I can
Uwe Dippel wrote:
When dealing with web based submission, the best thing I have found is
to make sure the web based submission adds its own headers like what it
is and where the user came from and such so when diagnosing the problem
one can easily block based on that information. If there is an
Matthew Weigel unique at idempot.net writes:
Then you have grown your userbase too fast with a terrible setup, and now
you're caught in the middle of fixing the problem or avoiding downtime.
Are you sure this is not a misunderstanding? When you host user accounts, on a
tight, default, setup of
Chris Bennett wrote:
This could be helpful, possibly. First, you can maintain a functional
mini_sendmail by putting a nother script at /bin/mini_sendmail, this
script could do some sort of logging and then pass things on to the real
mini_sendmail, located somewhere else, different (hidden)
Uwe Dippel wrote:
Matthew Weigel unique at idempot.net writes:
Then you have grown your userbase too fast with a terrible setup, and now
you're caught in the middle of fixing the problem or avoiding downtime.
Are you sure this is not a misunderstanding? When you host user accounts, on a
Hi,
On Fri, 10.04.2009 at 09:42:21 +0800, Uwe Dippel udip...@uniten.edu.my wrote:
I'm running postfix as MTA on a machine with several CMS, on a chrooted
Apache. Recently, there is a huge number of spam being sent from there,
alas. When I scan the postfix-logs, all those come from 'root',
I'm running postfix as MTA on a machine with several CMS, on a chrooted
Apache. Recently, there is a huge number of spam being sent from there,
alas. When I scan the postfix-logs, all those come from 'root', meaning
they don't come through port 25. I run OpenBSD with mini-sendmail, and
now I
When dealing with web based submission, the best thing I have found is
to make sure the web based submission adds its own headers like what it
is and where the user came from and such so when diagnosing the problem
one can easily block based on that information. If there is an account
involved,
14 matches
Mail list logo