Re: Requirements for a filtering header

> 6) MUAs trust tag insertion order. All filters in the
> organization agree to insert their tags at the top of the mail header.
>
> pros: easy to implement, no authentication required
> cons: only the very last filter tag can be trusted, provided
> it is certain
>       that the organization employs at least one filter. To
> trust more than
>       one filter tag, a system such as 3) or 4) is still needed.

Instead of date, what about including the IP address of the machine on
which the filter is running and allow the Path verification group to
worry about the rest?

filtered by: Sophos.myfiltering.com [a.b.c.d]
filtered by: NAI.myotherfiltering.com [e.f.g.h]

X-nai.myotherfiltering.com-virus: blah
X-Sophos.myfiltering.com-virus: foo

>
>
> I think I've covered all the current proposals, though
> perhaps not minor variations.
>
> A couple of further points: solutions 1)-4) are robust
> against header removal, eg if some agent removes or rewrites
> some headers. 5) and 6) depend on tags being left
> semantically unchanged.
>
> Every "actor" (ie the MUA, or a MDA which sorts into folders,
> or a filter which blocks messages) must deal with the
> "content trust" issue. It just cannot be ignored (which would
> be solution 1).
>
> This issue is a direct consequence of the RFC2822 message
> format, because the format doesn't separate meta information
> (ie headers) from content (ie body) in a secure way. Thus
> anybody can and does spoof meta information, and if
> successful can control actors which act on the meta
> information, like the MUA.
>
> Ok, that's quite enough for now. Hopefully, I'm not too far
> off the mark.
>
> --
> Laird Breyer.
>