On 4/25/2020 6:01 AM, Ned Freed wrote:
> Aside from implementation errors, I've seen no operational problems with DSNs,
> only with the DSN extension. The problem there is that some people have
> claimed that since NOTIFY=SUCCESS is a part of the base and they don't want to
> do it the only alternative is to disable the entire extension. I disagree; I
> think that since security concerns are paramount it's perfectly OK to simply
> reject NOTIFY=SUCCESS on security grounds.
Perhaps this goes to the challenge of a specification's distinguishing
its essential core, versus desired-but-not-required enhancements.
Completely inapplicable in this case, I'm afraid. One of the primary goals of
the NOTARY effort, if not the primary goal, was feature parity with X.400.
And the operational model for X.400 was success receipts as the default.
So the feature had to be part of the core.
But thinkgs change. X.400 collapsed - a casualty of even more serious
design errors than success DSNs. Spam became email's biggest problem,
which made NOTIFY=SUCCESS less desirable. Privacy concerns also arose that
weren't even on the radar at the time this work was done.
Fail to support all of the core and it's not valid to claim to support
the specification.
It's not a question of support, it's a question of operational policy. Every
implementation of the DSN extension I've seen has no problem supporting
NOTIFY=SUCCESS. THe debate has been over whether or not it's legitimate to have
an operational policy of bouncing messages that ask for it.
Of course there's also the issue of whether or not the extension, eith
or without NOTIFY=SUCESS, is of sufficient value to enable. Some people
see little value here, and the NOTIFY=SUCCESS situation is sufficiently
bothersome to tip the scale to dropping the extension.
The danger of a pick-and-choose free-for-all is that a claim to support
a specification provides little useful information.
Dave, we're talking about having an operational policy of restricing the use of
exactly one feature which made sense when the standard was defined but has
issues today. This is hardly a pick-and-choose free-for-all.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp