Re: [Asrg] Re: 3. Requirements document
2003-09-29 11:31:34
gep2(_at_)terabites(_dot_)com wrote:
How would you suggest that recipients would go about granting and
denying permissions (or consent) if there are no standards in place?
I think that that is an issue to be described by the documentation for the
software involved, and/or the online help files that accompany it. I don't
think there needs to be ANY worldwide consensus on how that needs to be done.
What about the MUA communicating with the MTA? Wouldn't a standard way
of communicating consent between the MUA and MTA help?
What's more, it might well be COUNTER-PRODUCTIVE to our case just as it's
counter-productive for so many people to be using the same Outlook and Outlook
Express E-mail clients; it just gives spammers a common, familiar base to find
and exploit "universal" weaknesses in.
Does that mean we should abondon SMTP and HTTP since people can find
holes in them? A protocol that is properly designed and implemented,
will not be a problem.
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.
The consent exchange protocol would be useful primarly for telling your
MTA or ISP on what types of choices you made. Exchanges between senders
and receivers might only occur in certain cases such as C/R, or opt-in.
This would depend on how the protocol and the framework are designed.
I think what's the MOST important is that we get SOMETHING out that
significantly helps the recipient users, and soon enough that it's still of
value to them.
Definatly.
Are you suggesting that the receiver simply chooses not to receive certain
kinds of email and that email starts to bounce?
I think the recipient ought to have the choice of how to deal with certain types
of messages. "Bounce it" might be one option, although probably not a good one
since there are NO guarantees that there is even a valid POP3 mailbox at the
sender end (and even so, that it's possible to determine what that POP3 E-mail
address might be... clearly, a LOT of spam and viruses go out with forged/bogus
sender addresses, as we've seen recently).
I believe that in general, either just t-canning (or holding in limbo for some
time period, pending triage and final resolution) is probably a better approach
overall. I think that the best approach for most spam and virus mails, and with
ultimately the lowest total cost to the Net, is to simply route them all
(commensurate with the recipient's established and specified permissions rules)
down a black hole, and the sooner the better after they're sent.
RFC 3464 defines a DNS format for bounced messages which gets delivered
with the MAIL FROM <> line in order not to bounce again. If a message
gets "t-canned" and not delivered, the sender will not find out about it
and might assume the email went through. This would change the semantics
of email on the Net which has already begin from the side-effects of
various spam systems.
If so, there is still a need to have some form of a format or standard in
place that the receiver can use to communicate his consent decisions to his MUA,
MTA or ISP.
I don't think that that needs to be the result of a worldwide standard, in part
since the capabilities of different permissions list implementing systems are
likely to be VERY different, and may result in having quite different needs to
control those capabilities.
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.
The consent framework and protocol will define a framework for these
tools to interoperate. The implementation details of what kind of data
is exchanged can be left out of the standard.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
|
|