Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

RCPT delays and PIPELINING

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


ph10 at hermes

Feb 1, 2007, 4:09 AM

Post #1 of 16 (945 views)
Permalink
RCPT delays and PIPELINING

I thought I'd post this so that it gets into the archive. Sites that use
the "delay" modifier in the RCPT ACL (either in conjunction with
"ratelimit" or otherwise) might run into problems with PIPELINING.

The PIPELINING extension to SMTP is supposed to make better use of the
network. Using PIPELINING, a client can send MAIL, RCPT, RCPT, ..., DATA
all at once, without waiting for a response in between. The client then
waits for the responses to come back, in order. The server does not need
to flush its output buffer until it has run out of input from the
client. The idea is that in many cases, all the commands from MAIL to
DATA will fit into a single packet, and likewise all the responses will
go back in a single packet. Without PIPELINING, there is a packet
exchange for each command.

Exim, as a server, advertises PIPELINING by default, and as a client, it
uses PIPELINING if the server advertises it. You can suppress the
advertisement (globally, or to specific hosts) by setting
pipelining_advertise_hosts.

A problem arises if the server starts applying delays when it responds
to RCPT commands, because the client won't see any response at all until
either the server's output buffer fills up, or DATA has been processed.
For example, if the client sends MAIL, RCPT, RCPT, RCPT, DATA all in one
packet, and the server applies a 1-minute delay to each RCPT, the client
will see a 3-minute delay before any response at all is received (it
will be waiting for a response to MAIL). It doesn't take too many small
delays to add up to 5 minutes - which is a typical client timeout time.

PIPELINING was invented to speed things up; delays were invented to slow
things down. They don't play well together. :-(

A feature of the next release of Exim (already in the snapshots) is

control = no_pipelining

This makes it possible to disable pipelining for certain clients based
on any criteria that an ACL supports, not just the host identity (which
is all you have with pipelining_advertise_hosts). However, you have to
disable before the response to EHLO is sent in order for it to work.

Bottom line: if you are using delays with RCPT commands, consider the
PIPELINING consequences.

A thought: as I wrote this, it occurred to me that maybe there is a way
that Exim can take note of having obeyed "delay", and if so, force out
its output buffer after it has written the next response, instead of
waiting until it has run out of input. If possible, that would solve
this issue automatically. Any views on this idea?

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


holmgren at lysator

Feb 1, 2007, 4:19 AM

Post #2 of 16 (912 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

On Thursday 01 February 2007 13:09, Philip Hazel wrote:
> A thought: as I wrote this, it occurred to me that maybe there is a way
> that Exim can take note of having obeyed "delay", and if so, force out
> its output buffer after it has written the next response, instead of
> waiting until it has run out of input. If possible, that would solve
> this issue automatically. Any views on this idea?

Would it cause trouble if Exim flushed its output as soon as it encounters
a "delay" modifier?

--
Magnus Holmgren holmgren [at] lysator
(No Cc of list mail needed, thanks)

"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans


ph10 at hermes

Feb 1, 2007, 4:23 AM

Post #3 of 16 (918 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

On Thu, 1 Feb 2007, Magnus Holmgren wrote:

> On Thursday 01 February 2007 13:09, Philip Hazel wrote:
> > A thought: as I wrote this, it occurred to me that maybe there is a way
> > that Exim can take note of having obeyed "delay", and if so, force out
> > its output buffer after it has written the next response, instead of
> > waiting until it has run out of input. If possible, that would solve
> > this issue automatically. Any views on this idea?
>
> Would it cause trouble if Exim flushed its output as soon as it encounters
> a "delay" modifier?

I suppose that's another way of doing it, but it seemed to me that it
might be better to do the flush after it has done the delay. I suspect
that it doesn't much matter which way round it is done.

But I am really interested in views as to whether doing the automatic
flush is a good idea or not.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


wbh at conducive

Feb 1, 2007, 4:32 AM

Post #4 of 16 (919 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

