On 18/02/2012 8:36 p.m., Bron Gondwana wrote:
On Sat, Feb 18, 2012, at 08:13 PM, Adrien de Croy wrote:
AFAIR Bcc should never hit the wire. That's how it can be "blind"
carbon copy.
Otherwise you rely on a server to strip it.
I entirely disagree. I was thinking quite a bit about the "upload to
the IMAP server and then send it via SMTP while telling it who to
send to", and I actually don't like it.
with respect, others may like it and want to do it.
If you don't like it, you can design your server and client to behave
the way you like without making it impossible for others to do it in the
protocol.
others may prefer to submit the SMTP envelope information when they tell
the server to send a message, and it could be stored as some meta-data
on the message.
Sure, if there's a huge desire to do this then fall-back to SMTP may be
possible... but we're doing submission in IMAP so that client authors no
longer have to support that protocol right?
Certainly in the XSENT I implemented, once it has sent, it sets an
\XSent flag on the immutable message. Not an \XSent-to-one-address.
server is free to do whatever else it likes, like moving it to sent, or
making a copy or whatever.
The message with an \XSent flag is a record that it was sent to the
addresses listed in that header.
And the copy that went "over the wire" up to the IMAP server is your
record of what you did. That _should_ include the BCC, so you can go
back later and check who you sent it to. Obviously, the BCC should
be stripped as it gets handed over to the delivery agent.
I guess it's a grey area there - if you consider IMAP to be a remote
mail client that you're driving from a distance, then it's ok to store a
BCC header, just like you would if you were storing it in a local
store. But you're relying on the IMAP server to strip it when it
submits the mail for delivery, which is a bit of work for the IMAP server.
If you don't have to parse and re-build messages all the time, you'll
scale much better.
Bron.
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
