When using fetchmail, how do I delete oversized messages from the server without actually fetching them? The man page of fetchmail doesn't help. I want fetchmail to issue "dele #n" command to the server for each oversized message.
If fetchmail is unable to do it, is there any other way?
Abhir Joshi wrote:
When using fetchmail, how do I delete oversized messages from the server without actually fetching them? The man page of
It's not possible with fetchmail AFAIK. :(
If fetchmail is unable to do it, is there any other way?
Yes, with my POP accounts I do it directly like this:
$ telnet <pop-server> 110
USER <username>
OK
PASS <password>
OK
DELE <message-number>
OK
QUIT
You can check the size of the messages with LIST, etc.
Hope that solves your prob for now.
Manish
Now that I know it can't be achieved using fetchmail, I was wandering, why this feature isn't yet incorporated into fetchmail? This feature really helps to get rid of those whopping mails with image attachments without wasting the dialup bandwidth.
On Thu, 16 Jan 2003, Abhir Joshi wrote:
why this feature isn't yet incorporated into fetchmail? This feature
You need to ask ESR about that. Send in a patch if you want... he might incorporate it into the next release.
On Thu, Jan 16, 2003 at 04:39:22AM +0530, Abhir Joshi wrote: | Now that I know it can't be achieved using fetchmail, I was wandering, | why this feature isn't yet incorporated into fetchmail? This feature | really helps to get rid of those whopping mails with image attachments | without wasting the dialup bandwidth.
You can always use the -l option with fetchmail (and flush the mails using -F later on).
On Mon, 13 Jan 2003, Abhir Joshi wrote:
When using fetchmail, how do I delete oversized messages from the server without actually fetching them? The man page of fetchmail doesn't help. I want fetchmail to issue "dele #n" command to the server for each oversized message.
If fetchmail is unable to do it, is there any other way?
I don't think fetchmail can do this but take a look at mailfilter. You can set it to automatially delete messages *on the server* based on a variety of criteria. Look for it on sourceforge.
Sharukh.
On Mon, Jan 13, 2003 at 07:31:14PM +0530, Abhir Joshi wrote:
When using fetchmail, how do I delete oversized messages from the server without actually fetching them? The man page of fetchmail doesn't help. I want fetchmail to issue "dele #n" command to the server for each oversized message.
If fetchmail is unable to do it, is there any other way?
Let me introduce you to JFetch. I started this project sometime back. Although, I haven't been doing much development on it; I still use it and it works great for me. It was made to fulfil exactly these kinds of requirements. Of course, it is Java based, so you will need a JVM; and believe me the flexibility is really worth the tradeoff in resources.
Check http://www.execve.net/jfetch
I'll be more than glad to help anyone with configuring it; who knows might make a release again ;).
Cheers, -g
On Tue, Jan 14, 2003 at 11:42:02PM +0530, Gautam Mani wrote:
Let me introduce you to JFetch. I started this project sometime back. Although, I haven't been doing much development on it; I still use it and it works great for me. It was made to fulfil exactly these kinds of requirements. Of course, it is Java based, so you will need a JVM; and believe me the flexibility is really worth the tradeoff in resources.
Check http://www.execve.net/jfetch
I'll be more than glad to help anyone with configuring it; who knows might make a release again ;).
Well, I haven't yet checked it but it would be really nice if you wrote it in C or C++.
Abhir Joshi wrote:
On Tue, Jan 14, 2003 at 11:42:02PM +0530, Gautam Mani wrote:
<snip>
Check http://www.execve.net/jfetch
I'll be more than glad to help anyone with configuring it; who knows might make a release again ;).
Well, I haven't yet checked it but it would be really nice if you wrote it in C or C++.
And why do you say that?
Manish
On Fri, Jan 17, 2003 at 07:55:57PM +0530, Manish Jethani wrote:
And why do you say that?
simply because you need to have a java interpreter for that. A standalone binary would be cleaner.
Abhir Joshi wrote:
simply because you need to have a java interpreter for that. A standalone binary would be cleaner.
Well, actually, having a Java interpreter would be a lot cleaner than writing all your s/w in C/C++. Programs like Gautam's are better written (and maintained!) in Java. That's why Java (or Perl, or some other high-level language) exists!
Though Java is not really an open-source thing, it's still pretty much open and widely used and accepted even in the open-source community. Lots and lots of business s/w has been written (and, recently, ported) to Java. At least one Free JRE would come bundled with most Linux distros.
Manish
On Sat, 18 Jan 2003 00:14:36 +0530 Manish Jethani wrote:
Well, actually, having a Java interpreter would be a lot cleaner than writing all your s/w in C/C++. Programs like Gautam's are better written (and maintained!) in Java. That's why Java (or Perl, or some other high-level language) exists!
"lot cleaner"... "better written"... these are all emprirical statements. Java the language exists to be able to program for Java the platform. AFA choosing the Java platform is concerned, I'd rather prefer going through some pain on my part than have thousands of users pay the performance price. Nor do I want to pay the performance price myself, so my PC doesn't have a JVM.
On Sat, Jan 18, 2003 at 12:14:36AM +0530, Manish Jethani wrote:
Well, actually, having a Java interpreter would be a lot cleaner than writing all your s/w in C/C++. Programs like Gautam's are better written (and maintained!) in Java. That's why Java (or Perl, or some other high-level language) exists!
Gautam's program is something with very basic functionality; it is like an enhanced fetchmail (I haven't tried JFetch yet. I downloaded it but I don't yet have JVM). Many more people would accept it if it could be converted into a standalone binary.
open-source community. Lots and lots of business s/w has been written (and, recently, ported) to Java. At least one Free JRE would come bundled with most Linux distros.
And what about those thousands of machines which had GNU/Linux or BSD or ... installed long before todays fancy Linux distros were available? JFetch is not a business s/w and its use is not limited to some organizations.
Also, as pointed out by Tahir, "lot cleaner" is something the programmer or maintainer is concerned with, who, anyway, is used to working with that complexity. For a user, it's cleaner if he can execute it with ./JFetch without any unnecessary virtual machine comming in between.
Since JFetch is an enhancement to fetchmail and not radically different from fetchmail, I feel that instead of writing a totally new software, a patch to fetchmail would be more helpful. ESR should be told about this (It's possible that Gautam has already had a correspondence with ESR). If he refuses to include this functionality for some reason, then a new software is worth. Having the functionality added to fetchmail would also mean that users would just have to upgrade their existing fetchmail and add the new options to the existing fetchmail configuration file.
Ultimately it is Gautam's choice. Is there any way to convert the java byte code to native code binary? If there is, then those binaries could be distributed, and people like me, who don't have JVM, could start using it right away.
On Sat, Jan 18, 2003 at 03:50:07PM +0530, Abhir Joshi wrote:
On Sat, Jan 18, 2003 at 12:14:36AM +0530, Manish Jethani wrote:
Well, actually, having a Java interpreter would be a lot cleaner than writing all your s/w in C/C++. Programs like Gautam's are better written (and maintained!) in Java. That's why Java (or Perl, or some other high-level language) exists!
Gautam's program is something with very basic functionality; it is like an enhanced fetchmail (I haven't tried JFetch yet. I downloaded it but I don't yet have JVM). Many more people would accept it if it could be converted into a standalone binary.
There was a specific reason that I chose to use Java in this case. JFetch allows you to easily plugin mail-filters which is really kewl. So all it takes is creating a filter complying to certain interfaces, and dropping it in the classpath. Configuration etc. all can be provided through one central config file. Java's dynamic class-loading mechanism helped me a lot here. As I said earlier, I would rather have this flexibility than worry about a running JVM.
JVM's have become faster and faster over the years and anyone following the Java world would know about technologies like Hotspot which are dramatic improvements in the JVM implementation.
Since JFetch is an enhancement to fetchmail and not radically different from fetchmail, I feel that instead of writing a totally new software, a patch to fetchmail would be more helpful. ESR should be told about this (It's possible that Gautam has already had a correspondence with ESR). If he refuses to include this functionality for some reason, then a new software is worth. Having the functionality added to fetchmail would also mean that users would just have to upgrade their existing fetchmail and add the new options to the existing fetchmail configuration file.
I use a dialup the amount of time I spend online needs to be a minimum. I used to be a fetchmail user, and I wanted specific functionality like:
- message-id filtering (duplicate message removal) - size based filtering - spam filtering
Anyone who knows the POP3 protocol know that these (and more) filters can be achieved without actually downloading the message. Just the headers are sufficient. Now, fetchmail could probably include the size feature... but thats just one of the many that I wanted. SPAM control was another of my requirements (sender based etc.) And you know about duplicate messages due to people cross-posting. Getting all this into fetchmail seemed unrealistic... though I never got in touch with ESR.
Ultimately it is Gautam's choice. Is there any way to convert the java byte code to native code binary? If there is, then those binaries could be distributed, and people like me, who don't have JVM, could start using it right away.
Bytecode->native converters exist today... but FAIK they are quite unstable.
BTW, can anyone shed some light on how plugins are/can be implemented in C/C++ (like GAIM etc.) Any pointers will be greatly appreciated.
-- Abhir Joshi http://education.vsnl.com/abhir/
Cheers, -g
On Sat, 18 Jan 2003 17:48:21 +0530 Gautam Mani wrote:
JFetch allows you to easily plugin mail-filters which is really kewl.
[snip]
through one central config file. Java's dynamic class-loading mechanism helped me a lot here.
You can do all of this in C and C++. "Dynamic class-loading" needs to be OS supported and you can have this done in C and C++. AFAIK, it can be done in any language as long as the compiler knows how to generate object code for such purposes. I don't know when or by whom this technique was first implemented but A little googlizing revealed a Sun Microsystems document dated 1992 regarding this. Most of the mainstream OSes support this now.
On Sat, Jan 18, 2003 at 06:50:51PM +0530, Tahir Hashmi wrote:
through one central config file. Java's dynamic class-loading mechanism helped me a lot here.
You can do all of this in C and C++. "Dynamic class-loading" needs to be OS supported and you can have this done in C and C++.
As you can see in my earlier post, I am interested in knowing about implementation of plugins in C/C++. If by "dynamic class-loading in C/C++" you are referring to the dlxxx calls, let me tell you that from whatever little I have read about them, they are really not usable. They don't guarantee type-safety, and require various workarounds (atleast if you want to work with classes). Feel free to correct me if I'm wrong here.
Java gives me a clean way to integrate these plugins also thereby providing type safety. I have also used its serialization capabilities for storage of message-ids etc.
I am of the opinion that each of these languages has its place, and the decision to use one over the other is totally upto the developer in question. For me, speed of development is very important. When I look back and think if I had tried implementing the same in C/C++, I am looking at all these issues (from the top of my head):
- IMAP / POP3 client implementations (I also have experimental NNTP) - SMTP client implementation (for delivery to an MTA) - Mail storage implementations (mailbox, maildir) - Class loading (with type-safety) - Configuration - Logging
Some of these issues are resolved by the Java language itself. Some are Java extensions. With the extensions following well defined specifications, the learning curve to use the extensions is also very little.
I see speed of development, class-loading abilities and the availability of extensions and libraries as the primary factors in using Java in this particular case.
-- Tahir Hashmi (VSE, NCST)
Cheers, -g
On Sat, 18 Jan 2003 20:55:26 +0530 Gautam Mani wrote:
As you can see in my earlier post, I am interested in knowing about implementation of plugins in C/C++. If by "dynamic class-loading in C/C++" you are referring to the dlxxx calls, let me tell you that from whatever little I have read about them, they are really not usable. They don't guarantee type-safety, and require various workarounds (atleast if you want to work with classes). Feel free to correct me if I'm wrong here.
You're half right here. Type-safety isn't guaranteed by the linking process itself, since linkers are neither supposed to know about data types, nor the language from which the object code was compiled. However, name mangling of symbols ensures that type safety is enforced for C++. This is the reason why the "extern C" artifact exists. (In fact, you can have extern foo declarations for linkage to object code from any language foo. Talk of interoperability ;-) ). The workaround you mentioned, is taken care of by the compiler without the programmer having to bother about it. In short, C++ linkage *is* type-safe.
providing type safety. I have also used its serialization capabilities for storage of message-ids etc.
If you mean Object Serialization, perhaps xparam.sourceforge.net may be the answer.
Abhir Joshi wrote:
it is like an enhanced fetchmail (I haven't tried JFetch yet.
I'm not sure whether it's tightly coupled with fetchmail.
I downloaded it but I don't yet have JVM). Many more people would accept it if it could be converted into a standalone binary.
Actually, to tell you frankly even I often find myself in this situation. Sometimes I don't have a JVM, sometimes I don't have perl. But over time I've found it worth the effort to get a CD and install a decent JVM. That immediately opens me to so many useful applications out there. That's also the very reason why I bought a PC, installed GNU/Linux, ... and now installing a JVM!
Also, as pointed out by Tahir, "lot cleaner" is something the programmer or maintainer is concerned with, who, anyway, is used to working with that complexity. For a user, it's
^^^^^^^^^^
I think you're forgetting the basic principle here - Keep It Simple, Stupid! UNIX itself is based on this funda.
cleaner if he can execute it with ./JFetch without any unnecessary virtual machine comming in between.
sh$ cat JFetch #!/bin/sh java -jar jfetch.jar
sh$ ./JFetch Initialising...
new software is worth. Having the functionality added to fetchmail would also mean that users would just have to upgrade their existing fetchmail and add the new options to the existing fetchmail configuration file.
So far, this the only good reason I've seen for having the thing written in C. Then again I'm not too sure. :)
those binaries could be distributed, and people like me, who don't have JVM, could start using it right away.
If there's no acceptable JVM available for your platform then I can consider starting off a project to write one. But in this case I guess you're simply being a bum by refusing to install one.
Manish
On Sat, Jan 18, 2003 at 08:00:05PM +0530, Manish Jethani wrote:
Actually, to tell you frankly even I often find myself in this situation. Sometimes I don't have a JVM, sometimes I don't have perl. But over time I've found it worth the effort to get a CD and install a decent JVM. That immediately opens me to so many useful applications out there. That's also the very reason why I bought a PC, installed GNU/Linux, ... and now installing a JVM!
Sounds so familiar ... lets try putting this in a different language:
Hacker: I developed my code on the Windows platform because everyone seems to be using it anyway.
Webdesigner: This sight is best viewed in IE version so-and-so because I developed it in IE version so-and-so because ... (you guessed it) everyone seems to be using it anyway.
User: I use Windows because there are so many more apps available on it, I don't mind paying for the licenses ... besides, (yes, right again) everyone else seems to be using it anyway!
Sameer.
Sameer D. Sahasrabuddhe wrote:
On Sat, Jan 18, 2003 at 08:00:05PM +0530, Manish Jethani wrote:
Actually, to tell you frankly even I often find myself in this situation. Sometimes I don't have a JVM, sometimes I don't have perl. But over time I've found it worth the effort to get a CD and install a decent JVM. That immediately opens me to so many useful applications out there. That's also the very reason why I bought a PC, installed GNU/Linux, ... and now installing a JVM!
Sounds so familiar ... lets try putting this in a different language:
Hacker: I developed my code on the Windows platform because everyone seems to be using it anyway.
The problem with developing only for Windows is that your code will run only on Microsoft's OSes. Users would need to install some version (or worse, a particular, newer version) of Windows. Other companies don't (can't?!) develop Windows. This locks the user into "Microsoft technologies".
And what's wrong with that?
1) RMS: This is against the Free software philosophy. 2) Apple, Sun, etc: This is creating (has created) a "monopoly". 3) People like me: Microsoft technologies are crappy anyway. :)
Is that the case with Java? Do users need to install Sun's JVM? Are other companies/groups allowed to develop their own JVMs? Are the specs open? Are there Java compilers other than Sun's available in the market?
You can't be comparing Windows with Java.
<side> Slashdot: Programming Languages Will Become OSes [http://developers.slashdot.org/article.pl?sid=03/01/17/1656249] </side>
Webdesigner: This sight is best viewed in IE version so-and-so because I developed it in IE version so-and-so because ... (you guessed it) everyone seems to be using it anyway.
Again, developing for "IE only" is akin to developing for a particular, non-standards-conforming JVM (how about Microsoft's JVM for an example?).
But, yes, developing for "the Web" as a platform is ok (good?) as long as your code is standards compliant (valid HTML, limited/no use of Javasript). If you don't want to install a Web browser on your system then I'm afraid I can't write a "thin-client" version of my front-end in C just so that you can run it "directly from the commandl line". It wouldn't be profitable enough for me, _amongst_other_things_.
(A lot of software developers are doing that BTW - desupporting old thin-clients and promoting Web-based front-ends.)
User: I use Windows because there are so many more apps available on it, I don't mind paying for the licenses ... besides, (yes, right again) everyone else seems to be using it anyway!
Well, if J. Random User doesn't mind paying for the license fees for Windows and _she_likes_using_it_ then I don't see *any* problem with it. You might not like this fact, but a lot of people actually love using Windows just like you and I love using GNU/Linux. Some others use it because they have major investments in it (my uncle is a lawyer, and he has hajaar documentation in Word format, and at the age of 45 he has no interest in learning how to use a new word processor just because Windows is not Free!).
We need to help more users migrate to Linux, and we need to make more users start liking Linux. The latter seems to be turning out to be difficult (correct me if I'm wrong, but that's the way I feel, honestly). Of course, I'm speaking of Linux in desktop context here.
Manish
On 20/01/03 00:05 +0530, Manish Jethani wrote:
<side> Slashdot: Programming Languages Will Become OSes [http://developers.slashdot.org/article.pl?sid=03/01/17/1656249] </side>
Those who do not understand unix are condemned to reinvent it, poorly. -- Henry Spencer
Devdas Bhagat
-
Abhir Joshi -
Chirag Kantharia -
Devdas Bhagat -
Dr. Sharukh K. R. Pavri. -
Gautam Mani -
Manish Jethani -
Philip S Tellis -
Sameer D. Sahasrabuddhe -
Tahir Hashmi