Re: header inventory

Philip Miller <[email protected]> Tue, 16 Mar 2004 07:42:08 -0500
Newsgroups gmane.ietf.asrg.filtering
Message-ID <[email protected]>
Jose Marcio Martins da Cruz wrote:
> Mark E. Mallett wrote:
>> On Thu, Mar 11, 2004 at 11:42:23AM +1000, Laird Breyer wrote:
> ...
>> One thing I would like to see (that I mentioned on the main list a
>> while back) is version/locus information.  Each filter would supply a
>> tuple that uniquely identifies the filter and its location in the
>> delivery chain.  (None of the examples posted so far do this, although
>> one might be able to infer some of it by the header location in
>> relation to other added headers-- however I don't think people
>> mentioned where they were adding the headers.)  Required information
>> might include:
>>
>>    - filter name and version
> 
> Filter name Yes. But version is really important ?

I think version is. Knowing the name of a filter does no good if it's a
piece of software whose design has been completely overhauled 3 times in the
past year.

>>    - server name/IP information
>>    - delivery address or other key
> 
> What to you meant by delivered address ? Recipients ? I'm not sure this 
> is a good idea. As if you add this, you can reveal BCCs, at least at 
> current version of SMTP protocol. And what about an alias resolving to 
> some thousand recipients ???

I think he means the address that the server is currently acting to deliver
to. In other words, a 'Filtering-On-Behalf-Of' header (obviously, it needs a
better name; 'Filtering-for-Delivery-to').

> On the other hand, what seems to me very important is to add the Message 
> ID of the message in order to someone be able to look for it at log 
> files generated by the filter.
> 
> Also, I'm not sure showing the reasons the message was classed as being 
> spam is important or even desirable. For the mail server admin, yes, but 
> not necessarily for end user. This may be an option, not a requirement.

On the contrary, what about the situation where the mail admin doesn't care
about the user, and is thus causing a nuisance to the user. If the user can
use local client filters to counteract the actions taken based on a
particular label or filtering criterion, then having this avilable is very
important.

Philip Miller