Re: SMTP-SASL auth failure caching.
- Victor Duchovni:
> On Sat, Dec 01, 2007 at 10:43:53PM +0000, Keean Schupke wrote:As long as Postfix recognizes the 535 SMTP status in this very
> > have added a dsn_valid() check, and swapped to using strtoul, along
> > with unsigned long for all time values... no negative times.
> In http://tools.ietf.org/html/rfc4954#section-6, the enhanced status
> code for AUTH failures is defined as:
> 535 5.7.8 Authentication credentials invalid
> which extends:
> which only defines 5.7.0-5.7.7
> It may be appropriate to further check the enhanced status code (if
> present) and skip responses where 535 is accompanied by an enhanced
> status code other than 5.7.8. On the other hand, the 535 response is not
> currently supposed to be accompanied by any other enhanced status code,
> so this may be too pedantic.
specific context (AUTH request) there should be no need to require
a specific enhanced status code.
It is the SMTP client's job to translate protocol-specific server
replies (535 5.7.8 yadda yadda) into something meaningful (suspend
all further usage of this password for this user and server).
Is there a need for the SMTP client to make a sanitized version of
the server reply available to other software? If not, then why
- On Tue, Dec 04, 2007 at 09:04:19PM +0000, Keean Schupke wrote:
> How about we make the key iterations a config variable, and let theYes, that's the idea. Also CPUs have historically gotten faster
> user make the balance between speed and security?
year-by-year. Moore's law is looking a bit more feeble lately, we are
getting the feature-size scaling (more cores per die) but the clock-rate
seems to have stalled for a bit.
Finally, the table will not be in the chroot jail, proxymap/proxywrite
won't be chrooted even when other processes are. So some "postfix"
processes will have less access to the table than others.
Anyway this is all coverging to something sensible. The question for
the smtp(8) side is whether making the password hash the key is the
best choice. We could make "nexthop user" the key, and stick the
password hash in the result. That way deletion will actually work.
Otherwise, new passwords will be set before the fail map entry expires,
and the table entry becomes orphaned.
If this change is made, the entry is valid only if not expired, and the
password hash matches. Looks a lot an /etc/shadow entry with a user name
and PKCS#5 v2 password hash, only it perversely records invalid passwords!
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.