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 message sent from [email protected] is now sent, as before, to [email protected] and [email protected], and also to [email protected], which redirects to [email protected]. Now the redirects would result in a message from [email protected] to [email protected], a message from [email protected] to [email protected] and a third message from [email protected] to [email protected]. 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 http://thread.gmane.org/gmane.mail.postfix.devel/2557). 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. Andre
