On Wed, 23 Jun 2004, Chris Drake wrote:
TF> So if the recipient does a CBV anyway, what's the advantage over
TF> properly specifying plain CBV?
per-message authentication
You can do that with a standard for signed return paths and plain CBV.
sender+recipient pair authentication,
Doesn't work in the presence of aliasing (forwarding).
dictionary attack prevention
Doesn't require your proposal. Requires co-operation from the attacker.
OMTA CBV "opt out" mechanism,
Especially useful for attackers.
improved reliability with existing (non-CBV-aware) MTAs
Properly specifying plain CBV will acheive this.
CBV loop avoidance
Plain CBV does this anyway.
alternative verification service features,
Possibly useful.
TF> The protocol you described performs the CBV between DATA and its response,
TF> which is after the oMTA has found out about the recipients.
The OMTA only knows if the recipients are valid after sending the data
and waiting for the response from the RMTA (which, in my scenario,
does the CBV inbetween).
In order for CBV to work you have to be truthful in your response to RCPT.
Any CBV specification must cope with systems that are not.
Are you proposing that messages should be rejected in their entirety
because of one mistyped recipient address? What about mailing lists?
e.g. one subscriber's account at a site is cancelled and all the other
subscribers at the site lose their subscriptions.
--
Tony Finch <dot(_at_)dotat(_dot_)at> http://dotat.at/