From: Keean Schupke (keeanfry-it.com)
Date: Sun Dec 02 2007 - 02:40:19 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This is a resubmission, apparently the patch plus my preamble is over
the 40k character limit. The patch is short enough, so it must be all
my waffle at the beginning! I will post the patch in the next mail.

Well, this is V2.1 I guess. I went with most of the changes suggested,
and I modified the interface to cache_client. Now you pass in the
"service name" and "CLNT_STREAM**", so the cache client is stateless,
and can be used from many places in the same process at the same time.
This coupled with the ability to change the serivce name in the
"master.cf" file, and override the cache file with "-o cache_map"
allows the cache service to really provide multiple caches to multiple
services at the same time. For good measure, I added a
"smtp_sasl_auth_cache_service" conf variable to allow you to set the
name of the auth_cache service to something else.

I have tested the patch with both soft_bounce disabled and enabled,
and all is behaving as required.

Also, using the little cache_client test program at the end of
cache_client.c I notice the memory based hash table (dict_ht) does not
support delete. This should not affect funtionality, as an expired or
corrupt cache entry will just be ignored, but it does mean warnings
are generated evey time an attempt is made to delete a cache entry in
the "volatile" mode. This affects verify.c as well. I assume it is not
worth disabling the delete call for this mode, just incate dict_ht
gains this functionality in the future.

The patch includes adding the service to master.cf (although I run
pretty much everything in a chroot jail, which I believe is not the
default... so that one may not apply). Also I haven't made any changes
to the main.cf, and the patch was generated after the soft_bounce
patch, and the comments there may be slightly different.

Regards,
Keean Schupke, Fry-IT Ltd.

On 02/12/2007, Wietse Venema <wietseporcupine.org> wrote:
> Victor Duchovni:
> > On Sat, Dec 01, 2007 at 10:43:53PM +0000, Keean Schupke wrote:
> >
> > > 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:
> >
> > http://tools.ietf.org/html/rfc3463#section-3.8
> >
> > 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.
>
> As long as Postfix recognizes the 535 SMTP status in this very
> 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
> bother.
>
> Wietse
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]