A properly designed C/R system should *not* expect all senders to
respond. It should *not* increase the probability of a losing a
legitimate message.
And that is why this design exists only in your mind, until you
reinvent SMTP.
Your design dictates that some permanent non-deliverable messages be
transformed into "out-of-band action required for delivery" messages.
You suggest using standard SMTP permanent error codes to implement
this nuance. [Never mind the fact that the final disposition of the
message, if indeed the message object is stored on an intermediate
server instead of deleted, is closer (if anything) to a new type of
transient error.] Implementing your design would require an end-to-end
revisiting of how major MTAs deal with permanent error codes.
I don't mean to be entirely dismissive. It is always tempting to
brainstorm "human intervention" solutions that occur during the SMTP
envelope, instead of creating post-acceptance DSNs and inevitably
creating backscatter. Yet you seem unwilling to see your design as
more fitting a new (E)SMTP _extension_, insisting that it is in some
way workable now. That is why it fits with standard kookery.
Why don't you rethink and propose your idea in terms of a new SMTP
extension (i.e., SMTP verb/s)? Your basic notion is to expose a
requeueing mechanism to the end user using some standard notation.
Most MTAs, for example, give the admin the ability to "Send now" a
specific message object from the retry queue, though this
functionality is rarely exposed to the end user due to obvious
security and stability concerns. Perhaps what you want is to tag some
messages a with a "source-requested retry allowed" and/or
"source-requested retry only" flag. (I would advise you to abandon
your idea of the _remote_ quarantine; that leaps over a security
barrier that doesn't make this feasible as a proposed extension, and
it also means that all messages will be accepted in entirety by the
remote server, which is a tremendous waste of bandwidth.) Messages
with such flags will be kept in the queue for the standard queue
lifecycle, but your extension will instruct that a context-specific
DSN be sent to the end user when both sides support the extension. A
receiver-supplied challenge based on transaction ID would be
presented. (URL to a CAPTCHA, whatever). The response would be added
to the message envelope and transmitted along with the message object
upon the subsequent retry.
By proposing a new SMTP extension, you would lessen skeptical
responses based on real-world experience. An SMTP extension would need
to be announced and supported on both sides in order to work, allowing
more graceful degradation based on mutual understanding of both sides'
capabilities. A receiver would decide whether to accept mail in
sessions during which extension support was not announced (as public
MXs implicitly decide to accept mail from senders who did not
authenticate, MIME bitness is negotiated, PIPELINING is agreed upon,
etc.). A mandatory spam weight could be given to messages submitted
without extension support, or they would be rejected. And so on.
The message is going to the quarantine anyway. A response will move
it from the quarantine to the inbox. No response just leaves it
where it is.
It will "just" be in the quarantine, which at its *most* user-friendly
is linked in real-time to the user's Junk Mail folder. And we know
that JM folders are practical peers to people's Inboxes and sorting
rules -- there is no devaluation of JM folders, right? Well, no. This
fails to persuade or distract from the essentially imaginary quality
of the design.
--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