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 hav
On Sat, Oct 05, 2013 at 05:55:49PM -0400, Wietse Venema wrote:
> > > Either the use of per "login name" counters
> > > should be restricted to "known" logins,
> >
> > This is for free, there is no such thing as an "unknown login".
>
> Not true when "per login name" counters are updated regardles
Patrick Ben Koetter:
> * Wietse Venema :
> > Viktor Dukhovni:
> > > On Sat, Oct 05, 2013 at 09:59:23AM -0400, Wietse Venema wrote:
> > >
> > > > It should be easy enough to count per "login name" instead of per
> > > > "SMTP client" (after all, those labels are just simple strings that
> > > > sel
* Patrick Ben Koetter :
> * Wietse Venema :
> > Viktor Dukhovni:
> > > On Sat, Oct 05, 2013 at 09:59:23AM -0400, Wietse Venema wrote:
> > >
> > > > It should be easy enough to count per "login name" instead of per
> > > > "SMTP client" (after all, those labels are just simple strings that
> > > >
* Wietse Venema :
> Viktor Dukhovni:
> > On Sat, Oct 05, 2013 at 09:59:23AM -0400, Wietse Venema wrote:
> >
> > > It should be easy enough to count per "login name" instead of per
> > > "SMTP client" (after all, those labels are just simple strings that
> > > select a hash-table entry).
> > >
> >
Viktor Dukhovni:
> On Sat, Oct 05, 2013 at 09:59:23AM -0400, Wietse Venema wrote:
>
> > It should be easy enough to count per "login name" instead of per
> > "SMTP client" (after all, those labels are just simple strings that
> > select a hash-table entry).
> >
> > However it should not be too ea
On Sat, Oct 05, 2013 at 09:59:23AM -0400, Wietse Venema wrote:
> It should be easy enough to count per "login name" instead of per
> "SMTP client" (after all, those labels are just simple strings that
> select a hash-table entry).
>
> However it should not be too easy to exhaust server memory.
>
Wietse Venema:
> nik600:
> > Virus, botnet and user's bad policies about password allows many 3rd party
> > entities to stole passwords, in the last month i've experienced a grows of
> > hacked users, and in some case many spam messages are sent from my servers
> > before i can block the user.
> >
i know, but if you have thousands of users you can't trust too much them.
I know also that smtps,pop3s,imaps must be used but you can't change a
production system.
it's a long migration, and during this migration you need tools to stop
spammers and broken accounts.
then, when the world will be per
On 10/4/2013 2:29 AM, nik600 wrote:
> Virus, botnet and user's bad policies about password allows many 3rd party
> entities to stole passwords, in the last month i've experienced a grows of
> hacked users, and in some case many spam messages are sent from my servers
> before i can block the user.
>
nik600:
> Virus, botnet and user's bad policies about password allows many 3rd party
> entities to stole passwords, in the last month i've experienced a grows of
> hacked users, and in some case many spam messages are sent from my servers
> before i can block the user.
>
> I've tried many combinat
Nik
Maybe try a policy server, CBPolicyd works well and support SASL quotas.
Have a look at http://www.policyd.org.
Regards
On 04/10/2013 09:29, nik600 wrote:
Virus, botnet and user's bad policies about password allows many 3rd
party entities to stole passwords, in the last month i've experi
Virus, botnet and user's bad policies about password allows many 3rd party
entities to stole passwords, in the last month i've experienced a grows of
hacked users, and in some case many spam messages are sent from my servers
before i can block the user.
I've tried many combination
smtpd_client_me
13 matches
Mail list logo
