Fred Morris:
> 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).
You are describing something that is controlled by entities outside
of Postfix.
> 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).
Always good to know this (still) works as promised.
> 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
The Milter protocol as defined supports envelope and content
modifications after SMTP END-OF-DATA. In the case of Postfix, this
means that the cleanup daemon makes the changes AFTER the entire
envelope and message are stored in a queue file.
> 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).
It requires a completely different Postfix implementation where the
smtpd daemon receives the sender or recipient change request and
makes the change in-memory, instead of the cleanup daemon receiving
the change request and making the change in-file. Although technically
possible, such a parallel implementation would be a very costly
optimization for a really rare use case.
Asking is cheap. Even explaining why it is a bad idea costs time.
Wietse
