wasm-demo/demo/ermis-f/imap-protocol/cur/1600095041.22688.mbox:2,S

193 lines
6.8 KiB
Plaintext

MBOX-Line: From brong at fastmail.fm Mon Jan 14 03:32:24 2013
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun 8 12:34:50 2018
Subject: [Imap-protocol] Is there some way to detect servers which
automatically add sent messages to the Sent mailbox?
In-Reply-To: <887FDCAF-16E0-4030-A4A3-1BA58554F038@apple.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>
Message-ID: <1358163144.24711.140661177295453.76384B37@webmail.messagingengine.com>
I have ranted about this at length about the state of this. I don't
think BURL is going to be a solution which gains wide adoption, though
I'd love to see a convincing argument from anyone who's rolled it out
to anything other than a corporate-style network where the clients,
servers and intermediate networks are all controlled by a single
organisation.
Fastmail has a configuration option which allows you to automatically
BCC all your outbound email to one or more other addresses, and one way
expose this is forwarding to an automatically created sieve rule which
files the copy directly into one of your own folders. We also don't
expose the existence of this anywhere.
I still think the sane option is to upload the message contents once
via IMAP and then have a command which is sent over the IMAP channel
saying to inject said message into an outbound email queue - meaning
that there's only a single connection channel required. The
interesting bits are, of course, spam controls. But so long as it goes
through similar controls to port 587 I think it's sane.
Anyway - we don't turn it on automatically, so users are likely to only
turn it on once they know what their client does.
Bron.
On Mon, Jan 14, 2013, at 09:15 PM, Ian Anderson wrote:
It does make the whole sending process take twice as long. The only
think I can think of protocol wise is an extended SMTP status code from
the DATA command or an IMAP capability, neither of which are super
wonderful. =\
Ian
On Jan 14, 2013, at 2:12 AM, Brandon Long <[1]blong@google.com> wrote:
Gmail definitely does this, though as long as your message is well
formed when sending via msa (date and messageid headers set), the
appended copy should just be considered a DUP, so no two copies.
Unnecessary bandwidth, I guess.
Nothing we do to indicate this protocol wise, but I'm open to
suggestions.
Brandon
On Jan 14, 2013 12:38 AM, "Ian Anderson" <[2]iana@apple.com> wrote:
I haven?t tested it, but I hear that FastMail, Tuffmail, Gmail, 126,
and 163 all do this. (Some of those may have since stopped, my
data?s a bit old.)
Ian
On Jan 14, 2013, at 12:33 AM, Timo Sirainen <[3]tss@iki.fi> wrote:
> I doubt you could get such DATA response a) standardized and
especially
> b) implemented by server admins. Or are you thinking about some
specific
> large email provider that does this? I'm not aware of any provider
that
> does this.
>
> I think BURL is going to become much more available at least in
server
> side within a few years.
>
> On Mon, 2013-01-14 at 00:05 -0800, Ian Anderson wrote:
>> Oh yeah, I didn?t think about BURL. Bleargh. Searching for the
>> message in the Sent mailbox after sending seems rather error
prone.
>> What if it takes ten minutes for the message to show up
>> automatically? Maybe an extended SMTP status code from the DATA
>> command would make sense on servers that are going to do the
append
>> for you though?
>>
>>
>> Ian
>>
>> On Jan 13, 2013, at 5:34 PM, Ho? V. Dinh
<[4]dinh.viet.hoa@gmail.com>
>> wrote:
>>
>>> Maybe you could detect the IMAP server you're dealing with and
>>> behaves accordingly to its behaviour.
>>> An other solution could be to FETCH in the Sent mailbox after
the
>>> mail has been sent.
>>> And match the message based on the Message-ID, then, decide
whether
>>> you really need to APPEND the message.
>>>
>>>
>>> --
>>> Ho? V. Dinh
>>
>>
>> On Jan 13, 2013, at 4:52 PM, Dave Cridland <[5]dave@cridland.net>
wrote:
>>
>>> No, there isn't, as far as I know. You can, on some systems,
tell
>>> which is the Sent mailbox, and you could watch it for a new
message,
>>> I suppose. I bet systems supporting special use mailboxes don't
do
>>> the automatic append, though.
>>>
>>> On other systems, the "correct" method for sending a message is
to
>>> first append it, and then submit by BURL.
>>>
>>> Finally, Alexey had a postaddress extension which allowed you to
do
>>> the append by using a special address during submission.
>>>
>>> Dave.
>>>
>>
>>> On Sunday, January 13, 2013 at 4:43 PM, Ian Anderson wrote:
>>>> I suppose this might be more likely as an SMTP response code
>>>> (though I can?t find a defined one) than an IMAP capability or
>>>> some such, but maybe someone on this list knows anyway?
>>>> <wishful_thinking>
>>>>
>>>>
>>>> Ian
>>>>
>>>>
>>>> On Jan 13, 2013, at 4:31 PM, Ian Anderson <[6]iana@apple.com>
wrote:
>>>>
>>>>
>>>>> I?ve noticed that in some systems when you send a message via
>>>>> SMTP, it will put a copy in the user?s Sent mailbox. Most of
>>>>> them don?t however, necessitating that I do an IMAP APPEND to
>>>>> get the message in Sent. Is there a good/any way to tell when
>>>>> the APPEND is necessary? Right now I?m doing it all the time
>>>>> which is resulting in double copies in the Sent mailbox for
>>>>> systems that do it automatically.
>>>>>
>>>>>
>>>>> Ian
_______________________________________________
Imap-protocol mailing list
[7]Imap-protocol@u.washington.edu
[8]http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
_______________________________________________
Imap-protocol mailing list
[9]Imap-protocol@u.washington.edu
[10]http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
Email had 1 attachment:
* smime.p7s
6k (application/pkcs7-signature)
References
1. mailto:blong@google.com
2. mailto:iana@apple.com
3. mailto:tss@iki.fi
4. mailto:dinh.viet.hoa@gmail.com
5. mailto:dave@cridland.net
6. mailto:iana@apple.com
7. mailto:Imap-protocol@u.washington.edu
8. http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
9. mailto:Imap-protocol@u.washington.edu
10. http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
--
Bron Gondwana
brong@fastmail.fm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130114/218b7230/attachment.html>