Is there an easier way to do IMAP?
Robert J Baker
> I have an E-mail account at fastmail.fm which can be imported into
> Pegasus using IMAP. Unfortunately, it is quite a process. First, I
> have to "mount" the IMAP server by going to Tools/IMAP Profiles. Then
> I have to go to Mail Folders and open the IMAP folder to read
> messages.
>
> Isn't there a way of automating this process? I know I can get
> Pegasus to mount the IMAP profile every time it starts up. But there
> is rarely any mail there, so it seems like wasted time and bandwidth.
> However, is there any way of getting Pegasus to automatically transfer
> any mail to my New Mail folder without going to the trouble of going
> to the Mail Folders and finding it? Can I add an icon to automate the
> whole process including dismounting IMAP when it is finished?
I too have a fastmail.fm account (have had it for a year), and as FM
doesn't support POP retrieval except for high-end accounts, using
PMail with it is quite a problem (and would be for me anyway, as I've
been converted to an IMAP guru; see below)...
It's fine for backing-up the entire account (which I recently did),
and for editing damaged messages and uploading the repaired versions
(ditto, with four messages which lacked date headers -- if interested
in the details, search the FM forum,
<http://www.emailaddresses.com/forum/forumdisplay.php?&forumid=17>,
for user "robert@fm"; try doing *that* with POP!), but I can see no
way of (automatically) *synchronising* my account (that is,
downloading only the new messages). As I take full advantage of all
that IMAP has to offer, and hence have several server-side folders,
manual synchronisation is even more of a pain for me than it would be
for someone who leaves everything in Inbox (to use the official IMAP
name for New Mail).
To my mind (and I doubt that I'm the only one), an IMAP client which
can't auto-synchronise is not truly an IMAP client (see
<http://www.emailaddresses.com/forum/showthread.php?&threadid=12006>),
so I hope that PMail gets this facility before very long; I don't want
to have to switch to <spit> Outlook Execrable... :(
(Due to the spam problem, the From and Reply-To addresses are valid
but unread. My e-mail address is robert_bak#fastmail.fm (demunge it
first); my EmailDiscussions.com ID (as already mentioned) is
robert@fm; or just reply to this thread.)
Cal Skeptic
Nomad
Baker) wrote:
Huh? Of course a non-synchronising client is a _true_ IMAP client --
IMAP is about (centralised) serverside storage of mail -- there is
nothing in the standard (rfc2060) that demands syncronisation, infact,
it's only really mentioned as being a side benefit of persistant
message UID's.
As for trying to avoid OE though, I can only agree with you ;-)
For those who only use IMAP though, and there are a few I'm sure, it
would be nice if PMail could open in IMAP only mode -- bypassing any
attempt at local storage. This would allow a user to have his actual
newmail folder be the remote IMAP folder.
However, currently, any action that could be taken on IMAP folders
would initially need the account to be activated first. You should be
able to do this by having the IMAP account connect at startup. Once
that's done, you could try leaving the folder window for the IMAP
newmail folder open, but minimised, and attache a folder-open filter
set to if that would copy/move mail to your local newmail folder.
I don't know whether the above would work with IMAP, I might test it
later when I've more time to tinker, but I've used similar tricks with
local folders and attached rule-sets for things such as an
auto-cleaning deleted mail folder (a trick I got from this list a
while back).
What'll happen when the new IMAP code eventually appears though, I
can't tell you, but maybe your problems will be over??
HTH
--
Nomad
Wondering of the vast emptyness of the 'net
in search of something cool.
Robert J Baker
> Huh? Of course a non-synchronising client is a _true_ IMAP client --
> IMAP is about (centralised) serverside storage of mail -- there is
> nothing in the standard (rfc2060) that demands syncronisation, infact,
> it's only really mentioned as being a side benefit of persistant
> message UID's.
That's the theory, but in practice it's impractical to run an IMAP
account on that basis -- remember, there's no such thing as
"unlimited" bandwidth, no matter how many (lying) ISPs claim to offer
this.
Also, there are several people (such as myself) who only have
cybercafé access, and thus *need* to synchronise local folders with
server-side ones. Thirdly, good practice prescribed backing-up long
before IMAP existed...
So, any good IMAP client needs to offer synchronisation, and it's
since occurred to me that there needs to be some options:--
* Whether synching is unidirectional (only downloading of messages
which don't exist locally) or bidirectional (also uploading of
messages which don't exist on the server).
* Whether synching should only be done on messages which have arrived
since a certain date/time (I'd like this to automatically default to
"since the last time synching was done")
* Whether certain folders are to be excluded (for example, there's
probably no point in synching the server's Trash folder or PMail's
Deleted Items folder).
Nomad
Baker) wrote:
>Nomad <nomad***@***absamail.co.za> wrote in message news:<jsig7voglo8n32rpp...@4ax.com>...
>> Huh? Of course a non-synchronising client is a _true_ IMAP client --
>> IMAP is about (centralised) serverside storage of mail -- there is
>> nothing in the standard (rfc2060) that demands syncronisation, infact,
>> it's only really mentioned as being a side benefit of persistant
>> message UID's.
>
>That's the theory, but in practice it's impractical to run an IMAP
>account on that basis -- remember, there's no such thing as
>"unlimited" bandwidth, no matter how many (lying) ISPs claim to offer
>this.
It's perfectly practicle -- that is, after all, what it was designed
for.
>Also, there are several people (such as myself) who only have
>cybercafé access, and thus *need* to synchronise local folders with
>server-side ones. Thirdly, good practice prescribed backing-up long
>before IMAP existed...
OK, with cybercafé access all bets are off ;-) However, with the
transient nature of cybercafé access, I would have thought that local
storage is the last thing that you'd want, rather than a requirement!
Do you chuck everything of floppy, and if so, with that volume of
data, what's the problem?
As for backup, that's what makes IMAP _as_it_stands_ so good --
centralised storage (should) == centralised backup. Although my
previous reply didn't even consider an ISP scenario, you do _pay_ them
to provide a service, and backup should be part of that (unless
specifically stated otherwise, in which case, you chose a bad ISP).
>So, any good IMAP client needs to offer synchronisation, and it's
>since occurred to me that there needs to be some options:--
It doesn't _need_ it, you _want_ it -- as my Mother always told me,
there _is_ a difference ;-)
>* Whether synching is unidirectional (only downloading of messages
>which don't exist locally) or bidirectional (also uploading of
>messages which don't exist on the server).
This is looking for a real mess of trouble -- it couldn't _reliably_
manage that automatically -- you'd always need user input for conflict
resolution.
>* Whether synching should only be done on messages which have arrived
>since a certain date/time (I'd like this to automatically default to
>"since the last time synching was done")
Which time -- sent or recieved?
>* Whether certain folders are to be excluded (for example, there's
>probably no point in synching the server's Trash folder or PMail's
>Deleted Items folder).
You'd be amazed how some people abuse systems sometimes -- trash is
often used as a "second level storage" system. Don't ask me why,
people are odd like that sometimes ;-)
You've got some interesting idea's there, but none are likely to make
it into the IMAP standard, as they're not really what it's about. As
for clients, the developers should follow the standard, anything extra
is their own business, but there is nothing to stop them adding stuff
if they want to.
As for your above options, you can do some of it already using
filters. Not as automatically as you'd obviously like, but it's
possible:
1) Uni-/bi- directional synching. You can filter either way, but
there is no conflict resolution, so you'd just end up with dupes.
2) Use a "Message age" or "Message date" filter for date/time
dependant filtering, but the default would have to be a specified
period -- without other mechanisms, it be difficult to work out when
you last synched. However, it'd be easy to edit the filter if you
needed it to change.
3) This is the easy one, just ignore folders you can't be bothered
with. ;-)
Like I said, it's not going to be as automated as you're obviously
after, but it's an idea of what you can do already.
As for your issue of bandwidth as an argument in your favour, that
doesn't fly -- the amount of network traffic that you'd need for
anything approaching a decent synch mechanism would render the idea of
saving bandwidth a non-starter.
I'm afraid that it seems you're looking for more in IMAP than there
actually is. Sorry to let you down, but I tried to do it gently.
Laters
Gary P
> IMAP is about (centralised) serverside storage of mail -- there is
> nothing in the standard (rfc2060) that demands syncronisation, infact,
> it's only really mentioned as being a side benefit of persistant
> message UID's.
I have to say take exception to your "huh"... One of the biggest benefits
of IMAP is _disconnected access_. You can sync your IMAP mailbox onto your
laptop, disconnect, edit, delete and move to your heart's content, and
re-sync, applying all those changes to the server.
In fact, a 1996 article on imap.org states:
>>>
One of the important capabilities of IMAP4 is support for "disconnected"
operation, wherein an email client may download a cache copy of selected
messages, manipulate them while disconnected from the email server, and
subsequently resynchronize its cached state with the message store on the
server.
<<<
[http://www.imap.org/papers/docs/disc-status.html]
BTW, RFC2060 is obsolete, RFC3501 (IMAP4rev1) is the latest. One of the
additions according to the imap.org summary of the RFC: "IMAP4rev1 also
provides the capability for an offline client to resynchronize with the
server."
http://www.imap.org/papers/docs/rfc3501.html
-g