[Top] [All Lists]

Re: [ietf-smtp] Submission DATA reply to indicate auto-save

2013-04-11 04:07:26
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: ..
C: AUTH ..
S: ..
S: 250 2.1.0 Ok

Where the above server notifies that the user will get a local copy, while:

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:

S: 250 2.1.0 Ok
C: ..
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 

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