On 21/02/2012 2:27 a.m., Dave Cridland wrote:
On Mon Feb 20 12:43:25 2012, Filip Navara wrote:
JYFI, we (eM Client, www.emclient.com) do use BURL in some cases.
As does the Qt Messaging Framework.
(And Polymer, and Isode's M-Switch/M-Box, and ... )
OK, I'm not familiar with any of these clients. Most of our customers
are running windows on the desktop.
Anyone know of any windows-based clients that use BURL?
That all said, I'm swinging around to the notion of sending mail
through the message store access protocol:
If we have a command which sends a particular mail *with an envelope*,
then I think we can map all ESMTP stuff to it - but rather more
interestingly, we can keep the envelope around as metadata within the
store.
This allows things which you simply cannot do with BURL, for instance:
1) We could track bounces using VERP, and annotate the message when a
DSN is received, so you could see which sent messages have failed.
2) We could track MDNs in a similar way.
You'd want multiple envelopes on a message, to handle resends and
redirects, and it seems sensible to capture the S/LMTP envelope on
delivery, too, such that a client would have sufficient information to
cause a (delayed) bounce.
I appreciate this appears to be a U-turn on my behalf - that's because
it is. I don't see multiple protocols as being a show-stopper, but the
comments about DSN/MDN processing sparked this chain of thought for me.
People nowadays are used to instant feedback. So a 4 hour-later
delivery warning is not well received. Some systems you only find out 2
days later that your mail couldn't be delivered. You might have missed
the deal at that stage.
There's no technical reason why a system can't be designed and built
that would provide pretty much immediate feedback to a mail submitter as
to the outcome of the delivery. And I'd like to even check parameters
before that as well. It won't work in all cases, since there are still
many clients that are not connected full-time to the network. But it
can work in enough cases to provide real benefits.
There are of course all manner of commercial roadblocks to that, such as
what protocols are deployed. But there are ways to migrate to new
protocols if there are enough compelling reasons to do so.
Dave.
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
