ietf-asrg
[Top] [All Lists]

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