Hi Kyle, Thank you for the advice :))) I am using fetchmail + POP3. I will try your suggestion it regaring mutt e-mail download.
fetchmail skips mail download based on ~/.fetchids file. Just for a sake of "fun" I will try to "make" that Perl utility, meanwhile will use mutt POP3 implementation. I guess your idea regarding POP3 TOP will work. Btw, can mutt run mail download offline? And also, can mutt, let's say on "D", parse message befor deleting it, and drop that "id line" in some other file? meaning what would me macro example? Thank you, Paul -----Original Message----- From: owner-mutt-us...@mutt.org [mailto:owner-mutt-us...@mutt.org] On Behalf Of Kyle Wheeler Sent: Thursday, August 13, 2009 11:05 AM To: mutt-users@mutt.org Subject: Re: What is the best way to approach "Deleted" mail removal from -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thursday, August 13 at 10:38 AM, quoth Paul Grinberg: > So, let's say my fetchmail keeps all the mail on the mail server > after mail download is complete. Without being rude, let me stop you right there. Fetchmail with the "leave it on the server" option is PROBABLY a bad setup for you. It was originally intended for POP3 servers, as a workaround for the fact that POP3 is phenomenally bad at handling multiple clients. It's a hack, intended for specific and usually temporary situations (where a certain amount of hackery is tolerable), not as a long-term solution. If you have no choice but to use POP3, I highly recommend you use mutt to access your POP3 server directly. With the message and header caching, it can be just as fast as a fetchmail-based option, and it handles things like deleted messages much better. If you're using fetchmail and "leave it on the server" with IMAP... you'd probably be better served by using the tool "offlineimap", which handles this sort of thing extremely well. > But sometimes you have spam, and other stuff that you usually delete > (D). Emails stay on the mail server, and they hold space. Indeed, as you instructed your software to do. > How to properly delete mail if you know mail id??? Well, assuming you're using a fetchmail/POP3 setup, there's no real solution that meets the "properly" category without either ditching fetchmail or ditching the "leave it on the server" option. But assuming you'll ignore my advice above, here's more hackery you could do. First, you'd need a script that will identify messages on a POP3 server based on a Message-ID or something similar. The problem, of course, is that POP3 has no means of "searching" messages other than by doing it the old fashioned way (download each one). Where IMAP gives each message a unique, long-term UID number, POP3 does not (it has UIDs, but they only last as long as the POP3 connection). So, you would need to write a perl script (or use some other language) that, given an input full-text message, would download every message on your POP3 server until it found a message that matched the one you had. You have to do a full-text matching (rather than just a header-based or message-id-based matching) because POP3 has no concept of "headers" (though you may be able to do some optimizing of this, using the POP3 TOP command, downloading just enough of each message to uniquely identify it). Once you have such a script (let's call it "pop3-delete.pl"), you can hook it into mutt by creating a special "delete" macro that you would use whenever you want to delete a message from the server as well as from your local copy. It would look something like this: macro index D '<pipe-message>~/.pop3-delete.pl<enter><delete-message>' > Ideally I want mutt to add those "ids" to some dummy file, which I > then pipe to some kind removal utility. Or you could do that, though it seems even more roundabout than what I was describing. I'm not aware of any pre-existing tools to do what you're describing, though. Good luck! ~Kyle - -- History will be kind to me, for I intend to write it. -- Winston Churchill -----BEGIN PGP SIGNATURE----- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKhCuwAAoJECuveozR/AWe10QP/1KDM7LNKJByHbF8poFgtjxu mN67t5TPD9i67Ni3G4CJwU7ZfyCPXmMHaIt5KedRqZp56rkOo++q69PBSg1wNLS3 rfBdqm4O0oLAkjjAkeGg3zKkj+ee/kmsjhaCdr8Wjl6uyduuWiq03wGivMqXcP5n Gvsy5yJ9N5v2sfr+wZqCf3zkdIZBWjUKqvSBcsQ8r9BkUPjVts5XcCnbiehEwXMK wHhsCpRLK5lidhWssEDWuyBCS+JaxTa2PM/4SWfnXkCBcc/N5oYeWm3W3CXoycuM FOKrFtrJL8IGERSvtJRiY1CkdQyfh4/jhmxRlBD4lmZZKza5bzezpzf/jIrcJYW5 fA8vvWB9cvoljH7luBm8GJq6C6UhDg+gCLYcpkaVOwm6Q/GcNT4J2uKSVqdQOhwx TKeQk6i+MkdHCyRc4DXKTP/A4A4R8l+XlMoQ10sVsM1len9gG0GziWlL2S84OYBF yLtmHeq85KvC9K+OpQd0zDWzK2Ji1Duqbu8PIUewqppX6lBdoBroONqkQsQGZIgJ BAGB5Hl6C2DUTdWdvWEwmIU9Dr41pupzLY3GmaflcJT4gduHS5T95JkYQ8ZdUyOq GC/2bopwxZxPksRtKYdz5gYsziB22owp9MhLQ9FZkD8MoKh7N+bIOettlsc02B3S Q9kT8RxhFwGemm4g4Nxr =sAfx -----END PGP SIGNATURE-----
