On 28 Apr 2015, at 13:30, Wietse Venema wrote:
Bill Cole:
Also, the setting "smtpd_delay_open_until_valid_rcpt = no" assures
that
the queue ID is known at RCPT time, making it possible for Postfix to
provide it to milters as the default setting says it will.
This is not the default because it can increase queue activity by
an order of magnitude or more, at least for servers that reject the
majority of all mail delivery requests (creating and deleting queue
files is by far the most expensive part of Postfix queue management).
Understood. I'm not arguing against that default, which is important for
machines that have substantial volume and don't turn away most of it
with postscreen. However, the existence of postscreen has substantially
expanded the range of sites where the disk-thrashing risk of
"smtpd_delay_open_until_valid_rcpt = no" is small enough to be worth
gaining deterministic log correlation.
In the time since that text in MILTER_README was written, Milter
applications have been written to handle the case that {i} is not
available before the DATA command.
Yes, but that text in conjunction with the table of macro availability
has apparently led to at least one Milter application (MIMEDefang) to be
written to presume the unconditional unavailability of {i} at RCPT in
all cases, even though {i} is provided for all recipients when
smtpd_delay_open_until_valid_rcpt = no and apparently (based on the
default milter_rcpt_macros) also would be for recipients subsequent to
Postfix accepting a valid one for the message with the default setting.
Are you are willing to consider changing MILTER_README to more precisely
describe that conditional availability of {i} if I propose specific
wording?
