[Mimedefang] Any way to get MD to accept a Postfix queue ID at RCPT time?

[Bill Cole]

Background:
    Historically, Postfix has by default not allocated SMTP transaction 
IDs until relatively late in the SMTP conversation because doing so 
robustly costs a tiny synchronous filesystem operation, which can be a 
performance issue on high-volume machines. However, for the sake of 
having logs that can be deterministically parsed, there is a 
'smtpd_delay_open_until_valid_rcpt=no" setting which has become widely 
popular since its introduction in v2.3. This means that in theory 
MIMDefang can know the transaction ID in filter_recipient and in fact 
the default Postfix setting for the list of macros to offer milters at 
RCPT includes 'i' (which is the transaction ID.)

Problem:
    MIMEDefang seems to have internalized the fact that traditionally 
(and still by default) Postfix provides no 'i' until after it has 
decided to accept at least one recipient.  So this overkill logging line 
in filter_recipient:

    md_syslog ('info', "$QueueID: filter_recipient args: $recipient, 
$sender, $ip, $hostname, $first, $helo, $rcpt_mailer, $rcpt_host, 
$rcpt_addr");

Results in log sequences like this:

    Apr 28 10:11:03 toaster postfix/smtpd[74161]: 3lblJ70DYWz1YV92n: 
client=roaringpenguin.com[70.38.112.54]
    Apr 28 10:11:03 toaster mimedefang.pl[66886]: NOQUEUE: 
filter_recipient args: <mdlist-20140424 at billmail.scconsult.com>, 
<mimedefang-bounces at lists.roaringpenguin.com>, 70.38.112.54, 
roaringpenguin.com, <mdlist-20140424 at billmail.scconsult.com>, 
colo3.roaringpenguin.com, relay, billmail.scconsult.com, 
mdlist-20140424 at billmail.scconsult.com

"NOQUEUE" being the traditional Postfix way of saying that it has no ID 
yet, which MD seems to have adopted. Note that Postfix absolutely knows 
a queue ID here, as it logs it right before it calls MD. With Postfix 
debug logging I have confirmed that Postfix is offering the ID, but 
mimedefang is not using it:

	Apr 28 13:05:41 toaster postfix/smtpd[77325]: milter_macro_lookup: "i"
	Apr 28 13:05:41 toaster postfix/smtpd[77325]: milter_macro_lookup: 
result "3lbq9T0NQ3z1YVB34"
	Apr 28 13:05:41 toaster postfix/smtpd[77325]: milter8_rcpt_event: 
milter unix:/var/spool/MIMEDefang/mimedefang.sock: rcpt <postmaster>
	Apr 28 13:05:41 toaster postfix/smtpd[77325]: event: SMFIC_RCPT; 
macros: _=localhost [127.0.0.1] {daemon_name}=toaster.scconsult.com 
i=3lbq9T0NQ3z1YVB34 j=toaster.scconsult.com {mail_addr}= 
{mail_host}=toaster.scconsult.com {mail_mailer}=local 
{rcpt_addr}=postmaster at toaster.scconsult.com 
{rcpt_host}=toaster.scconsult.com {rcpt_mailer}=local 
i=3lbq9T0NQ3z1YVB34
	Apr 28 13:05:41 toaster postfix/smtpd[77325]: vstream_fflush_some: fd 8 
flush 314
	Apr 28 13:05:41 toaster mimedefang.pl[66886]: NOQUEUE: filter_recipient 
args: <postmaster>, <>, 127.0.0.1, localhost, <postmaster>, localhost, 
local, toaster.scconsult.com, postmaster at toaster.scconsult.com

I see no way to explicitly tell MD that it should expect a queue ID from 
Postfix at RCPT time (which it *MIGHT* depending on the config of 
Postfix and/or whether there's been one good recipient already) but I 
would be overjoyed to be informed of my aging eyes overlooking something 
in the docs. ( 
http://lists.roaringpenguin.com/pipermail/mimedefang/2010-June/035833.html 
suggests that the set of macros MD wants at each stage is fixed, defined 
in the C portion of the software, and maybe special-cased for Postfix, 
but I haven't gone code-diving just yet...)