Re: [Imap-protocol] Is there some way to detect servers which automatically add sent messages to the Sent mailbox?

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][email protected]> 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][email protected]> 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][email protected]> 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][email protected]>
  >> 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][email protected]>
  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][email protected]>
  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][email protected]
  [8]http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol

_______________________________________________
Imap-protocol mailing list
[9][email protected]
[10]http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol

Email had 1 attachment:
  * smime.p7s
      6k (application/pkcs7-signature)

References

1. mailto:[email protected]
2. mailto:[email protected]
3. mailto:[email protected]
4. mailto:[email protected]
5. mailto:[email protected]
6. mailto:[email protected]
7. mailto:[email protected]
8. http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
9. mailto:[email protected]
  10. http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
-- 
  Bron Gondwana
  [email protected]

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol