On 10/8/2014 8:11 PM, Ronald F. Guilmette wrote: > I posted these questions recently, but either nobody saw my posting > or else nobody thought that these questions wre worth of a reply. > > On the chance that it was the former, I am posting these questions > again... because I still do need answers. > > ================================================================== > I'm building a new policy server, and I have some questions about > the protocol. > > "Tagging" of incoming messages... so that they may be specially > handled by post-delivery tools (e.g. procmail and others) is a useful > feature. And I hope to make use of "action=PREPEND <text>" responses > in my policy server to perform such tagging. All of my (3) questions > below relate to such tagging. > > > 1) With regards to the "action=PREPEND <text>" response that can be > yielded by a policy server, is there any way that this can be used > to inject more than one new header into the message currently being
The "one query, one response" model from the rest of postfix holds true for the policy service interface too. > > 2) Also with respect to the "action=PREPEND <text>" response that can > be returned by a policy server, I am wondering if Postfix undertakes > any formatting of the <text> material before it prepends it to the No text formatting is done. > 3) I had hoped to be able to have my new policy server run, once > only, for each incoming message, at MAIL FROM time. So naturally. > I inserted the rule to invoke it underneath my smtpd_sender_restrictions > in my main.cf file. However when I had the policy server log (to a > file) all of the material in the requests it was receiving from > Postfix I was, confused, at first to find that in the requests it > was receiving, the protocol_state parameter was always set to > "RCPT" rather than "MAIL". Then I realized the essential cause of > this, i.e.: > > smtpd_delay_reject = yes > > Obviously, and as documented, smtpd_delay_reject was causing the > "restrictions" listed in my smtpd_sender_restrictions list to be > delayed until the RCPT TO phase. Yes, this is documented. > > That delay, in and of itself is not really a problem for me. What > _is_ a bit of a problem is the fact that smtpd_delay_reject doesn't > merely cause anything listed under smtpd_sender_restrictions to be > delayed until such time as the _first_ RCPT TO is seen, but rather > it causes each of the things listed under smtpd_sender_restrictions > to be reevaluated, once for each RCPT TO. Yes, this is an implementation artifact. I don't know if it's worth fixing since it rarely causes an issue. Typically, policy services that only need to be run once are put in smtpd_data_restrictions. One thing to be aware of with smtpd_data_restrictions is the recipient list will be empty for multirecipient mail, but that doesn't sound as if it's a problem for your application since you appear to be only concerned with the sender. -- Noel Jones
