On 2012-01-11 at 13:10 -0800, Murray S. Kucherawy wrote:
> 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 exim be willing to implement something like this? It may be that you have no processing modes or responses like "quarantine" that would apply so maybe it's not applicable at all, but it's worth it to ask.
Nearest equivalent would be that messages can be "frozen" and "thawed"
on the queue, so if the message is frozen/thawed, the command-line tool
could be extended to support a more descriptive tag that could make it
into a Received: header.
However, the Exim way tends to be to delivery _out_ of the queue rather
than leave mail accumulated there; perhaps to a batch-SMTP-format
holding area. Re-injection would then send the mail on. Exim itself
does not ship with any kind of quarantine system as part of the standard
configuration, it just supplies enough flexibility to offer a couple of
approaches for building a quarantine system.
Given the current queue management's scalability limits, I'd be a little
reluctant to extend freeze/thaw in such a way as to encourage their bulk
use, but perhaps after we have multiple queues as first-class managed
concepts it would make more sense. That work is only at the "sketched
out, folks agreed in principle" stage and has been for a couple of
years, waiting for the work to be put in to do it.
-Phil
