As it says above your response it is only permanent *for that
recipient*. A new message envelope - or a web query - is exactly
what we are talking about. With C/R (which I don't use - I'm just
objecting to your rants)
The case against C/R was settled years ago, and it's an embarrassment
to have to debate an even more primitive version than the one that
(briefly) saw the light of day.
The "old new" C/R that is being considered here only works in an
imaginary world where you get to publish a Standard RFC whenever you
want. Envelope-time C/R was already considered and dismissed. There is
nothing newly standardized in SMTP that makes it any more feasible
now.
the 5xx (or DSN) is in some sense a lie: the message is stored
someplace. It just won't be delivered until some event unrelated to
SMTP takes place. 551 says delivery to that recipient is dead in the
water - but suggests another recipient to use instead.
I fully understand the imaginary C/R implementation.
Unlike the real-world C/R implementations, it requires an
across-the-board rewrite of the way SMTP senders deal with an existing
class of permanent errors: hiding the permanence of the error and
substituting friendly language that directs the user to use an
out-of-band method of requeueing/unquarantining a stored message
object.
Like the real-world C/R implementations, it suffers from a plethora of
guaranteed deal-killing problems because listserves, et al. do not
read responses, whether they are true DSNs, massaged DSNs, or crafted
procmail responses.
Like the real-world C/R implementations, it permanently adds HTTP into
SMTP as if that's just a small step that will not at all influence the
willingness/ability of even *human* senders to pursue the final
delivery of the e-mail.
Unlike the real-world C/R implementations, it does not create
backscatter. Yet since the imaginary implementation isn't possible, it
hardly seems necessary to note this "pro".
And to believe in the imaginary C/R implementation apparently also
requires a suspension of disbelief that quarantines are *by their very
definition* outside of the people's day-to-day workflow.
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: sandy(_at_)cypressintegrated(_dot_)com
------------------------------------
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com