Hello Dan, Tuesday, July 6, 2010, 9:35:30 PM, you wrote: > Perhaps this one? > http://tools.ietf.org/html/draft-ietf-lemonade-submit-01 Thank you! Do you know any imap server that supports it, so we would be able to test our client against this server? -- -- Best regards, Maxim mailto:max <at> ritlabs.com
Hi, Le mardi 06 juillet 2010 à 21:39 +0300, Maxim Masiutin a écrit : > Hello Dan, > > Tuesday, July 6, 2010, 9:35:30 PM, you wrote: > > > Perhaps this one? > > > http://tools.ietf.org/html/draft-ietf-lemonade-submit-01 > > Thank you! Do you know any imap server that supports it, so we would > be able to test our client against this server? I just had a look at this draft as we have a mail server (including imap) in which we'd be interested to implement this kind of feature, however this draft only list possible ways of achieving message submission over imap and does not define which one should be used, nor how. I personally like the part <4.1.4. "IMAP Push" Using Proxy Model> with a mix of <4.1.3. "IMAP Push" Using APPEND> when it comes to composing the mail. When the client instructs the IMAP server to submit the message, the imap server connects to the local smtp to send the message (or directly appends to the mail queue if possible) and returns success to the SUBMIT (or whatever it gets called) command only once the message was appended to the local queue. As it's the local queue this process should never(Continue reading)
Hello!
Our server and the client support the following extension. The above
text is "google" translation from Russian into English because we
wrote this internal memo in Russian. Should we edit it to make proper
English, add the required formal information and submit it as draft?
At least a pair of software support it.
IMAP SEND
Extension SEND is supported by the servers, which return «SEND» in the
list of capabilities. Extension SEND introduces two new commands: SEND
and UID SEND. Also introduces a new response SEND. SEND command is
allowed only in the Selected State.
SEND Command
Arguments: message set
Data: untagged responses: SEND
Result: OK - send completed
NO - send failure (e.g. permission denied)
BAD - command unknown or arguments invalid
SEND command sends message with the specified message sequence
numbers. The addresses of the sender and recipient are taken from the
message headers. This command returns untagged response SEND for each
of these messages.
(Continue reading)
On Wed, 7 Jul 2010, M. Karpelès wrote: ... > I just had a look at this draft as we have a mail server (including > imap) in which we'd be interested to implement this kind of feature, > however this draft only list possible ways of achieving message > submission over imap and does not define which one should be used, nor > how. I believe that draft was input to the discussion that then occurred on the lemonade mailing list and in face-to-face meetings, where it was eventually concluded that doing submission directly inside IMAP is the Wrong Thing for a number of reasons. From that came the 'trio', RFCs 4467-4469, which avoided those issues. If you have concerns about this then you should review the lemonade mailing list archive *before* reopening the discussion or starting a new proposal, or else you'll be arguing from a position of ignorance. There were strong proponents on both sides of the discussion when this was being considered and yet the consensus, as I recall, was strongly for the models supported by the RFCs that were published. Philip Guenther
On 07/06/2010 10:38 PM, Philip Guenther wrote: > I believe that draft was input to the discussion that then occurred on the > lemonade mailing list and in face-to-face meetings, where it was > eventually concluded that doing submission directly inside IMAP is the > Wrong Thing for a number of reasons. From that came the 'trio', RFCs > 4467-4469, which avoided those issues. The trio also avoided being implemented, though, so I wonder if the decision was the right one... Arnt
On 6.7.2010, at 22.26, Arnt Gulbrandsen wrote: > On 07/06/2010 10:38 PM, Philip Guenther wrote: >> I believe that draft was input to the discussion that then occurred on the >> lemonade mailing list and in face-to-face meetings, where it was >> eventually concluded that doing submission directly inside IMAP is the >> Wrong Thing for a number of reasons. From that came the 'trio', RFCs >> 4467-4469, which avoided those issues. > > The trio also avoided being implemented, though, so I wonder if the decision was the right one... Apple has implemented it to Dovecot and Postfix (although the patch has not been integrated to either one, yet). Presumably also to iPhone at some point (I've no knowledge). So maybe they're not dead yet.
On Tue, Jul 6, 2010 at 3:08 PM, Timo Sirainen <tss <at> iki.fi> wrote: > > Apple has implemented it to Dovecot and Postfix (although the patch has not been integrated to either one, yet). Presumably also to iPhone at some point (I've no knowledge). So maybe they're not dead yet. No, it hasn't been implemented on the iOS devices. D
On Tue, Jul 6, 2010 at 3:08 PM, Timo Sirainen <tss <at> iki.fi> wrote: > > Apple has implemented it to Dovecot and Postfix (although the patch has not been integrated to either one, yet). Presumably also to iPhone at some point (I've no knowledge). So maybe they're not dead yet. No, it hasn't been implemented on the iOS devices. D
We have a complete implementation of the trio, along with an example
client for the iPhone that uses it. They work just fine.
Tony Hansen
tony <at> att.com
On 7/6/2010 5:26 PM, Arnt Gulbrandsen wrote:
>
> On 07/06/2010 10:38 PM, Philip Guenther wrote:
>> I believe that draft was input to the discussion that then occurred
>> on the
>> lemonade mailing list and in face-to-face meetings, where it was
>> eventually concluded that doing submission directly inside IMAP is the
>> Wrong Thing for a number of reasons. From that came the 'trio', RFCs
>> 4467-4469, which avoided those issues.
>
> The trio also avoided being implemented, though, so I wonder if the
> decision was the right one...
>
> Arnt
>
On 07/07/2010 01:06 AM, Tony Hansen wrote: > > We have a complete implementation of the trio, along with an example > client for the iPhone that uses it. They work just fine. Yes, they work, but they're not getting implemented, for whatever reason. IMO a send draft should be allowed to go forward, if its authors make a case that it'll be implemented when the trio wasn't. Arnt
RSS Feed
