Giorgio Luchi:
> I agree with you and with the sentence "Postfix is designed to
> work on a mail queue of any size. This is possible because Postfix
> works with a fixed memory budget.", and we don't want to break the
> architecture.
Good. The use of unbounded memory came up recently in a different
Postfix context.
> What I'm talking about at this stage, it's if the scheduling
> algorithm we are asking for could be a good choice for an "only
> outgoing/relay" SMTP server.
> I know that the instruction "foreach transport's job (round-robin
> by ip or auth-user)" is too much superficial to address completely
> the problem but, if there is interest, I'm sure that we could find
> a solution to solve the issue.
That solution would have no "foreach job in the queue".
If Postfix has room in memory for N job entries, and some customer
sends 10*N, then Postfix will not look at any other customer's mail
for some amount of time. This is because by design Postfix cannot
know what other jobs exist in the mail queue.
> I've saw the idea behind "dead destination", "preemption", "dealing
> with memory resource limits"; similar ways could be applied to our
> request: we could limit the size of the customers queue, we could
> limit the size of each customer queue with a max number of messages,
> ... (others); it may be that the solution will not be fair at 100%,
> but a little less could be enough to address the problem.
How does Postfix enforce per-destination concurrency policy, when
mail is kept in per-customer queues?
What happens when Postfix opens a queue file and discovers that
this customer's queue is full? Postfix must not open the same files
again and again in an infinite loop, and Postfix must not have
"foreach job in the queue" knowledge.
We could move such messages to the deferred queue, but that would
make queue management more expensive, replacing rename(incoming,
active) +remove() with rename(incoming, deferred) +rename(deferred,
active) +remove().
> I'd like to know if we can engage someone that works on the core
> of postfix to implement our feature. We'd like to have this feature
> on our servers and so we are also glad to pay for someone that can
> agree with us and that could collaborate with us to implement this
> request.
> I'm not so familiar with feature request in open source project,
> so I apologize if I'm not following the "right procedure".
I'm sure that each project has its "right procedure".
With Postfix the procedure is to present a design that is detailed
enough so that other people can understand how it works (a little
shorter perhaps than the scheduler_readme file). Then, people like
Victor and myself will look for problems and whether they can be
fixed.
Wietse
