On 11 Apr 2013, at 20:10, Timo Sirainen <tss(_at_)iki(_dot_)fi> wrote:
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
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
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 have limited Internet connectivity, so might have missed a part of the
discussion. My apologies if this was already discussed.)
If you want to return extra information on DATA, I suggest you put it after the
Enhanced Status Code (if any), as many response parsers are expecting Enhanced
Status Codes to come first. E.g.:
250 2.0.0 [localcopy] Message accepted
250 [localcopy] Message foo is on its way.
ietf-smtp mailing list