ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: 3. Requirements document

2003-09-26 08:46:43
On Sep 26,  2:34am, gep2(_at_)terabites(_dot_)com wrote:
} Subject: Re: [Asrg] Re: 3. Requirements document
}
} Since in a "proper" (IMHO) recipient-chosen, recipient-controlled
} system there is NO need for senders to interact directly with the
} recipient's chosen software (other than just by existing SMTP/POP
} protocols) I don't think there's any pressing need whatsoever for a
} worldwide permissions-and-control "standard" for interacting globally
} with these programs. I believe that the market itself will sort these
} things out, to the extent the need to be, in a relatively short time.

I may have missed something in the past part of this discussion, but
what gives you the idea that there is any "direct" interaction with
end-user software implied here?

Or perhaps a better question is, what's your definition of "direct"?

Was the world really a better place when every MTA generated a different
delivery status notification format, most of which were understandable
only by humans?  If so, why has the RFC3464 format become so common?
If not, shouldn't we apply that lesson to another case where a status
notification could be transmitted?

The important thing is a standard way of communicating the recipient's
choice.  There's no implication that anyone other than the recipient has
the right to make that choice, nor that the recipient has to have any
justification for which choice he makes.  It's wasteful of everyone's
resources if the choice is never communicated, i.e., that any no-longer-
wanted messages are simply discarded at the time of delivery.  The point
is to propagate the "discard" decision as close as possible to the sender;
in the case of a known and conscientious sender, ideally the decision
would reach all the way back and the sender would cease to initiate any
further messages.

The fact that there exist messages for which the sender is unknown and
malicious doesn't reduce the need for communication between recipients
and known senders.  In the case of known but oblivious or malicious
senders, a record that consent was revoked (or a lack of record that
consent was ever provided) may be useful in several respects.  At the
same time, a record that consent had at one time been provided is very
useful in cases of malicious or mistaken prosecution, where it is e.g.
the recipient claiming fraud who is in the wrong.

Even when the sender is unknown, it could be useful to communicate the
consent decision to an upstream provider and have the unwanted message
blocked earlier in the transmission process.  Yes, there's a possibility
of misuse or abuse here -- a message could be wrongly blocked upstream --
but guess what:  That's already the case now.  Communicating explicit
consent to the upstream would actually help prevent incorrect blocking,
not encourage it.

} For example, some of these filters might be implemented by Web-based
} tools, and others might be based on E-mail-type control commands.
} These two methods are likely to be (even VERY!) different. These are
} the types of things which individual ISPs and software providers are
} likely to use for 'product differentiation' that will give one ISP
} or software an edge over another. I don't think these NEED to be the
} result of a 'standards' effort.

Obviously not, but that has nothing to do with having a standard for
communicating the resulting consent decision.  Even if the standard
specifies a way to transmit some of the filtering information, there's
no reason that the end-user tool _has_ to transmit it, or to transmit
all of it.  The end-user tool can always apply filters in addition to
those described by the consent communication.

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg