Re: [Imap-protocol] Is there some way to detect servers which automatically add sent messages to the Sent mailbox?

On Tue, Jan 15, 2013, at 08:15 AM, Brandon Long wrote:
> On Mon, Jan 14, 2013 at 5:24 AM, Dave Cridland <[email protected]> wrote:
> > My gut feeling is that if Brandon and Bron implemented BURL, you'd see
> > clients falling over themselves to implement.
> 
> I realize its just my young naivete, but the complexity of BURL/URLAUTH
> instead of what seems to me the much simpler concept of mail submission via
> IMAP just boggles my mind. (if someone has a link to a thread or page that
> opines on why, I'd be happy to try to understand, but last year's thread
> seemed to come down to "we might not future-proof it against a new
> must-have SMTP extension and we would never re-visit the IMAP extension to
> also support that")

That was pretty much what I got out of it.  Along with a huge amount of concern
for the complex cases of corporate networks with controlled IT requirements and
weird mail routing.

I'm much more concerned for the 99% of users who don't need anything complex,
don't send through multiple servers or have multiple mail stores, and need to
have the simplest possible system with the least number of things which can go
wrong.  Everything which can go wrong is something which increases the support
load, the documentation (which nobody reads but you have to have anyway) and
the operations workload.

> We don't currently have plans to support BURL.  There'd have to be a pretty
> compelling reason, and given that we auto-BCC all msa messages anyways, it
> already solves the two copy problem... admittedly, only for clients which
> know to configure that way or users that manually configure based on our
> support articles.  Also, the user's shouldn't get two copies if our
> duplicate detection is working, so it only makes sending slower in that
> case.

It would be nice to avoid that case of course!

GMail is big and different enough that a lot of clients already implement
special cases for you.  FastMail, not so much.  It's good though, because
things get some real-world testing through you that the standardisation
process really doesn't provide on the same scale.

Certainly with the converstaions stuff we're doing, for all that it would
be good to write it up as a standard (and we're working on that), it's also
really nice to be the only implementation, so we can fix things that we got
wrong.  That's a major reason we're holding off, because we want the ability
to test different ways more quickly.

> Frankly, we'd be more likely to support the submission via IMAP draft that
> was circulated last year.

The only thing I think I would like to see added is the ability to set a flag
on successful submit, and not submit again if that flag is already set.

This allows for nice idempotent usage - two concurrent connections both asking
for a submit works locklessly, because one performs the submit and the other
sees the flag and skips it - and retry on failure can just repeat the command
with no risk of sending the same message twice unless there was a lower level
transient failure - and that case is already the same with SMTP when the send
succeeds but the success response is lost.

How about we just do that?  I'm on leave this week, but I'm back at work next
week and I'd love to put together a test implementation.  I've already got a
Cyrus branch which does a lot of what is needed (just forking and execing a
specified binary which implements the sendmail command line, then writing an
iovec with buffer containing some extra headers and the mmaped spool file).

It's pretty un-tested though, and it's against about a 6 month old git master,
so it might need some work to port to our current HEAD.

Bron.
-- 
  Bron Gondwana
  [email protected]

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol