On 11.4.2013, at 3.59, John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:
--On Thursday, April 11, 2013 01:12 +0100 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:
The proper ESMTP style for this would be
(1) an EHLO keyword to say the server supports the feature
(2) a MAIL parameter for the client to enable the feature
Do you need more signalling than that?
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.
EHLO advertisement itself isn't enough, since this may be a user-specific
setting and I don't think clients re-EHLO after AUTH.
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
I think adding syntax
to the message body reply would be a bad idea, since that is
usually used to feed back trace info (queue ID). Perhaps you
could have a new command to be used (pipelined) after the body
to retrieve the IMAP status. Would that make the MAIL
parameter redundant?
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..
Yes. But it seems to me that the problem Timo is trying to
solve involves submission via Gmail and not being able to turn
off its saving a copy of the sent message. It seems to me that
problem doesn't involve the IMAP server at all except insofar as
the sending client chooses to send the SMTP message and then use
IMAP APPEND or equivalent to put a copy somewhere.
It seems to me that problem is easily solved using the
well-known maxim:
Patient: "Doctor, it hurts when I do xyz."
Doctor: Have you considered not doing xyz?"
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.
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. 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).
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp