I apologize for my boundless optimism. I think the "it can't be done" mantra is really "it's always been this way".
I understand that there is an impedance mismatch between the SMTP and milter protocols in that a milter is allowed to inspect and even reject an address supplied via SMTP RECV, but it is not allowed to edit it until the entire body has been processed (EOB/EOM). I see flags (SMFIP_NO*, SMFIP_NR_*) expressly intended to suppress large parts of the protocol exchange. Seems to me that for SMTP MAIL and RECV events at least, it is possible to use these flags to skip basically all of the intervening protocol goop between e.g. RECV and EOB/EOM (this works, PCAP of POC on request). I see no reason that a milter executor cannot fast forward to EOB/EOM based on these flags (seems to occur in milters when they're deciding what to ack or not); and that therefore milter edits to e.g. recipients in EOB/EOM can take place in the context of the SMTP RECV; and that a milter not desiring of this behavior can request intervening data / handshakes to disable this behavior, at least until an "allow_fast_forward" flag is decided upon (if ever). On 1/24/20 10:49 AM, Viktor Dukhovni wrote: > On Fri, Jan 24, 2020 at 10:04:26AM -0800, Fred Morris wrote: > >> I want to call a milter as a "bump in the wire" before this check to >> potentially alter local recipients prior to them ricocheting off of all >> of that shininess. >> >> net -> Postfix -> Postfix >> ^ ^ >> | | >> v v >> milter local_recip_maps > Milters get to process each SMTP command as it comes in, however > smtpd_recipient_restrictions are processed before handing off "RCPT TO" > to the milter. So the milter cannot modify the recipient address before > local_recipient_maps checks happen. > > You can use socketmap tables in local_recipient_maps if for some reason > you want to apply some non-trivial computation to the address in order > to determine whether it is valid. At least privately, the milter camp has provided aid and comfort. Whereas, nothing around domain socket support has risen above the usual background noise of people stating opinions about open source software they do not write or use; zero, nothing. Hence, milter! (At the moment I have no plans to write a milter executor and nobody has offered money, although I'd be happy to provide aid and comfort for anyone wanting to implement fast forwarding). Personally I'd rather disable the security checks preventing TCP tables in local(8) and recompile, but that's just my opinion. (I'll save my quibbles with Postfix's implementation of VRFY for another day.) -- Fred Morris
