Re: Including state information in Received fields
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.
Re: Including state information in Received fields
On Thu, Jan 12, 2012 at 12:10 AM, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Wednesday, January 11, 2012 5:46 PM To: Postfix users Subject: Re: Including state information in Received fields But design issues aside, would you consider implementing it at some point? Indications of interest like that would be useful input to the IETF. In my sysadmin career it would have saved me a lot of work figuring out why something was delayed at one particular hop. Log analysis tools might also find it useful, but I haven't tried to sell them on the idea yet. I've found that people don't always want to have this made known. When tracking down why did mail take X hours to reach my friend's inbox issues, it would be quite the embarrassment to have the tracer headers show that my work was being rate limited by ISP X.
RE: Including state information in Received fields
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Peter Blair Sent: Wednesday, January 11, 2012 10:21 PM To: Postfix users Subject: Re: Including state information in Received fields I've found that people don't always want to have this made known. When tracking down why did mail take X hours to reach my friend's inbox issues, it would be quite the embarrassment to have the tracer headers show that my work was being rate limited by ISP X. The MTA being subjected to rate limiting would have to know it's being rate-limited in order to be able to log that in a state clause. If all it's getting is temp-fails, it doesn't know it's in such a state. The intent here is to enable an MTA to log that a message is in a particular state when the local MTA (or an adjacent local component like an MLM) is the one making that decision, not when some downstream MTA (i.e. the next hop) is doing so.
