On Thu, 2013-04-11 at 11:07 -0400, John C Klensin wrote:
Gmail is unlikely to implement that, since that would require
changing their current default behavior and breaking users'
configuration. So it's not going to get wide adoption.
I wasn't suggesting changing the current default behavior at
all. Instead, I was suggesting that they could add a new and
thoroughly optional flag to the profile that would default to
the current behavior but that would, if set by the user, disable
the copying of the outgoing message. Current users and users
favored the copies wouldn't need to do a thing.
I think you've missed my point. I think that what you are
looking for is a configuration option on either the client or
the server, not a protocol matter.
I tend to agree that this functionality should be configured server side
using some external means (e.g. web UI) instead of doing it in the SMTP
protocol. Otherwise it adds more complexity than necessary. All I really
want is for an SMTP client to know whether the local copying happened or
not.
Trying to make a protocol
change to avoid configuration options -- especially when that
protocol change has to affect both SMTP and IMAP in the general
case-- is unwise architecturally and philosophically. More
important from your point of view, if you don't believe Google
would implement a configuration flag that could disable the
message-copy behavior, why is it reasonable to believe that they
would implement a protocol change?
Even if Gmail implemented a configuration flag to disable the behavior,
it wouldn't solve what I'm trying to solve. I like that behavior. I want
to make it more popular, not less popular. To do that would require
making it easy for clients to support it.
If the total amount of code to change in both server and client side is
just a few lines, and the gain would be to avoid re-uploading the mail,
I think it would quickly get popular. (As opposed to BURL, which
requires a ton of new code and a whole new way of doing the submission.)
See above. The more complex this gets and the more message-time
handshaking is required, the less likely it is to be
implemented. Worse, a given Gmail (or other) mailbox may be
accessed over webmail, IMAP, POP, and maybe by other means,
using different clients with different capabilities. Some of
the above might require that the client send the
I-only-use-IMAP-and-wont-change-my-mind-in-the-future option and
that the server believe it.
Sure, I agree. A single flag in some reply would be ideal solution for
everyone I think, unless it breaks something I didn't realize could
cause breakage.
My IMAP-specific ideas were just thoughts of some optional add-ons,
which wouldn't have to be supported by anyone. I can just as easily live
without them. (Their main purpose would be to allow IMAP clients to add
the message immediately to their local cache, similar to IMAP's UIDPLUS
extension.)
Option 1: Persuade the Gmail folks to allow a profile
flag that would _not_ save everything to the /Sent
folder but would allow explicit copies to it.
But that feature is actually useful, if only the clients
realized it was happening. That's why I'm considering adding
such option myself optionally.
So the user of that client program either
-- doesn't know and presumably doesn't care about the
extra copies
-- does know and still doesn't care
-- knows and wants to avoid the duplicates by
suppressing the automatic server copy
-- knows and wants to avoid the duplicates by not making
a copy in the client via IMAP APPEND
If the user doesn't know, then anything one might do with the
options you suggest would be based on the assumption that you
know better than the user does what the user would like if he
were better informed. That is a dangerous assumption and
behavior even when you get it right. If the user does know,
then the third case is best dealt with by a configuration option
to the server account and the fourth one by a configuration
option to the client program. And those options may be
per-server --if I had two servers, operated by two different
parties, that had the option of automatically keeping copies of
outbound messages, I might want to set that option to "no" on
one of them but leave it as "yes" on the other, especially if I
had bad experiences of the reliability of the associated IMAP
server in doing the APPEND.
I would definitely make this feature optional on server side, defaulting
to disabled. Each site's admin might want to enable this specifically
for their own users. But the admins wouldn't want to explain to every
user how exactly to configure their 10 different IMAP clients to avoid
the duplicate upload.
Remember that, for an IMAP user, APPEND offers the choice of
determining what folder the outgoing message going into. That
determination could be made manually or based on the outgoing
address(es), etc. Google's "save automatically" cannot
reasonably support that unless you take your command sequence a
step further and send "and when you store it, put it in folder
XYZ" (or, in Gmail's case, "attach label XYZ"). If you build
an automatic "if the server is saving automatically, don't save
locally" capability, you deprive at least some users of that
folder-selection capability.
I don't think there are many users who want to save the message anywhere
else than the default Sent mailbox (which is configured by IMAP
SPECIAL-USE extension). Those few who want something different are most
likely able to also disable this feature (or more likely haven't enabled
it in the first place).
Most of the users aren't
going to configure that, so the feature would be of no use for
them. I'm hoping to build something that would get wide
adoption on server side (Gmail, Dovecot) and hopefully on
client side ("needs about 10 lines of more code to client" -
that's why I would have liked a simple flag on DATA reply,
clients already do everything necessary to simply parse that
reply and set an internal flag to skip IMAP APPEND).
Interesting. In my experience, many clients have no idea at all
what to do with information that comes back in the DATA reply.
They still do parse the line to see if it's returning 250 or an error.
And most likely they could simply add around that part of the code
something like:
if (strstr(data_reply, "[localcopy]") != NULL)
state->imap_append_skip = true;
That was my original plan, but that's a rather IMAP-like way to deal
with it.
Worse, their strongly interpreting that information violates the
5321 prohibition on using more information than is present in
the reply code. You could override that behavior with an
extension, but that adds even more complexity and contradicts
"already do everything necessary...".
I don't think it violates anything, because the client doesn't have to
understand it. Or otherwise enhanced status codes would violate it as
well. Maybe it could be just an enhanced status code (category)?
250 2.8.1 Ok: queued as 6AA4E3C6224, as well as saved locally
But here I don't know if some clients panic because they no longer see
"250 2.0.0" reply.
I don't know that what you are suggesting is a bad idea. It is
just something I'd think about in a different way and that I
think you'd have a lot of trouble getting implemented and
deployed in precisely the mail implementations that you care
most about (other than your own, of course).
The server side implementation is tricky to implement well, but I think
that's mostly out of scope for the potential RFC. I think this extension
would be worth it just for Gmail itself, since they have implemented it
anyway. I was actually a bit surprised that they already didn't indicate
this using some X-extension.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp