--On Monday, September 3, 2018 08:11 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
I fully agree that you don't want to advertise this globally.
Probably you already don't advertise PIPELINING globally for
the same reasons. You may still make it available
selectively.
Do you really trust people to get this right?
Based on experience with people getting almost anything wrong
that it is possible to get wrong and my concern about marginal
complexity, I certainly don't. I think that suggests that, if
this is going to go forward, a very careful explanation in the
text about what is necessary to get it right is a requirement.
Then we can at least worry about people who won't bother to read
that text rather than those who will guess at what is needed to
get it right and leave things out.
That, of course, gets back to the question of whether the
complexity this adds, including both the complexity of getting
it right and the complexity of dealing with folks who get it
wrong is worth it in terms of payoff.. Still trying to reserve
judgment.
Another thought along those lines: for the special cases, such
as submission and within a collection of closely-related
machines, out of band agreements might be a better option than a
formal SMTP extension, more or less along the lines of the
handwaving about similar situations in the MUA-> submission
server spec. In part because you are not requiring any sort of
client announcement, an agreement among a set of related systems
to go ahead and do this. That would have the advantage that, if
all of the systems legitimately using the technique among
themselves are under single operational management, there is a
management mechanism for deciding to not do it any more (even if
that is a rare case) and everyone can get the word as to when to
flush the caches to take advantage of new features. From the
standpoint of that approach, we also have a relatively
non-complex answer to the "what is someone gets it wrong and
uses this with a target server that can't/won't handle it"
question: either the antispam mechanisms kill the transaction,
the server sends out a lot of 5yz "command out of sequence"
responses, or you somehow luck out. None of those is a really
bad outcome other than wasting some server time and the client
operator(s) would get strong incentives to clean up their act.
I don't know if there are useful cases for this that do not fall
under the above umbrella.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp