Viktor Dukhovni:
> With SASL we don't know what the login name is unless authentication
> succeeds. The user name encoding is mechanism specific (with GSSAPI
> it is in the ticket!). Does the SASL API expose a user name for
> failed logins?
See discussion in my reply to Patrick.
> > Did you have more ideas about shared-memory counter in memcache?
>
> I have not given any thought to anything in this space that is not
> SASL. My conjecture is that SASL is special.
I see this as a general counting mechanism with a custom policy on
top. In this case, the number of logins on the same account is
maintained by the counter, and the decision to block mail or disable
an account is policy. A general counting mechanism can be used for
other things: senders, recipients, etc. Many of my specific examples
are already implemented by policy daemons.
> The basic control for submission clients (be it by client address,
> or by successful client login) is to substantially limit the
> connection concurrency and rate from any given whitelisted IP or
> any authorized account, and then to set a maximum submission message
> rate per single connection. After that promptly close down any
> access that is abused.
>
> Don't use POP before SMTP, it is way past its prime.
Sure. We're talking about different parts of the solution: counters
(me) and policy enforcement (you). My immediate focus was on counters
as a way to enable new functionality such as Postfix health monitoring,
and making the anvil daemon redundant.
Wietse
