Re: header inventory

On Mon, Mar 15, 2004 at 04:15:16PM +0100, 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 was overloading the "required information."  I'd like to see some
minimal information included by a filtering mark.  Some of the required
information would be to identify the software, and some other information
would be required to idenfity the filtering point (where in the delivery
chain the message passed through the message).  So yeah, I'd say that
software identifying information would include name and version, and
location information would include hostname/ip/other where "other"
is needed to further refine the filtering point.


> 
> >   - 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 ???

OK, strike "address" and just focus on "other key."  All I meant is
that server/ip is not sufficient.  I might have a filter for "mem"
that forwards to "mark" on the same system, and "mark" also filters
the message using the same software.  So the "filtering point" has to
be more than just hostname/ip in order to be unique.  If you use the
delivery address you have the advantage of being able to backtrack
from a delivered message (i.e., after it leaves "mark" and arrives at
some other place) to (again, just a random example) find and debug a
filter that did the wrong thing.  As you say, though, that may not
always be desirable for privacy reasons.



> 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.

Only in circumstances where you expect the message-id to change.


> 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.

Right, I didn't include that as the required part.  Just an example
of what things a filter might want to make note.  I would say,
though, that for a structured header such as this, some keywords
would have specific registered meaning.  Other non-structured headers
could be added as well, and hopefully tied in some way to this
well-known structured header.

mm