Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

On Fri, Feb 17, 2012, at 12:40 AM, Adrien de Croy wrote:
> On 17/02/2012 12:22 a.m., Dave Cridland wrote:
> > Right, sure, understood (after s/MTA/MUA/) but what has port 25 got to 
> > do with it?
> 
> back to my point about getting everything over 1 port.  If we had that, 
> then blocking 25 wouldn't have affected me.

If you were using port 587, it wouldn't have affected you - that's been
standardised for a while.

The more important thing is - if we were going over one port, it would
have either not affected you, or TOTALLY affected you - with nothing
working.  Either of those is significantly more understandable to the
"punter" than some things working, and others not.

The same with "Send succeeds, but then append-to-Sent-folder fails" if
your IMAP connection is unavailable but your SMTP server isn't.  Or if
you're over quota.

BURL at least solves the second one, but it solves it in a half arsed
way that the little XSEND I put together last week doesn't.

With XSEND, you upload the message to IMAP first, then you say:

TAG XSEND UID

Which sends the message UNLESS it has the \XSent flag already.

And it sets the \XSent flag as soon as the message is sent.  No
waiting on network IO.  So the only gap is a failure within the
server itself.  If the client disconnects and tries again, the
flag will already be set, and it will not duplicate the message.

No partial failures.  No multiple systems depending on each other
to be up, configured correctly, routing to each other.

(Implementation in this case is "Call sendmail -bmi and pipe the
spool file to it")

> > What we need to do is identify the core problems to be solved, instead 
> > of finding solutions and trying to figure out how to use them.
> 
> * SPAM

There's a checklist for why this one won't be solved.

> * UDNs

In the case of wingate, because of the embedded SMTP server, you could
theoretically hold the client waiting until you had tried one outbound
SMTP.  Only fixes the first hop of course.

A "ocean boiling" solution to this would involve server level magic on
control messages.  You'd want forgery protection though... gets trickier
when you consider active attacks.  Mind you, MDN is already fraught with
active attacks.

Bron.
-- 
  Bron Gondwana
  [e-mail]