Hello.

On Wed 2002-06-12 at 10:37:21 -0400, Mike Schiraldi wrote:
[...]
> I think what i'll do is filter probable spam as if it were just regular mail
> and write a script that i can call on each piece of spam. The script will
> count the number of bytes in the message (call it N) and then look through
> the archives for all messages whose filesize is N. (I use maildir) Then, for
> each of those matching messages, i'll strcmp it to the original message, and
> if there's a perfect match, delete the file.

As you mentioned maildir, "links" popped straight to my mind. I do not
know how maildir resp. the involved programs handle soft links
resp. hard links, but it might be worth a try.

Given that those are supported reasonably (and I do not overlook
something obvious), soft links would need a helper in procmail that
creates by-date-archive and incoming folders by linking messages to
the real one in the main archive. Additionally mutt would have to
follow and delete the real message file (maybe per macro, maybe by a
little patch, which follows the symlink). From time to time a script
should would have to delete all dangling soft links from the
by-date-archive (and how does mutt handle broken links wrt
maildirs). That's all, I think.

Worst case would be IMHO if mutt wouldn't move around the link, but
re-create a message file on changes. Best would probably be, if mutt
already had special symlink support and followed the link to always
modify the real file.


With hard links, also a script called by procmail would have to assure
that those are created instead of copies. On deletion mutt would have
to delete the other hard links, too, which probably required a script
to look for the inode id of the current mail and delete those with the
same in the archives.

Worst case would be, if mutt tries to be careful and always uses
temporary files which it then moves "over" the old message on changes,
because that would create a copy as soon as you change something.

Best case is when any change would be done in-place and therefore the
hard link would never be broken.


All that said, if mutt doesn't works well with links yet, it would be
probably easiest to implement the "follow symlinks" concept, because
changing handling of temp files could have some security / reliability
issues.

Hope I did not confuse all others or even myself. ;-) 

Bye,

        Benjamin.


-- 
[EMAIL PROTECTED]

Attachment: msg28936/pgp00000.pgp
Description: PGP signature

Reply via email to