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