On Wed, Oct 28, 2015 at 4:36 PM, John C Klensin <john-ietf@xxxxxxx> wrote: > Folks, please tone down the rhetoric, read the specs, try to > understand the comments Dave Crocker and I made, and at least be > clear about the difference between your taste and what SMTP > requires and allows. There actually are reasons for most or all > of SMTP. If you think those specifications are incorrect, I > look forward to seeing the well-reasoned I-D, one that starts > from the Internet email environment as it actually exists > outside the giant providers (and as several people, notably > including John Levine) keep trying to explain). I don't think the problem here is a lack of understanding. Rather it is a difference of opinion as to what the approach should be. As a meta-point (since we are on the IETF list, that is most relevant), I think one of the things we lack is a protocol lifecycle model and the determination to apply it. Yes, I know we have 'HISTORIC' but when are we going to call it a day on BEEP let alone FTP? If we were managing our portfolio rationally, we would put FTP and BEEP in a bucket marked 'No further effort'. Getting FTP up to modern security standards would be a huge amount of work and it would be wasted effort as its feature set has been subsumed by SSH and HTTP long ago. The problem is that it is difficult to let go. SMTP email has had a 40 year run. Like the car I own of that vintage, it is perfectly capable of functioning (albeit with some assembly in the case of the car) but it isn't going to approach the speed, safety or reliability of a new model. There comes a time when getting 1970s technology to meet 2015 needs is a case of diminishing returns. And adapting to changing needs frequently means losing functionality. In short, expecting every feature of SMTP that could be used in 1980 to be supported today is unreasonable. While it is in theory possible to drive a 1977 MGB at 100mph one would be most ill advised to try.