------- 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: [email protected] ReportedBy: [email protected] CC: [email protected] 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 <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