Philip Hazel wrote:
> I thought I'd post this so that it gets into the archive. Sites that use
> the "delay" modifier in the RCPT ACL (either in conjunction with
> "ratelimit" or otherwise) might run into problems with PIPELINING.
>
> The PIPELINING extension to SMTP is supposed to make better use of the
> network. Using PIPELINING, a client can send MAIL, RCPT, RCPT, ..., DATA
> all at once, without waiting for a response in between. The client then
> waits for the responses to come back, in order. The server does not need
> to flush its output buffer until it has run out of input from the
> client. The idea is that in many cases, all the commands from MAIL to
> DATA will fit into a single packet, and likewise all the responses will
> go back in a single packet. Without PIPELINING, there is a packet
> exchange for each command.
>
> Exim, as a server, advertises PIPELINING by default, and as a client, it
> uses PIPELINING if the server advertises it. You can suppress the
> advertisement (globally, or to specific hosts) by setting
> pipelining_advertise_hosts.
>
> A problem arises if the server starts applying delays when it responds
> to RCPT commands, because the client won't see any response at all until
> either the server's output buffer fills up, or DATA has been processed.
> For example, if the client sends MAIL, RCPT, RCPT, RCPT, DATA all in one
> packet, and the server applies a 1-minute delay to each RCPT, the client
> will see a 3-minute delay before any response at all is received (it
> will be waiting for a response to MAIL). It doesn't take too many small
> delays to add up to 5 minutes - which is a typical client timeout time.
>
> PIPELINING was invented to speed things up; delays were invented to slow
> things down. They don't play well together. :-(
>
> A feature of the next release of Exim (already in the snapshots) is
>
> control = no_pipelining
>
> This makes it possible to disable pipelining for certain clients based
> on any criteria that an ACL supports, not just the host identity (which
> is all you have with pipelining_advertise_hosts). However, you have to
> disable before the response to EHLO is sent in order for it to work.
>
> Bottom line: if you are using delays with RCPT commands, consider the
> PIPELINING consequences.
>
> A thought: as I wrote this, it occurred to me that maybe there is a way
> that Exim can take note of having obeyed "delay", and if so, force out
> its output buffer after it has written the next response, instead of
> waiting until it has run out of input. If possible, that would solve
> this issue automatically. Any views on this idea?
>

Yes.

From the time we discovered that Exim could do so, we have had advertisement of
pipelining OFF, enforce sync ON, and drop sync requirement on successful auth
for submission. Works well, and catchs 'some few' garbage servers out. Bothers
legitimate servers not at all.

So - never had the conflict, even when using delays.

The benefits of pipelining, OTOH, can no doubt be demonstrated.

BUT - with all the other things going on, I suspect that for some very high
percentage of real-world traffic, either one side or the other will not
support/make use of or gain much from pipelining *anyway*. Rationale is the
prevalence of single-recipient traffic, where there is little to gain.

Grant - it may well be a Godsend for *really* heavy traffic 'routes' - say
between and among gmail, MSN, Yahoo user communities. Or perhaps, in 'Exim land'
among busy university servers.

So I don't 'recommend' disabling pipelining. In the default, or otherwise.

And I do see value in 'more tools'. Generally.

But there is probably more meat on other bones than to add finer granularity w/r
mixing delays and pipelining.

I suspect most who use delays do as we do - NOT work pipelining at all - and
would not change that even if Exim supported a 'mix'.

JM2CW

Bill






--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


jh at plonk

Feb 1, 2007, 4:54 AM

Post #5 of 16 (917 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

Quoting Philip Hazel:

> But I am really interested in views as to whether doing the automatic
> flush is a good idea or not.

I am also in favour of the flush-before-delay. The client will get the
responses for the previous commands, so he will have at least that, and
the server will not appear to be completely stuck. The behaviour is more
"natural", I'd say, and it's better for debugging.

