Stefan Palme:
[ Charset UTF-8 unsupported, converting... ]
> Thanks for all your answers. My first approach to just throw
> away all bounces caused by senseless data entered into a web
> form is obviously too naive ;-)
>
> I guess I will go the way to collect bounces by a script and
> establish an smtpd_recipient_restrictions based on this list
> of bouncing addresses.
>
> The only thing I cannot handle with this approach are bots using
> [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] etc. as
> destination email addresses - all those addresses will bounce
> and being collected, but never tried again by the bot. An IP-based
> rate limiting (and all other sort of rate limiting based on clients
> information) on postfix side will not work, because the clients
> IP address is always 127.0.0.1 (the web application, used via a
> remote browser).
>
> So an IP-based rate limiting in the web applications logic
> will be necessary - and this is really expensive, because there
> are a LOT of web applications using web forms running on this
> server...
>
> Maybe there is a way to solve this on postfix side, too?
> Each web application could add an additional Header "X-Sender-IP: <IP>"
> (and maybe other client information) to the generated mails - this
> is not too expensive to implement.
This can be done outside of Postfix with the Milter protocol. In
theory it can also be done with header_checks (combined with a
tcp_table(5) lookup table).
> Is it possible to use postfix to define "for each value of
> X-Sender-IP there are only 5 messages per day allowed" ? This would
> not prevent a bot from filling the web form thousand times a day,
> but postfix will not even accept 995 of these messages to be sent out...
>
> I guess I will have to write an own policy daemon for this,
> or is this possible with pure postfix configuration?
Instead of adding an ever-increasing list of features to Postfix
(or throwing in a Turing-complete scripting language) I decided
around 2000 to allow people to plug stuff into Postfix: content
filters, policy daemons, and Milter applications.
Wietse
