------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1293
Summary: RFC 6729: new received_state_set ACL modifier.
Product: Exim
Version: N/A
Platform: Other
OS/Version: All
Status: NEW
Keywords: work:small
Severity: wishlist
Priority: medium
Component: ACLs
AssignedTo: pdp@???
ReportedBy: pdp@???
CC: exim-dev@???
Mail I wrote to exim-dev:
==========================8< cut here >8============================
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
==========================8< cut here >8============================
Todd L backs this ACL approach:
==========================8< cut here >8============================
My first reaction was to add a post data acl (for accept, blackhole
doesn't have any significance) which has an ability to modify a
header, and specifically the current proposed received header. But
the more I think about it, that seems like a bad idea. The more I
think about it, the more your idea seems straightforward and less
prone to misunderstanding.
==========================8< cut here >8============================
So, tracking bug for feature request.
-Phil
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
