Simply, RFC 6729 adds Received: headers for some state transitions
within a mail processing flow (MTA, MLM) which might cause delays.
So, how does this apply to Exim?
As long as content-scanning is done inline, that's not a main concern
for us; we're not an MLM with queues holding messages for moderation,
and we don't support holding messages for some fixed release time.
Thus the main thing would be "state quarantine" for when messages are
frozen or unfrozen, and also "state quarantine/<configurable>" so that
someone choosing to receive possible spam and put it into a spam folder
can use "state quarantine/spam" on the Router which delivers it there.
The latter case could _almost_ be done now with headers_add on the
Router (or Transport), _if_ the Router/Transport option "headers_add"
supported the same :at_start: (etc) modifiers as the ACL "add_header"
modifier. In this case, we'd be treating the delivery into the spool
box as a pseudo-Received: transition, and expect whatever software might
move the mail between mailboxes to insert a header itself. We could get
away with just :at_start: (and :at_end:), which would simplify the
changes needed.
The former case would involve more modifications for every freeze/thaw,
which I'm a little reluctant to do.
However, really the idea is to modify the _existing_ Received: header
that is going to be inserted, by adding some text _near_ the end. See
appendix item A.2 for this example:
Received: from internal.example.com
(internal.example.com [192.168.0.1])
by newyork.example.com (8.11.6/8.11.6)
with ESMTP id i9MKZCRd064134
for <secret-list@???>
state moderation (sender not subscribed);
Fri, Feb 15 2002 17:19:08 -0800
_This_ can't currently be done now, because we guarantee that the
new Received: header will be available to the DATA ACL, which is where
content scanning will happen, which is where I'd expect the quarantine
decision to be made. The timestamp is updated in-place later, not
requiring any more memory.
Perhaps we could add a new ACL modifier, "received_state_set"? Ideally,
word followed by something in parentheses, but really whatever the admin
specifies. If that is set, then where we would modify the date, scan
backwards for the semi-colon, construct a new line of the text up to the
semi-colon, a space, the modifier option value, a semi-colon and then
the new timestamp. Then replace the ->text field completely. Document
that this happens after ACL processing, so will not be visible. But
folks could use an $acl_m_<variable> to hold the desired setting _and_
make it visible.
Does anyone think this modifier is even likely to be used, so that it
becomes worth doing this?
Any thoughts, folks?
-Phil
