--On Tuesday, 13 November, 2007 10:03 -0800 Dave Crocker
How is that any different than sending a 5xx in response to
RCPT TO:, which is something we can (and should) do now?
I'm feeling kinda dumb for having missed the ultimate flaw in
The goal of the proposal is to permit deferred filtering
analysis, or at least reputation analysis.
As someone else noted, most of this work requires the message
header and/or content. That requires message transfer.
The information that is transferred during the retained SMTP
exchange is minimally helpful, except for previous-hop IP
Address. Everything else requires access to the actual
message. This means reaching across the net to get the
message for inspection.
And this is better than transferring the message during a
regular SMTP session how?
We don't save cross-net transfers. We add transaction
overhead and delay.
The issue of hand-off responsibility is changed, but I have
not heard that asserted as a problem amidst anti-abuse efforts.
I agree, and dislike this proposal for this (primarily) and
other reasons, including my usual problem of not liking to have
to be online to read and reply to messages (I'm reading this
thread and writing this answer at circa 30K feet over the
But, in fairness to the proposal, the general idea has one
advantage. If one is concerned about source / originator
identity and authentication, having to make a real-time direct
connection back to the sender's repository permits thinking
about much stronger methods than, e.g., header signatures.
On the other hand, if we were willing to say "if you can't get
email unless you have stable end-to-end connectivity to the
sender", one could presumably get equally strong identification
and authentication with an enhanced SASL method and no new SMTP
extension protocol bits.