On 28/06/13 22:30, Wietse Venema wrote:
> Wietse Venema:
>> John Fawcett:
>>> I use fail2ban in order to block some types of apparently malicious
>>> connections to postfix when the clients keep retrying. For example the
>> As you agree logging every failed command would not be safe by
>> default.
>>
>> On the other hand, logging the command name (even without) parameters
>> for every [45]XX response could be tricky. Adding IF statements all
>> over the code is undesirable, so this would require a structural
>> change to the command reader and responder.
>>
>> What about a one-line change, such that the SMTP server logs the
>> existing per-session error counter when the connection is closed?
>>
>> This counter is reset upon successful completion of a (MAIL, RCPT,
>> DATA, end-of-data) sequence. This should be sufficient to expose
>> clients that hammer your server with unimplemented AUTH commands.
> Example:
>
> Jun 28 16:27:25 spike postfix/smtpd[65532]: disconnect from
> camomile.cloud9.net[2604:8d00:0:1::3] error_count 0
>
> As per the patch below for any Postfix version ever released.
>
> Wietse
>
> *** ./src/smtpd/smtpd.c- Sun Jun 23 11:10:02 2013
> --- ./src/smtpd/smtpd.c Fri Jun 28 16:26:41 2013
> ***************
> *** 4989,4995 ****
> * After the client has gone away, clean up whatever we have set up at
> * connection time.
> */
> ! msg_info("disconnect from %s", state.namaddr);
> smtpd_state_reset(&state);
> debug_peer_restore();
> }
> --- 4989,4996 ----
> * After the client has gone away, clean up whatever we have set up at
> * connection time.
> */
> ! msg_info("disconnect from %s error_count %d",
> ! state.namaddr, state.error_count);
> smtpd_state_reset(&state);
> debug_peer_restore();
> }
Thanks Wietse
That looks like it will do it.
