Andreas Schuldei:
> * Wietse Venema ([EMAIL PROTECTED]) [081022 02:37]:
> > Andreas Schuldei:
> > > The goal is that the server starts sending mail every 10th
> > > second, then after 50 mails increase to 2 mails every 10 seconds,
> > > until it sends 10 mails every then seconds, ramping up
> > > slowly.
> >
> > It inserts 10s delay between INDIVIDUAL deliveries.
> >
> > The documentation says:
> >
> > default_destination_rate_delay (default: 0s)
> > The default amount of delay that is inserted between INDIVIDUAL
> > deliv-
> > eries to the same destination
> >
> > Thus, with default_destination_rate_delay=10s, after one INDIVIDUAL
> > delivery is completed, the next INDIVIDUAL delivery starts 10
> > seconds later.
> >
> > INDIVIDUAL delivery != PARALLEL delivery.
>
> yes, i got that now. I had not gotten that impression when i read
> the documentation the first few times and even when i observed
> the behaviour.
The _destination_rate_delay feature solves one specific problem:
providers with a hard limit of a small number of messages (ex: 100)
over a large unit of time (ex: 1 hour or 1 day). This is naturally
implemented with fixed inter-message time spacing; this approach
minimizes the over-all delay.
> Partly because i dont see a good reason why the
> delay cant be combined with the slow start.
That looks like the opposite of _destination_rate_delay. Instead
of an upper bound on the number of deliveries (to stay within an
acceptable use policy), you want an upper bound on the amount of
time (so Postfix keeps up with the volume of mail it has to deliver).
One is implemented with a fixed delivery rate, the other isn't.
> Now if this is so i dont see a good way to not create peeks in my
> mail delivery from my high bandwidth connection to other such
> places, still dynamically ramp up the delivery volume as volume
> increases and still not be branded as a spammer (who tend to send
> email in bursts).
Pretty much every MTA in existence will try to deliver mail as soon
as it enters its queue, so I don't think that only spammers have
a monopoly on bursty behavior.
> when looking at the recipent domains of our site, gmail and
> hotmail take up a big percentage of our mail volume. Whenever i
> send with default_destination_rate_delay = 0s, in order to be
> able to use dynamicly increasing volume, I get these steep peeks
> as mail delivery is virtually instantanious between hotmail,
> gmail and our box. With default_destination_rate_delay set to a
> non-zero value however i cant respond to increased mail volume anymore.
>
> Therefor i ask to make both features combineable or create a way
> to otherwise have dynamic slow delivery (with the option to
> become faster over time).
What you need is something that spreads out the deliveries in time
such that, on average, one burst of email is delivered before the
next burst of email arrives in the queue.
That has nothing to do with slow start or with concurrency feedback,
so it must not be built on top of those mechanisms.
Instead, it requires a per-destination delay between the starts of
deliveries, where the delay gets shorter as the length of the active
queue for that destination increases. This works completely
independently from delivery concurrencies.
Wietse
