Wietse Venema wrote:
> Wietse Venema:
>> Postfix VSTREAMs automatically flush output on the next read
>> operation; a lot of things depend on this, including the SMTP client
>> and SMTP server protocol implementations. This is how Postfix avoids
>> sending silly little network packets.
>>
>> In the case of skipping Milter replies, the idea is that queued
>> SMFIC_RCPT messages will be eventually be flushed when Postfix
>> reads a response from the Milter application; normally that
>> would be at or before the end-of-body reply.
>>
>> I am surprised that the VSTREAM doesn't flush SMFIC_RCPT as it
>> should; normally one has to jump ugly hoops to lose output like
>> that.
>
> My hypothesis is as follows: the automatic flush-before-read did
> not happen, because the write and the read operations were done
> in different processes (and therefore, on different VSTREAMs).
>
> Specifically, the VSTREAM in the smtpd process did not automatically
> flush RCPT requests to the Milter socket, because the next read
> request on that Milter socket was done on a different VSTREAM in
> a cleanup process.
>
> Please see if the patch below solves the problem.
Yes, it does. Thanks.
> *** ./milter8.c- Sat Jul 11 20:27:15 2009
> --- ./milter8.c Fri Sep 18 16:38:11 2009
> ***************
> *** 2584,2589 ****
> --- 2584,2596 ----
> if (msg_verbose)
> msg_info("%s: milter %s", myname, milter->m.name);
>
> + /*
> + * The next read on this Milter socket happens in a different process.
> It
> + * will not automatically flush the output buffer in this process.
> + */
> + if (milter->fp)
> + vstream_fflush(milter->fp);
> +
> if (attr_print(stream, ATTR_FLAG_MORE,
> ATTR_TYPE_STR, MAIL_ATTR_MILT_NAME, milter->m.name,
> ATTR_TYPE_INT, MAIL_ATTR_MILT_VERS, milter->version,
