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 ) _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
