Exec'ing a script from Cyrus when imapd has a client

[Greg A. Woods]

At Thu, 12 Nov 2009 11:55:25 -0800 (PST), David Lang <david.lang at digitalinsight.com> wrote:
Subject: Re: Exec'ing a script from Cyrus when imapd has a client
> 
> no, SMTP only works if you have network connectivity that is up most of the 
> time. it will handle short outages, but it will not handle the case where your 
> network connectivity is off most of the time

If your link is off most of the time then use UUCP -- that's what it was
designed for.  Tunnel it through SSL if you're using public IP
addressing and routing for the same link.

Or just use IMAP from a client MUA -- your link will be up when you want
to read mail and all your mail will be available at the IMAP server at
that time.

All these excuses for doing strange things with things like fetchmail
are really really lame and stretching the imagination beyond belief!


> > Use proper client/server protocols for dynamic IP clients!
> 
> SMTP is not a proper protocol for a dynamic IP environement.

Indeed, SMTP is not a client/server style protocol in the sense I meant.

IMAP would be a proper client/server style protocol in the sense I meant.


> not true, in the beginning UUCP was the primary mechanism for transporting 
> e-mail. it was designed for the (then current) environement where connectivity 
> was very intermittent and expensive to leave idle (which happens to match the 
> use case here as well, but using UUCP takes far more cooperation on the part of 
> the Internet server, thus the fetchmail approach)

I used UUCP intensively for at least 10 years at dozens of sites with
hundreds of peers, starting over 20 years ago.  I've worked on UUCP
implementations, including building alternate transport layers for UUCP
connectivity over networks such as X.25.

UUCP e-mail, _is_ fundamentally a store and forward protocol, _even_
when the client makes the call.  Don't confuse connection establishment
with higher protocol layers.

UUCP is _NOT_ an "Internet" protocol (though of course modern
implementations can use TCP/IP as an underlying connection transport).

Now read again what I wrote with all of that in mind:

    Well, in Internet e-mail delivery there has always been one and only
    one answer to the push vs. pull philosophy.  I'm only talking about
    e-mail here.

> UUCP that's acttivated when the client connects and tickles the server to let it 
> know that it's connected is effectivly a pull mechanism.

No.  The server _always_ _pushes_ the command and data files to the
client REGARDLESS of how the connection was initiated.  The UUCP client
doesn't know what to ask for -- it just opens the connection and allows
the server to proceed normally with using the connection.  The server
pushes over command and data files for the client to act upon, in just
exactly the same was as if it had initiated the connection.

Connection establishment in UUCP is no more related to the fundamental
fact that e-mail via UUCP is a store-and-forward protocol than PPP
connection establishment is related to the fact that SMTP is a
store-and-forward protocol.  They are both different layers.

Keep it Simple -- don't confuse or violate protocol layers!


> Thunderbird? my understanding (from watching people use it) is that it wants to 
> pull a copy of all your mail to the local box before processing it. how is this 
> a proper IMAP client?

How is it not a proper IMAP client?  Like I said, pick your poison.
Some MUAs will want to copy everything over at once for one kind of
performance profile, some will request only headers (enough to form the
summary index) for another kind of performance profile.  Thunderbird
fully understands the concept of multiple folders on arbitrary servers,
and it more or less speaks true IMAPv4, giving the user an interface to
do most everything that IMAPv4 will easily allow.  It has additional
features that make it possible to work offline.  That sounds like a
proper IMAP client to me.

-- 
						Greg A. Woods

+1 416 218-0098                VE3TCP          RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>      Secrets of the Weird <woods at weird.com>