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

[Adrien de Croy <[e-mail]>]

On 17/02/2012 1:11 a.m., Bron Gondwana wrote:
> 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.

that's what I've noticed in support.

> 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.

aieeee BURL...

until then, a mail server vendor had no need to write an IMAP client.

Would have been a trillion times simpler to implement submission from 
IMAP.  I can't even think of a mail server product with IMAP that 
doesn't have SMTP already.

Did anyone actually implement this?

It seems so fraught with problems / fragile that I'd expect very few 
implementations.  That's even apart from the complexity.

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

how do you provide the SMTP forward path?  Is that scraped from the headers?

maybe should be

TAG XSEND UID (addr, addr...)

> 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.

sure, but if you're delivering direct to end MTA, you have pretty much 
the whole path.

>
> 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.

half the problem is lack of standardisation.  MDNs should be 
machine-readable.

Adrien

>
> Bron.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com