On Wed, Sep 5, 2012 at 10:59 PM, Phil Pennock <pdp@???> wrote:
> Simply, RFC 6729 adds Received: headers for some state transitions
> within a mail processing flow (MTA, MLM) which might cause delays.
I like this concept. I hang with Murray daily in IRC, so if you have
any specific questions, email him directly and I'll prod him to not
ignore it (though he just started his new job at a place you might be
familiar with).
> 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.
In the latter case, it almost seems more appropriate for "state
content (scored spam)", though the RFC specifically did say it wasn't
the intent to categorize the message:
****
Appropriate use of this mechanism does not include associating meta-
data with the message, such as categorizing the message (e.g., the
notions of "is spam" or "was 8-bit, converted to 7-bit").
****
> 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.
I don't like adding a second header implying a second SMTP or LMTP
conversation, a procedure that said email that didn't undergo.
> The former case would involve more modifications for every freeze/thaw,
> which I'm a little reluctant to do.
Agreed.
> 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.
So some new concept of "adjust the intended received header after we
already presented it to the data acl." Not sure I like that, but I
could be convinced.
> 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.
Or maybe a new expansion variable, visible only in the data acl,
$proposed_received_header.
> Does anyone think this modifier is even likely to be used, so that it
> becomes worth doing this?
Possible.
> Any thoughts, folks?
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.
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
