Post by Wietse Venema
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
message sent from ***@example.com is now sent, as before, to ***@local1.com
and ***@local2.com, and also to ***@local2.com, which redirects to
***@external.com. Now the redirects would result in a message from
***@example.com to ***@external.com, a message from ***@example.com to
***@external.com and a third message from ***@example.com to ***@external.com.
The first one would use local1.com as the SRS domain, while the other
two would use local2.com. These two latter messages could share the same
SMTP session for delivery.
With the previous clarification in mind, the scheduler API seems the
cleanest path to follow because:
1. As you pointed before, splitting messages in the queue would increase
file system load. Adding this price tag to SRS would lead mail provider
to think twice before supporting SRS.
2. As explained before, SRS doesn't always require single-recipient
deliveries, so one doesn't have to waste bandwidth when it's possible to
group deliveries; more one this subject when I present my suggestion for
the scheduler API below.
3. If such scheme is implemented, VERP could then be removed from
Postfix's core, and be implemented as a special case of what was
described above, that is, the messages wouldn't be grouped for delivery.
4. Implementing the ability to modify the envelope sender via the
scheduler API would also create an additional advantage: no more
virtual_alias_maps lookups than the ones already done by Postfix would
be necessary. Currently, a milter application needs a way to resolve
redirects by itself, because it doesn’t have access to the results of
Postfix’s own resolution (as previously discussed in
If a scheduler API is to be implemented in Postfix, here is my
suggestion of what it should accomplish:
1. Ideally, one should be able to not only tell the scheduler to switch
to single-recipient delivery mode, which, as described above, would
result in some inefficiency, but how to group recipients according to
some criteria (defined by the API user).
2. The scheduler API must allow actions to be taken when the message is
being sent. In the case of SRS specifically, this action would be to
change the envelope sender address.
3. SRS can't decide how to group the recipients just comparing orig_rcpt
and rcpt, for example, if all local recipients are delivered using LMTP,
orig_rcpt may always be different to rcpt. Moreover, if a message is
added to the queue by a SASL-authenticated SMTP session, the messaging
isn't being redirected, but being sent out, thus SRS is not even
necessary. These cases imply that the scheduler API must provide access
to the metadata associated to the message in the queue to allow API
users to make decisions on how to group the recipients.
Once this new API is available, SPF would be better implemented using
the policy API since what it's really doing is enforcing policy, and SRS
using the scheduler API to be efficient. The milter API wouldn't be
necessary for SPF/SRS anymore.