#994 re-request: magnets on any header

[Alan Jay Weiner]

I requested this a long time ago (feature request
#665543, on 10 Jan 2003) and it was dismissed. Since
then I've wanted this ability over and over - and
searching the feature requests, it seems others request
it also - I found similar requests posted several times.
So I'm re-requesting it and ask for it to be
reconsidered. (and hopefully not redismissed... :)

I rarely filter based on just "From" or "To" headers.
Most of the maillists I'm on have something that's
truly unique in their headers - rarely is it in the
From or To headers. As an example, I filter on the
following:

X-Palm-Dev-Forum: palm-dev-forum

List-Owner: <mailto:owner-ntfsd@lists.osr.com>

Reply-To: <ntsysadmin@lyris.sunbelt-software.com>

List-ID: <mysql.mysql.com>

Reply-To: Palm_OS_5@yahoogroups.com

Sender: vnc-announce-admin@realvnc.com

I would NEVER create a magnet for these addresses - far
too often the list name isn't in either the To or From
headers. Some maillists have something in the subject
line, but most of the lists I'm on do not.

But if I can make a magnet for any arbitrary header, I
can 99.99% guarantee that it will be filtered correctly
by my mailreader.

The best part is that POPFile can put in the
X-Text-Classification header, so my mailreader can
filter based on that - which will make things much
easier if I change mailreaders and need to migrate
filters...

It's important to permit arbitrary headers rather than
just expanding the To/From/Cc/Subject list; otherwise I
wouldn't be able to filter on X-Palm-Dev-Forum (for
example).

In my original request, John asked if this couldn't
simply be done by training POPFile for the maillists -
let it figure out the magic headers.

I suppose it could, but that would require a *lot* of
verification that messages were sorted properly - some
of the maillists I don''t even read regularly (they're
for searching when I have questions) - so that training
time would increase my workload tremendously.
And I'd never be sure that something didn't end up
filed wrong.

One argument against these magnets is that spam to the
maillist will get through - that's a trade-off I easily
accept. (most of the maillists I'm on rarely get spam
anyway)

- Al -

[osamut]

Logged In: YES
user_id=1406930

I wanted this ability, too.

Actually, I found magnet types can be increased
*manually* as followings but I have no idea how
to implement this in UI.

1. Modify "sub magnet_page" in $POPFILE_ROOT/UI/HTML.pm
so that magnet types not defined in the language files
are displayed *as is*.

original:
$type_data{Magnet_Type_Localized} =
$self->{language__}{$magnet_types{$mtype}};

modified:
$type_data{Magnet_Type_Localized} =
$self->{language__}{$magnet_types{$mtype}} or
$magnet_types{$mtype};

2. Manually append magnet types, ummm

$> cd $POPFILE_USER
$> sqlite popfile.db
sqlite> select * from magnet_types;
1|from|From
2|to|To
3|subject|Subject
4|cc|Cc
sqlite> insert into magnet_types values
(5,"x-ml-name","X-ML-Name");
sqlite> select * from magnet_types;
1|from|From
2|to|To
3|subject|Subject
4|cc|Cc
5|x-ml-name|X-ML-Name
sqlite> .exit

3. Restart POPFile

[Ricardo P. Alves]

Logged In: YES
user_id=1468500

Alan, all,

I agree with you: having a HEADER magnet would save A LOT
of training. I currently use another spam-filtering tool
in our server (Spamassassin) that sets a flag in the
message (before it reaches popfile) as follows:
X-Spam-Status: No / Yes

If I'm able to use this (spam-status = YES) as a Magnet, I
could benefit from both programs at the same time (by
using this "positive + negative" >> "positive spam".

Kind regards,
Ricardo.