Re: Summary of Issues Raised to date
Philip Miller <[email protected]> Tue, 16 Mar 2004 16:58:05 -0500
| Newsgroups | gmane.ietf.asrg.filtering |
|---|---|
| Message-ID | <[email protected]> |
David Nicol wrote:
> Laird Breyer wrote:
>> - Spoofed [category] tags. How does a filter deal with them?
>
> this sounds like a job for capability keys.
>
> What I mean by that is, instead of the delivered message containing
> ("bearing") a token that indicates the grade of it and so on, the
> delivered message would contain a key with which the MUA could look up a
> grade in the MTA's database of filter results, in effect a "book" system
> for communicating filter results.
>
> A standard would be required for interoperability. There has not been a
> lot of tag forging because the various tagging filters all use their own
> tags. (I don't use a tagging filter at this time except for my cpan.org
> address which runs through spamassassin. Is there spam being sent now
> with forged SA headers?)
>
> With a standard way to specify an identifying key (the individual mesasge
> IDs from POP would work just fine) we just push the standardizing of the
> declarationof the filter results to what the MUA gets in return for
> presenting the key. No gain really.
I don't like the idea of having the MUA have to contact whatever upstream
server in more ways than it takes to download the message.
I think a better way to verify the authenticity of a filtering header would
be a simple signature calculated on a deterministic checksum of the rest of
the header and included in the header. We need some way to inform the MUA of
the public complement to the signing key, but that's a fairly simple matter.
(Hell, we could even throw it in the DNS! :-)
> A better way might be to have a filtering MTA flatly refuse to accept any
> mail in that is already displaying the filter headers of the kind that it
> will add (unless of course it is a trusted peer, and we do _NOT_ specify
> a way to automate aquisition of trust)
This is flat-out asking for trouble.
> Implementing such a refusal policy would require filtering MTAs to
> differentiate between internal and external delivery
As is this.
> So all in all I don't think I've added anything to the discussion with
> this post.
If nothing else, you've provided inspiration.
Carry on
> Carry on
>
> Another general solution
Was something supposed to follow that line?
Philip Miller