jeffs wrote:
I have a postfix system set up that works fine (well, maybe that is
because it is not totally on-line yet :-\ ). But testing has been great.
Once it goes live this system is going to be used to send email alerts
to users based on certain database activity. Actually, a script which
runs against user names and email addresses in the database will be
kicking off the alerts. This is not a system that uses postfix for
general email type of activity -- it will be used only for outbound
alerts. I've got that part to work already just fine.
There is the slight potential for abuse by these logged in users that
one or two may figure out a way to send spam through this system by
forging (not login) credentials that the database uses to sort out
outbound email.
In this particular system if spam is going to go out via the method
mentioned above, it will always be destined for one particular user,
although those users will change over time and it is not feasible to
predetermine which user may be on the receiving end.
What would be the best method in postfix to shut down or stop a sudden
flurry of emails to one user. It will always be a sudden jump in
outbound emails since typical outbound alerts will not happen that often.
Postfix has rate-limiting features, but I'm not sure that would be very
helpful, since even a low rate-limit will still let a lot of messages
though (over a weekend, for example).
A better solution would be to secure the system that generates the
emails and use authentication for sending mail.
If that isn't an option, you could install spamassassin and use
header_checks to HOLD anything with an X-Spam-Level > a defined maximum.
It's very effective especially if you teach it what the legitimate
emails look like.
Terry
