Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: Handling reconnection with Mail::IMAPClient

by rizzo (Curate)
on Jan 25, 2023 at 13:48 UTC ( [id://11149870]=note: print w/replies, xml ) Need Help??


in reply to Handling reconnection with Mail::IMAPClient

Hi Discipulus

I'm using Mail::IMAPClient to write my own mail monitor and currently trying handling connection problems ...

To me this sounds as if you were trying to implement smtp server logic using an Imap client. Why not simply install a smtp server(opensmtpd, qmail, postfix) locally and then access it using Imap?

  • Comment on Re: Handling reconnection with Mail::IMAPClient

Replies are listed 'Best First'.
Re^2: Handling reconnection with Mail::IMAPClient
by Discipulus (Canon) on Jan 26, 2023 at 07:40 UTC
    Hello rizzo and thanks for reading,

    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. It is a similar behaviour to any email client programs like Thunderbird for example.

    When I speak about connection problems I mean client connection problems, infact I naively simulated such problem disconnecting the ethernet cable of my pc where my perl imap client is running.

    The above code shows my problem: the client provided by Mail::IMAPClient seems unbale to restablish the connection after reaching the IsDisconnected state. I'd like to recover the connection to the server instead of barely exiting the perl imap client program.

    L*

    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 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

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
        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.

        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.

      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 ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11149870]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (None)
    As of 2024-04-25 01:07 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      No recent polls found