44 lines
2.5 KiB
Plaintext
44 lines
2.5 KiB
Plaintext
MBOX-Line: From jkt at flaska.net Tue Jan 15 08:32:05 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
|
|
Date: Fri Jun 8 12:34:50 2018
|
|
Subject: [Imap-protocol] Re: Is there some way to detect servers which
|
|
=?iso-8859-1?Q?automatically_add_sent_messages_to_the_Sent_mailbox=3F?=
|
|
In-Reply-To: <CAKHUCzxeqZbhG58JmGqEaSKaF-Vpxs4A2Rh83Do_A8s3K+nJMA@mail.gmail.com>
|
|
References: <647C20F7-BB5D-47DD-BC89-3B0D903D2900@apple.com>
|
|
<7B9C4CD5-75ED-46F7-8AE4-C3415918E905@apple.com>
|
|
<83A6F18656334E6CA23106F9DB1C8EC1@gmail.com>
|
|
<E4D13318-11D2-41EF-979F-2840AF2AF9C9@apple.com>
|
|
<1358152426.27730.105.camel@innu>
|
|
<29D96F78-FC57-4AF5-8177-C71638D5DEB4@apple.com>
|
|
<CABa8R6seWwh3emtqPnYYCrh5v7BSOjh+H5gkkLmSj6KnK5rTbQ@mail.gmail.com>
|
|
<887FDCAF-16E0-4030-A4A3-1BA58554F038@apple.com>
|
|
<1358163144.24711.140661177295453.76384B37@webmail.messagingengine.com>
|
|
<CAKHUCzyCKR6gj1thzG2nXGMmWEv8=GALcMbTcy_TNPoOgqcKQw@mail.gmail.com>
|
|
<1358168208.10326.16.camel@innu>
|
|
<CAKHUCzzPttroO06o_ZAiKf4yLhpE=aN3Ae0+wk-XksB=zyL7cQ@mail.gmail.com>
|
|
<CABa8R6sJeV-RPPfahFN6WmPT5dUP00NOhNJrLMRmOntd8DRvGQ@mail.gmail.com>
|
|
<1358219317.28560.140661177648789.4B8BC9F9@webmail.messagingengine.com>
|
|
<bccbfca2-e293-421b-9fcc-1772ba45dfb1@flaska.net>
|
|
<CAKHUCzxeqZbhG58JmGqEaSKaF-Vpxs4A2Rh83Do_A8s3K+nJMA@mail.gmail.com>
|
|
Message-ID: <466e43ea-d3ce-46c2-8b72-b246fd4cca94@flaska.net>
|
|
|
|
On Tuesday, 15 January 2013 13:42:39 CEST, Dave Cridland wrote:
|
|
> I do not want to have one set of protocols for simple home clients and one
|
|
> set for enterprise, military and other more involved cases.
|
|
|
|
This makes sense -- which is why I made sure that the submission draft has the same supported features as the submission over ESMTP and that it includes provisions for future extensions. If the submission-over-IMAP gets adapted, I don't see why it shall be any second-grade citizen compared to the submission over ESMTP.
|
|
|
|
Yes, making sure that it stays up-to-date will require porting of the future ESMTP extensions -- but as someone who has done that for all of the existing ones, I don't envision that this will take much effort.
|
|
|
|
So, in short -- ESMTP has certain features which are important for its use case. What I claim is that only a subset of these are relevant for submission, and that this subset have been integrated into the proposal. I don't see a problem in continuing doing that in future.
|
|
|
|
Do you still see a problem in there?
|
|
|
|
With kind regards,
|
|
Jan
|
|
|
|
--
|
|
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
|
|
|