I have probably poorly expressed my question, but no: I'm not trying to implement a server logic. I'm implementing a client that connect to an IMAP server, fetches for new messages and (in the full version of the program) applies some rule to incoming messages.

That sounds like server-side filters (e.g. Sieve = RFC3028, exim filter) moved to the client.

Alexander

dear afoken,

> That sounds like server-side filters

I have both kind of replies on this:

No: my perl imap client reads via text2speech important mail sender and subject in my headset while I'm listening music to avoid the openspace chaos. So it is a filter yes, but eminently client side.

Yes: my perl imap client also mark as read some mail, move other ones to specific subfolder or mark them as important, so it is something should be done server side via message rules. But the actual server offers an OWA interface and rules are not always applied and I dont know why. Also: I use Thunderbird as mail client and it offers message filters too, but they have broken something recently and message filters are now very instable and new applied filters simply dont work.

But I dont think my question was about filtering. My question is about making a reconecction using Mail::IMAPClient and implementation apart I think is a valid question. The module offers methods to connect, check the status of the connection so I suppose should be great to be able to recover a lost connection. All professional mail clients are able to do this, I want it too.

L*

PS from the RFC you kindly linked:

   This document describes a language for filtering e-mail messages at
   time of final delivery.  It is designed to be implementable on eith
+er
   a mail client or mail server.
[download]

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

I dont think my question was about filtering.

No, but it made me think you were busy re-inventing the wheel on the "wrong" side (on the client).

my perl imap client reads via text2speech important mail sender and subject in my headset

Interesting idea. I'm not sure if I would freak out if my computer would suddenly start speaking while I'm deep "in the zone".

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Sorry, my bad. Instead of simply writing about "smtp server logic", I should have been more explicit.

As far as I understand it, the smtp protocol was designed with that sort of connection problems in mind. If mails cannot be delivered instantly they stay in the queue and are sent when the remote mail server is available again. At least to me that seems a convenient solution for the connection problem.

My idea was to install an additional smtp server locally and relay the mail to the remote smtp server, that finally ends up in the IMAP server your are trying to access to that local smtp server. If accessing that mail via IMAP is desired an additional IMAP server would be necessary.

Probably to much effort if there are only a handful of mailboxes, I see that. It must have been the term "connection problem" that triggered me ;-)