Prev: trouble on my rules check_client_access hash:/etc/postfix/acces_client
Next: recipient delimiter ambiguity
From: Wietse Venema on 24 Jun 2010 11:39
Luciana Moreira Signed by - PrivaSphere AG:
> Hello guys,
>
> I am trying to tunne our postfix installation. In our setup we receive
> mails, pass them after an anti-virus milter to a internal mail
> processing system that uses lmtp using a content filter, and then
> forward the mail to the final destination.
>
> Since I have full control over the internal mail processing system,
> ideally I should be able to define the number of processes in such a way
> that all requests would get through without getting deferred between the
> internal hops. Unfortunately this is not the case. Several messages are
> going to the deferred queue with the mesage bellow:
> > 0EEF34A925 1247 Thu Jun 24 16:38:19 foo(a)foo.com
> > (lost connection with 171.20.1.10[171.20.1.10] while sending MAIL FROM)
> > jm-tester(a)mydomain.com

You need to reduce the CLIENT SIDE concurrency: fewer processes
in master.cf, for example.

Wietse

From: Luciana Moreira on 24 Jun 2010 12:55
Hello Wietse,

Thx a lot for your quick reply.

I thought that the client side concurrency was defined by:

1) lmtp_destination_concurrency_limit
2) the number of lmtp processes

I have set them both to 1 now and still get the same error message. So I
am starting to believe that there must be yet another configuration that
I am unaware of. I have read many pages on the topic but haven't yet
seen anything different from what I have done.

What I am missing?

regards,
Luciana

Wietse Venema wrote:
> Luciana Moreira Signed by - PrivaSphere AG:
>
>> Hello guys,
>>
>> I am trying to tunne our postfix installation. In our setup we receive
>> mails, pass them after an anti-virus milter to a internal mail
>> processing system that uses lmtp using a content filter, and then
>> forward the mail to the final destination.
>>
>> Since I have full control over the internal mail processing system,
>> ideally I should be able to define the number of processes in such a way
>> that all requests would get through without getting deferred between the
>> internal hops. Unfortunately this is not the case. Several messages are
>> going to the deferred queue with the mesage bellow:
>>
>>> 0EEF34A925 1247 Thu Jun 24 16:38:19 foo(a)foo.com
>>> (lost connection with 171.20.1.10[171.20.1.10] while sending MAIL FROM)
>>> jm-tester(a)mydomain.com
>>>
>
> You need to reduce the CLIENT SIDE concurrency: fewer processes
> in master.cf, for example.
>
> Wietse
>
>

From: Victor Duchovni on 24 Jun 2010 13:09
On Thu, Jun 24, 2010 at 06:55:47PM +0200, Luciana Moreira wrote:

> Hello Wietse,
>
> Thx a lot for your quick reply.
>
> I thought that the client side concurrency was defined by:
>
> 1) lmtp_destination_concurrency_limit

Per nexthop, provided the transport is called "lmtp", and not something
else. Do you route multiple destination domains to the LMTP transport?
If so, use a consistent nexthot destination "lmtp:[lmtp.example.com]"

However, if LMTP delivery is indirect, via mailbox_transport, then the
LMTP concurrency ceiling is actually determined by the process limit of
the local(8) delivery agent, since it is local(8) and not the queue
manager that hands off mail to lmtp(8) via mailbox_transport.

> 2) the number of lmtp processes

This is enforced by the master process and is a hard limit. If you appear
to be exceeding it from time to time, it is most likely the result of
connection caching.

> I have set them both to 1 now and still get the same error message. So I am
> starting to believe that there must be yet another configuration that I am
> unaware of. I have read many pages on the topic but haven't yet seen
> anything different from what I have done.
>
> What I am missing?

Disable LMTP connection caching if you must ensure a concurrency limit
of 1. Typically the server concurrency limit is much higher, and the
client concurrency limits fit well within the server's limit.

--
Viktor.

From: Luciana Moreira on 24 Jun 2010 13:48
Hello,

Thx again for the replies, I am starting to see the light at the end of
the tunnel :-)

I have tried to disable the lmtp connection caching by setting the
following variable on main.cf:
lmtp_cache_connection=no

but the same errors are happening.

Victor Duchovni wrote:
> On Thu, Jun 24, 2010 at 06:55:47PM +0200, Luciana Moreira wrote:
>
>
> Per nexthop, provided the transport is called "lmtp", and not something
> else. Do you route multiple destination domains to the LMTP transport?
> If so, use a consistent nexthot destination "lmtp:[lmtp.example.com]"
>
Right now we are using the lmtp as a content filter as defined in the
main.cf:

content_filter = lmtpd:171.20.1.10:7026

But I am starting to believe that this is where the problem may be
comming from even though it works perfectly besides the fact that some
messages take too long to be processed due to the deferred queueing.
Could it be that we need to set it as a transport rather than a content
filter to have the client side concurrency use my settings?

> However, if LMTP delivery is indirect, via mailbox_transport, then the
> LMTP concurrency ceiling is actually determined by the process limit of
> the local(8) delivery agent, since it is local(8) and not the queue
> manager that hands off mail to lmtp(8) via mailbox_transport.
>
>
As I mention above we deliver it via content filter.

Regards,
Luciana

From: Victor Duchovni on 24 Jun 2010 14:16
On Thu, Jun 24, 2010 at 07:48:53PM +0200, Luciana Moreira wrote:

> Hello,
>
> Thx again for the replies, I am starting to see the light at the end of the
> tunnel :-)
>
> I have tried to disable the lmtp connection caching by setting the
> following variable on main.cf:
> lmtp_cache_connection=no

Where did you get this variable from? See

http://www.postfix.org/postconf.5.html#lmtp_connection_cache_on_demand

--
Viktor.

 |  Next  |  Last
Pages: 1 2
Prev: trouble on my rules check_client_access hash:/etc/postfix/acces_client
Next: recipient delimiter ambiguity