--On Thursday, April 11, 2013 12:07 +0300 Timo Sirainen
<tss(_at_)iki(_dot_)fi> wrote:
On 11.4.2013, at 3.59, John C Klensin <john+smtp(_at_)jck(_dot_)com>
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. 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?
Any attempt to actually negotiate the server behavior during the
mail transaction would presumably have worse performance
implications than a per-user configuration setting.
EHLO advertisement itself isn't enough, since this may be a
user-specific setting and I don't think clients re-EHLO after
AUTH.
Continuing with my reasoning above, if it is a user-specific
setting, then the server configuration option I suggested is
already in place and the user presumably knows it is. If the
configuration option doesn't exist, then there are no
user-specific settings.
Something that could work is something like:
C: EHLO ..
S: 250-LOCALCOPY
S: ..
C: AUTH ..
S: ..
C: MAIL FROM <..> (LOCALCOPY)
S: 250-LOCALCOPY
S: 250 2.1.0 Ok
Where the above server notifies that the user will get a local
copy, while:
..
C: MAIL FROM <..> (LOCALCOPY)
S: 250 2.1.0 Ok
Here the server doesn't store a local copy. Except if the
local copy saving fails (e.g. user over quota), should the
server now also fail the DATA? So maybe instead:
C: MAIL FROM <..> (LOCALCOPY)
S: 250 2.1.0 Ok
..
C: DATA
C: ..
S: 250-LOCALCOPY
S: 250 2.0.0 Ok: queued as 6AA4E3C6224
That would also allow more complexity like:
250-LOCALCOPY 2.0.0 Ok
250-LOCALCOPY 5.2.2 You are over quota
250-LOCALCOPY 2.0.1 IMAP 12345678 123 Saved mail with IMAP
UIDVALIDITY 12345678 and UID 123 to your \Sent mailbox
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.
...
I guess the 250-LOCALCOPY replies could also be a result for a
new command. Although that could be more difficult for clients
to implement using standard SMTP libraries. But then again the
MAIL FROM parameter might not be possible either..
Probably possible. But whether server and client implementers
would judge it to be worth the trouble is another matter.
Again, if, as you suggest, Google (for example) couldn't be
motivated to implement a rather simple configuration option, why
should one believe that they would implement something as
complex as what you are suggesting.
...
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.
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.
Option 2: Fix the relevant client to support a
per-submission-server flag that determines whether or
not to append copies of outgoing messages to some
selected folder.
Annoying to require users to configure a setting that could be
so easily determined automatically.
But it can't be "determined automatically" unless you are
certain that you know what the user would want in all of the
many situations that might apply, especially if the IMAP server
and mailstore were physically supported by different machines
and network configurations than the SMTP one.
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.
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 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).
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp