Andre Nathan:
[ Charset UTF-8 unsupported, converting... ]
> Hi Wietse
>
> On Mon, 2012-08-13 at 17:35 -0400, Wietse Venema wrote:
> > In your case the scheduler could compare the orig_rcpt and rcpt and
> > if they differ, switch to single-recipient mode. However, I don't
> > want to maintain hard-coded versions of DKIM or SRS etcetera inside
> > Postfix. That is why I provided the Milter and SMTP policy extension
> > interfaces. In the case of SRS this would require an additional
> > extension interface for the scheduler.
>
> I have to clarify an aspect about SRS: it does not always require
> single-recipient deliveries as my example seemed to have led people here
> to think it does. To see it, extend the previous example so that the
Sure, but sending recipients one-at-a-time would be safe.
The parts of the scheduler that deliver mail are something that I
would not tinker with. This is an intricate machine.
Perhaps a safe approach is to move all code out of the scheduler
that reads receipients from file, and that invokes the trivial-rewrite
daemon to figure out where to deliver. The result of this "preprocessing"
stage is a grouping of recipients into clusters that can be delivered
in the same mail delivery transaction.
With VERP. the clusters would always have size 1, and with SRS, the
clusters may have size >1. In both cases each cluster of recipients
has its own envelope sender.
The scheduler API (actually a protocol) would then receive requests
containing (sender, recipients) and it would reply with one or more
(sender, transport, nexthop, recipients) responses. The scheduler
would append these to its per-transport-per-destination queues.
Wietse
