From: Keean Schupke (keeanfry-it.com)
Date: Wed Nov 21 2007 - 12:31:41 CST

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

Hi,

Comments inline:

On 21/11/2007, Victor Duchovni <Victor.Duchovnimorganstanley.com> wrote:
> On Wed, Nov 21, 2007 at 06:15:22PM +0000, Keean Schupke wrote:
>
> > Hi,
> >
> > Again, not my problem. The organisation gateway is already in place,
> > and so is their password policy. Their gateway cannot always cope with
> > the load, which is one of the reasons we are supplying relay servers.
> >
> > The password lockout may count consecutive failures or cumulative
> > failures, I would like to be able to cope with both, as that feature
> > is not implemented by us, and may change when the system is upgraded
> > in 2008. We have to assume the new password is not available up front.
> >
> > As I said, I just need to authenticate to the server (working), queue
> > mails when authentication fails (working as per submitted patch), and
> > now finally stop trying to deliver to this destination after one
> > authentication failure, and only retry the authentication when the
> > credentials have been updated. Surely this is not such a bad
> > feature... If we know a given set of credentials are bad, why retry
> > them over and over again... they are not magically going to start
> > working, and it is creating unnecessary network traffic.
>
> You can't stop multiple in-flight authentication attempts when the first
> fails. So parallelism must be avoided. This has performance consequences.
>
> If the concurrency limit is 1, Postfix will throttle on the first failure
> (this may change in 2.5, but controls will be provided to restore the
> default fragile behaviour if that's what you need).
>
> You then have ~300s for the log-parser to catch up and add the the
> transport to "defer_transports".
>
> Probably the best that can be done, and no patches to smtp(8) required.

Log parser seems a flakey soluton, when we can have a rock solid,
in-step solution in the sasl auth protocol, and reduce unnecessary
network traffic too.

>
> > Good point about serialising the authentication requests... I have set
> > "default_destination_concurrency_limit" to one in my configuration.
>
> Is there only one destination from this system? Otherwise I would
> recommend a transport-specific setting, with just the broken destination
> routed to the serialized transport.

The sole purpose of this relay is to queue mail going into the gateway.

>
> > This proxy as you describe it, queueing mail and serialising
> > authentication requests, is exactly what I am using postfix to do...
> > and it seems to be doing a pretty good job so far (live tests of the
> > patch I submitted, with high traffic volume are going on at the
> > moment)...
>
> What does "high volume" mean? Is a concurrency of "1" sufficient to meet
> this volume requirement without excessive delay?
>

See above answer, if the serial auth to the gateway cannot cope, we queue.
High volume means peaky. If we hit the limit of one machine, a second
machine using a _different_account_ to login can be set up.

Cheers for the comments by the way... it might not seem like it, but
it is all helpful in the end...

Regards,
Keean Schupke, Fry-IT Ltd.

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