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

[David Lang]

On Thu, 12 Nov 2009, Greg A. Woods wrote:

> At Sun, 8 Nov 2009 06:54:30 +1100, Bron Gondwana <brong at fastmail.fm> wrote:
> Subject: Re: Exec'ing a script from Cyrus when imapd has a client
>>
>> On Sat, Nov 07, 2009 at 11:08:31AM -0500, Greg A. Woods wrote:
>>>
>>> Just get a forwarding alias installed on the remote mail server and then
>>> you'll be using the MTA to move your mail in a robust, secure, and
>>> fail-safe manner to the IMAP server where you desire it to be finally
>>> delivered.
>>
>> Maybe unreliable network connectivity?
>
> That's _exactly_ where you want to use SMTP or some other store and
> forward mechanism to create a robust and reliable mail transport link!
>
> Use SMTP to breech the unreliable link!  It's safe, proven, and designed
> for that very task!

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

>>  A dynamic IP where they don't
>> want a stale DynDNS pointer to cause someone else to get the mail?
>
> Well, amateurs can and will run whatever hacks they want, and they're
> not usually interested in doing the kinds of things necessary for
> production systems in the first place either.
>
> Further, if anyone is stupid enough to try to use dynamic IP addresses
> where static IP addresses are REQUIRED for proper functionality and
> robust operations then they get every problem they deserve and I have no
> interest whatsoever in catering to any of their hacks and abominations.
>
> Use proper client/server protocols for dynamic IP clients!

SMTP is not a proper protocol for a dynamic IP environement.

>> Pull vs Push in the abstract is an age old question that never has only
>> one answer, much as you are trying to paint it that way.
>
> 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.

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)

> Fight the way e-mail has always worked and you have to fight the whole
> infrastructure and use fringe tools with known risks and problems.
>
> If you want your e-mail to work reliably then you have to work with the
> existing infrastructure and with the tried and tested tools that
> designed and implemented to work that way.
>
> Note how even in SMTP the proposed mechanisms for pull-like
> functionality have been lost, broken, and forgotten forever, and even
> there, like in UUCP, it's still fundamentally store-and-FORWARD even if
> the client makes the call.  Nobody has _ever_ made "pull" work for
> e-mail in any significant widely accepted and implemented way.

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.

>>> The rest of this is kinda just BS about how to use a proper IMAP client.
>>
>> Er, you know a perfect IMAP client?  I've never been able to find a good
>> one, which is why I use offlineimap to local Maildirs and mutt to talk
>> to them.
>
> I didn't say "perfect" -- I said "proper".   :-)
>
> Mutt is not a proper IMAP client so far as I can tell, for example.
>
> Pine, Emacs Wanderlust, Thunderbird, Apple Mail, etc. are all "proper"
> IMAP clients in most respects, I think.  Pick your poison.  :-)

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?

David Lang