We could introduce modifiers for the delay keyword (like "delay =
10s/noflush"), if somebody wants the old behaviour, but it's probably
not worth it.

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


wbh at conducive

Feb 1, 2007, 5:02 AM

Post #6 of 16 (913 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

Jakob Hirsch wrote:
> Quoting Philip Hazel:
>
>> But I am really interested in views as to whether doing the automatic
>> flush is a good idea or not.
>
> I am also in favour of the flush-before-delay. The client will get the
> responses for the previous commands, so he will have at least that, and
> the server will not appear to be completely stuck. The behaviour is more
> "natural", I'd say, and it's better for debugging.
>
> We could introduce modifiers for the delay keyword (like "delay =
> 10s/noflush"), if somebody wants the old behaviour, but it's probably
> not worth it.
>

Given the (potentially) torturous nature of a pipelined 'session' will it not:

- take a lot more coding and testing in Exim to insure nothing breaks than the
gain may justify?

- have a reasonable chance of finding 'appropriate' handling at the far-end?

The second part concerns me more than the first as:

- it is beyond 'our' control.

- many of the 'majority' MTA have rather poor reputations for doing things
'correctly' in general.

IOW - even given the tools, will we find a frequent need to make exemptions - or
even turn them off?

Personally, I'd rather give up delays if need be.... which breaks nothing.

JM2CW

Bill

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


exim-users at lists

Feb 1, 2007, 5:05 AM

Post #7 of 16 (915 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

* on the Thu, Feb 01, 2007 at 01:54:21PM +0100, Jakob Hirsch wrote:

>> But I am really interested in views as to whether doing the automatic
>> flush is a good idea or not.
> I am also in favour of the flush-before-delay. The client will get the
> responses for the previous commands, so he will have at least that, and
> the server will not appear to be completely stuck. The behaviour is more
> "natural", I'd say, and it's better for debugging.

imo, the expected behaviour would be for it to auto-flush, so I vote
to go ahead with this change.

> We could introduce modifiers for the delay keyword (like "delay =
> 10s/noflush"), if somebody wants the old behaviour, but it's probably
> not worth it.

If you're only using very short delays and autoflushing, it half defeats
the point of pipelining come to think of it. Perhaps, there should be a
control to enable/disable it?

Mike

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


exim-users at lists

Feb 1, 2007, 5:09 AM

Post #8 of 16 (917 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

* on the Thu, Feb 01, 2007 at 01:05:04PM +0000, Mike Cardwell wrote:

>> We could introduce modifiers for the delay keyword (like "delay =
>> 10s/noflush"), if somebody wants the old behaviour, but it's probably
>> not worth it.
> If you're only using very short delays and autoflushing, it half defeats
> the point of pipelining come to think of it. Perhaps, there should be a
> control to enable/disable it?

RFC2920 states in section "3.2. Server support of pipelining" :

(2) SHOULD elect to store responses to grouped RSET, MAIL FROM,
SEND FROM, SOML FROM, SAML FROM, and RCPT TO commands in an
internal buffer so they can sent as a unit.

It's only a "should" rather than a "must", but doing the auto-flush kind
of goes against this.

Mike

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


holmgren at lysator

Feb 1, 2007, 6:15 AM

Post #9 of 16 (928 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

On Thursday 01 February 2007 14:05, Mike Cardwell wrote:
> * on the Thu, Feb 01, 2007 at 01:54:21PM +0100, Jakob Hirsch wrote:
> > We could introduce modifiers for the delay keyword (like "delay =
> > 10s/noflush"), if somebody wants the old behaviour, but it's probably
> > not worth it.
>
> If you're only using very short delays and autoflushing, it half defeats
> the point of pipelining come to think of it. Perhaps, there should be a
> control to enable/disable it?

The shortest delay is one second. That is in the vast majority of cases well
above the round-trip time. PIPELINING is meant to save time by saving
round-trips. That time is gone anyway when you deliberately delay the SMTP
dialog. Fewer round-trips also means much less overhead to the MAIL, RCPT and
DATA commands, and slightly less overhead overall. But does that matter? In
any case, "delay" is not something you use in normal cases, is it? It's
something you typically use to slow down [suspected] spammers. (Always
inserting a short pause before the initial banner is a common trick to trap
ratware that doesn't follow the sync rules, but that is before PIPELINING
comes into action.)

--
Magnus Holmgren holmgren [at] lysator
(No Cc of list mail needed, thanks)

"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans


ph10 at hermes

Feb 1, 2007, 6:56 AM

Post #10 of 16 (906 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

On Thu, 1 Feb 2007, W B Hacker wrote:

> Given the (potentially) torturous nature of a pipelined 'session' will it not:
>
> - take a lot more coding and testing in Exim to insure nothing breaks than the
> gain may justify?

No. It can do no harm to flush the output, just (perhaps) degrade
performance. There is nothing to stop a server doing the flush always,
though that defeats the idea of PIPELINING.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


ph10 at hermes

Feb 1, 2007, 6:58 AM

Post #11 of 16 (900 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

On Thu, 1 Feb 2007, Mike Cardwell wrote:

> If you're only using very short delays and autoflushing, it half defeats
> the point of pipelining come to think of it. Perhaps, there should be a
> control to enable/disable it?

There has been pipelining_advertise_hosts for a long time, and there is
a control in the current snapshot.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


ph10 at hermes

Feb 1, 2007, 7:02 AM

Post #12 of 16 (905 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

On Thu, 1 Feb 2007, Mike Cardwell wrote:

> RFC2920 states in section "3.2. Server support of pipelining" :
>
> (2) SHOULD elect to store responses to grouped RSET, MAIL FROM,
> SEND FROM, SOML FROM, SAML FROM, and RCPT TO commands in an
> internal buffer so they can sent as a unit.
>
> It's only a "should" rather than a "must", but doing the auto-flush kind
> of goes against this.

Yes, but that was written a while ago, probably before anybody was
thinking about using delays. Sites probably SHOULD turn off PIPELINING
when using delays, but if we introduce auto-flush, Exim will cause less
trouble when delays are introduced without doing this.

Besides, you often can't decide whether to use delays till long after
EHLO, which is your only chance to disable PIPELINING.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


exim-users at lists

Feb 1, 2007, 9:14 AM

Post #13 of 16 (908 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

* on the Thu, Feb 01, 2007 at 02:58:07PM +0000, Philip Hazel wrote:

>> If you're only using very short delays and autoflushing, it half defeats
>> the point of pipelining come to think of it. Perhaps, there should be a
>> control to enable/disable it?
> There has been pipelining_advertise_hosts for a long time, and there is
> a control in the current snapshot.

Sorry, I wasn't clear. I'm aware of that ability. I meant a control to
enable/disable auto-flushing.

Mike

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


jwblist3 at olympus

Feb 1, 2007, 3:08 PM

Post #14 of 16 (918 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

On 2/1/07 4:09 AM, "Philip Hazel" <ph10 [at] hermes> wrote:

> Bottom line: if you are using delays with RCPT commands, consider the
> PIPELINING consequences.

I shut off pipelining shortly after we started our greylisting. I saw
problems with a few sending MTAs I thought related to greylisting. Perhaps
they related to delay instead (my colleague also inserted a couple of short
delays, but far from enough in total to trigger the "5 minute problem").

Either way, those problems went away with no pipelinging.

As we're small enough to have limited impact on the 'Net through turning off
pipelining, I haven't investigated further, although it would seem
friendlier to have it on when possible.

>
> A thought: as I wrote this, it occurred to me that maybe there is a way
> that Exim can take note of having obeyed "delay", and if so, force out
> its output buffer after it has written the next response, instead of
> waiting until it has run out of input. If possible, that would solve
> this issue automatically. Any views on this idea?

Sounds good, if it can be implemented safely and easily. (This or the idea
of flushing upon an executed delay.) Doesn't sound good if it entails major
work to be bulletproof.

Meanwhile, I should take a look at our delays after EHLO response time, to
see whether perhaps they aren't doing what the colleague hoped.

I should also look again at our submission side--extra round trips over
dialup--our dialup submissions reach us over the Internet--or even 256K DSL
are unfortunate. Hmmm.

And back to your initial paragraph: getting this discussion into the
archives is a very good thing.

--John



--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


ph10 at hermes

Feb 2, 2007, 2:34 AM

Post #15 of 16 (906 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

On Thu, 1 Feb 2007, Mike Cardwell wrote:

> > There has been pipelining_advertise_hosts for a long time, and there is
> > a control in the current snapshot.
>
> Sorry, I wasn't clear. I'm aware of that ability. I meant a control to
> enable/disable auto-flushing.

Noted.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/


ph10 at hermes

Feb 5, 2007, 4:39 AM

Post #16 of 16 (905 views)
Permalink
Re: RCPT delays and PIPELINING [In reply to]

On Thu, 1 Feb 2007, Mike Cardwell wrote:

> * on the Thu, Feb 01, 2007 at 01:54:21PM +0100, Jakob Hirsch wrote:
>
> > I am also in favour of the flush-before-delay. The client will get the
> > responses for the previous commands, so he will have at least that, and
> > the server will not appear to be completely stuck. The behaviour is more
> > "natural", I'd say, and it's better for debugging.
>
> imo, the expected behaviour would be for it to auto-flush, so I vote
> to go ahead with this change.

I have committed a patch that implements this change, along with control
= no_delay_flush to disable it, just in case anybody wants to. A test
with Exim as both client and server displays the two behaviours nicely
(one times out, the other works).

Philip

--
Philip Hazel, University of Cambridge Computing Service.

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.