Dirk [email protected] wrote:
(apparently not to list, which was a bit confusing for me.)
DP> classify (smaller 20000) :n
At first, I was going to remark that this message list would be
addressing the union set of small or new messages, and that
the proper way to select the intersection would be
((smaller 20000) (new))
However, a short test showed that the original formulation appears
to work, too. At the moment, I am utterly confused how msg lists
are supposed to work. More on that perhaps another time.
DP> If I junk (:j) a message, and classify it again, it will not be detected as
DP> junk as it should be.
If I'm not mistaken, the junk-classifier is not updated before the
next "nail" run. At least, a short test supported that.
Steffen added:
SDN> i strongly believe that [junk classification] should be done on the
SDN> server side, using administrated, up-to-date white/grey/blacklisting,
SDN> and up-to-date databases like SpamAssassin, that get updated by a large
SDN> community of people; especially with IMAP, where it's easy to get just
SDN> a header listing of some JUNK folder.
I understand what you mean, but I for one was happy that nail has
its own classifier, back when I still got much spam at home. (2009,
something like 90 out of 100 mails daily). These days, I don't
even bother to "hook" the classify command, I just run it manually
when I get unusually many spam mails.
Neither at home nor at work I am using IMAP but simply access the
local inbox. I have to maintain various SpamAssassin setups at
work and it's a PITA. I'm glad I can avoid it at home.
Summary: different strokes for different folks.
SDN> direct part/attachment addressing
That would be much appreciated.
SDN> But now that i think about it i see that it would be nice to have
SDN> an integrated automatic classification hook or so, that could be
SDN> triggered when messages are accessed (have to think here), and
SDN> that would pipe the *raw* message through an external processor
SDN> *before* we look at it, i.e., so that a local
SDN> script/SpamAssassin/xy could modify it on the fly. [...]
SDN>
SDN> But maybe Martin Neitzel has found a clever way how to do that
SDN> already today :)
Nah, in fact I don't see how an automaton could decide when to use
a "raw" (in nail's sense, e.g. still base64-encoded) or "unraw"
message format. I have experienced problem settings where "raw"
was too raw while "unraw" was already too much pre-processed. This
is an inheritantly tricky problem, and I cringe whenever someone
adds another encoding feature in the context of email.
Happy Easter Holidays,
Martin
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
nail-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nail-devel
