On Mon, Feb 20, 2012, at 01:27 PM, 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 ... ) > > 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.
I'm beginning to appreciate the "multiple envelopes" idea as well actually, particularly reading your thoughts. It probably means storing annotations - or at least providing a way to access this envelope data that smells remarkably like annotations. In which case I wouldn't be adverse to having the envelope in the protocol if it's stored with the message as well. The hard part then is bolting it on to existing server implementations, since we need to store it SOMEWHERE. At FastMail we add 'X-Delivered-To' and 'X-Mail-From' headers which capture at least that much of the envelope. That happens during the LMTP proxy stage, where spam scanning and cleanups are done. (Postfix on the MX passes ORCPT via LMTP, we patch that in.) The downside of out-of-band metadata is that everything needs to support it. Otherwise you can't even see it. If it's in-band in the message, you can transfer it via intermediate stages that don't understand it - so you can download it via a dumb client, then operate on the local copy. Of course, with this theoretical protocol, annotations would have to stay alongside. Potentially mutable annotations. Bron. -- Bron Gondwana [email protected] _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
