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
processed? For example, let's say that I want to build a policy
server that injects the following new headers into every message it
processes:
X-Foo: bar
X-Bar: foo
Is there a way to do that, within the existing protocol? Or must I
create, install, and activate one new policy server for each separate
header that I want to attach?
(I was thinking that it might be Nice if the protocol allowed for the
possibility of, say, a literal "\n" within the <text> portion of a
PREPEND response. If that were supported, then I could clump together
as many additional headers as I liked into a single action=PREPEND
response sent from the policy server.)
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
current message. In particular, I am wondering if Postfix will
automagically perform any folding of the new header being prepended
to the message, i.e. at points containg whitespace within the header.
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.
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. Thus, as I have just
seen, if an incoming message has multiple recipients, a policy server
which is specified as part of smtpd_sender_restrictions will run
multiple times on the same single message. That in turn implies
that if, for example, the policy server always send this response
back to Postfix:
action=PREPEND X-Foo: bar
then an incoming message which has multiple local recipients will
end up having the following prepended:
X-Foo: bar
X-Foo: bar
...
For my purposes, this is sub-optimal.
Obviously, I could solve my multiple-redundant-injected-header problem
by setting "smtpd_delay_reject=no", so that my policy server _would_
in fact be invoked, only once for each message, at MAIL FROM time.
But I am rather reluctant to make this change because I'm not sure
what the full implications of doing that might be. The documentation
is clear that some SMTP clients become confused if told to go away
too soon (i.e. immediately after MAIL FROM) but does not otherwise
elaborate.
Given that I wish to have my policy server execute only once per each
MAIL FROM, _and_ given that I do not wish to lose the benefits of
the semantics of smtpd_delay_reject, is the proper solution here
for me to move any and all restrictions that I currently have
listed under smtpd_client_restrictions, smtpd_helo_restrictions,
and smtpd_sender_restrictions and put those all under
smtpd_recipient_restrictions (preserving their proper order, of
course) *except* for the one ``restriction'', listed within my
smtpd_sender_restrictions that causes the invocation of my
tagging policy server, and then, finally set smtpd_delay_reject
to "no"?
It would seem that that exact set of changes should allow my policy
server to run at MAIL FROM time while still preserving all of my
other restrictions *and* insuring that those are only evaluated at
RCPT TO time, thus allowing me to have my cake and eat it too.
Does that all sound right to you folks? Is that the proper solution?
