Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

On Mon, Feb 20, 2012 at 09:31:03AM +1300, Adrien de Croy wrote:
> not everyone is on sendmail
> 
> we're talking about adding 2 parameters, a return path and forward
> path.    Hardly complex.
> 
> this allows us to
> - not have to parse the headers
> - not have to re-write the entire message when stripping bcc

Most MTAs seem to do header rewriting by appending or stripping
parts of the header on the fly.  They don't rewrite the entire
message, they print the headers down the wire, then blat the
body.  That's not expensive unless you're doing it wrong.

> these things are not cheap.  they will affect service capacity.

Seriously?  We do it to millions of emails in Postfix every day
on a single box and the CPU barely breaks a sweat.  What sort of
capacities are you considering serving on a single machine here?
Micro-optimising this... if you can save a single fsync somewhere
you'll get much better optimisation than avoiding a header removal.
Remember you're probably ADDING a header anyway to note the sending
time and user/ip of the sender at the time it happened.

> Why would you incur such penalty simply to avoid transmission of a
> couple of parameters?

Because I don't believe you when you make it out to be a big penalty.
You're not rewriting the header on disk, purely on what gets written
to the wire.

> It's trivially simple for an MUA to supply this information when it
> wants to send the message.

Trivially simple, yes - not so simple to track and repeat.

> There's no reason to assume this information would be lost either.
> It's up to the server how to record such things and make them
> visible.  Whether that's in the sent items folder or something
> associated with the message.

Significantly more complex than a simple keyword.  For a rare case.
Parsing "Resent-To" instead handily covers the entire use-case that
you have raised, with no loss of functionality, and without bloody
raising the edge cases to higher importance than the simple common
case which happens all the time.  Make the easy things EASY and the
hard things possible, not everything equally hard.

> Distinction between envelope and content is a key principle of SMTP.
> One could argue it's also a cause of certain issues, but I don't
> think it should be discarded without some fairly serious thought.

Happy to have serious thought about it, but in this case the initial
envelope should IMHO be part of the content, because you're sending
something out of your "\Sent" box, near enough, and what's there
should be a record of what you sent.

SMTP will still exist for the 0.1% cases.  Resent-To will handily
cover the normal "user operated client" use-case.  This is a method
for "submission by a user operated client", that's all.

Bron ( getting bogged down in side issues, whee )