Murray S. Kucherawy: > Hi, > > I'm co-authoring a draft that would add supplementary information > to Received header fields indicating when a message enters some > kind of administrative hold. This would be useful to people looking > through trace data to figure out why a message sat on a machine > for some time, if the reason is something other than a hop that > took a long time to complete for connectivity reasons. > > The draft specification is here: > https://datatracker.ietf.org/doc/draft-kucherawy-received-state/ > > Would postfix be willing to implement something like this? At a > minimum, it might be useful to use this to indicate that a milter > application requested that a message be quarantined until an > operator released it.
The opportunities for doing this with Postfix are limited. Postfix writes the Received: header at message arrival time. The decision to add a Received: state field must be made before the "250 OK" in response to end-of-data, after the message is frozen (*). Once Postfix sends "250 OK" in response to end-of-data, there is no way that a Received: header can be replaced without violating the RFC requirement that mail not be lost due to frivolous causes. Postfix stores the MTA's own Received: header right before the message header and content. The stored header can be replaced via the queue file editing routines that support the Milter protocol. I recall that for Sendmail compatibility reasons, those routines do not allow Milters to manipulate the MTA's own Received: header, but I guess some checks could be moved around so that the edit routine can go to places where Milters cannot. Wietse (*) Recipients are deleted by in-place overwriting a status byte, which is assumed to be an atomic operation.