Re: [fetchmail]Selective deletion of email from remote server?

I'd like to second this request for a conditional keep. It's a feature I
always liked when still using Vpop3 on Windows.

The are many reasons that someone would want this and not 'workarounds' all
are possible outside the scope of fetchmail. I for instance keep my mail a
while on my ISP just so I can read it during the day with webmail when at a
customer's site.

As fetchmail keeps track of the UIDL's of the messages it has downloaded
before but are still on the server, any tool you write has to read that list
(it's in .fetchmailids). Also .fetchmailrc has to be parsed for account
information. So there is a tight link between fetchmail and the
functionality you're looking for. I wrote a perl thingy run by cron every
night that does just that (available on request), but is limited to POP3
servers. I found frequent malformed timestamps in the headers to be a
challenge. Of only the download date was recorded in .fetchmailids.

In short, it would be great to have a syntax like keep=n with n in eg.
hours/days instead of plain keep. Unlike some other requests it is imho true
to the nature of fetchmail.

If there are no takers I will consider writing a patch myself. But my C is
not what it used to be.

Jan Klaverstijn.

> Here is why:
>
> I have a number of email accounts in various places.  I also manage
> a server.  On this server, I want to retrieve the email from these
> various accounts, and redistribute it to local (to the server)
> accounts that I use for various purposes.  So far, so good:
> fetchmail works splendidly for this purpose.
>
> However, sometimes I don't have access to my server, only to the
> other, remote accounts.  In these somewhat infrequent cases, I want
> to be able to connect to these other accounts and read my recent
> email. Therefore, I use fetchmail's "keep" option, so that the email
> remains on these other servers.  In other words, I want the email to
> remain on the various remote accounts, NOT in some backup account on
> my own server.
>
> However, I don't want to keep the mail on these remote sources
> forever.  5-7 days of backlog is plenty.  That's why I want some
> sort of conditional "keep" functionality, which would allow me to
> program how much backlog I want on each of these servers.
>
> I know that I could write something in Java, Python, Perl, Ruby, and
> no doubt any number of other languages to periodically run on my
> server to attach via IMAP or POP3, as appropriate, to each of these
> remote mail sources and clean up the backlog.  I'm willing and able
> to do this.
>
> However, before starting a project like that, I was wondering if
> there was a way to get fetchmail to perform this task, since it
> already has the ability to do most of it.  I was also wondering if
> perhaps someone had already figured out a trick to get fetchmail to
> do this, or perhaps submitted some kind of unofficial patch for this
> purpose.
>
> Perhaps a new option, maybe called something like "keepfor" and
> which takes a duration parameter, might be added to fetchmail.  I'm
> willing to take on this task, if there is any interest in this
> functionality besides my own.
>
> But if not, I'm glad to go off and tackle this problem in a
> different way.  Just thought I'd check here first, to see if perhaps
> there was already some work done in this area, or some interest
> in this capability.
>
>
>
> > If you simply want a backup of the most recent 200 messages left on the
> > server, here is a procmail receipe that would do that.
> >
> >    ## ## Copy all incoming mail to the backup directory, just in case
> >    ## Note: you must already have a directory named safetynet, and
> >    ## the messages will be placed in individual files.
> >    :0 c
> >    safetynet
> >
> >    ## Prune the backup directory; keep only the first 200 notes
> >    ## to guard against mail loops overflowing the file system
> >    ## NOTE: this is a rolling log, so mails aren't kept for long
> >    :0 ic
> >    | cd safetynet && rm -f dummy `ls -t msg.* | sed -e 1,200d`
> >
> >
> > If you want something more complex and your email source is an IMAP
> > server, you could probably replace the delete message that fetchmail
> > sends to the source server.  Issue a move command instead, placing your
> > old incoming messages into a folder that you manage some other way.
> > This is a simple modification to fetchmail, and would fit into the code
> > and configuration files much more easily.
> >
> > To manage the folder with all the copies, I would look at the JavaMail
> > APIs, and write a small Java program that runs from cron.  It can run
> > anywhere, not just on your source email system.
> >
> > Alan
> >
> >
> >
> > _______________________________________________
> > Fetchmail-friends mailing list
> > Fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org
> > http://lists.ccil.org/mailman/listinfo/fetchmail-friends
>
> --__--__--
>
> Message: 2
> Date: Mon, 6 May 2002 10:57:35 +0530
> From: Sunil Shetye <shetye(_at_)bombay(_dot_)retortsoft(_dot_)com>
> To: fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org
> Subject: Re: [fetchmail]Bug in doing CAPA /w fetchmail-5.9.11?
>
> Quoting from Matthias Andree's mail on Sat, May 04, 2002 at 03:42:03PM
+0200:
> > I can imagine one, but that might break mail servers behind load
> > balancers: connect, send CAPA, store the replies, disconnect, reconnect,
> > proceed without CAPA with the stored CAPAbilities.
> This looks like a good solution. In fact, there is no need to quit if
> CAPA succeeds. Only if the response to CAPA is an -ERR should the
> POP server be reconnected.
>
> In fact, a similar thing has been done in the SMTP code, where if EHLO
> fails, the SMTP server is reconnected before sending HELO. Of course,
> the SMTP server is normally localhost, so reconnecting is not
> expensive.
>
> Sunil Shetye.
>
>
>
> --__--__--
>
> _______________________________________________
> Fetchmail-friends mailing list
> Fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org
> http://lists.ccil.org/mailman/listinfo/fetchmail-friends
>
>
> End of Fetchmail-friends Digest