ietf-asrg
[Top] [All Lists]

4d. Consent Framework - Scope (was RE: [Asrg] SMTP level unsubscribe)

2003-08-14 10:41:43
At 10:09 AM 8/14/2003, Andrew Akehurst wrote:

..........
> It seems to me that if we had a means by which a sending MTA could
> request such profile from the receiving MTA before sending it has the
> potential to drastically cut down spam.

This is an idea which has been discussed before on the list. Some
people objected on the grounds that a spammer using a compromised
MTA might scan people's personal consent policy to see how to
produce messages which will slip through the recipient's filters.

Other people might prefer the idea of partial disclosure: only
allowing certain MTAs to query the policy, or only allowing a subset
of the policy to be disclosed.

It's potentially a useful feature for reducing traffic but it may
be open to abuse by spammers, so it's a little controversial.

From the consent framework, section 2.1:

-------snip-----
Portions of the CONSENT POLICY may be communicated to the SENDER according to the SCOPE of the policy either by the CONSENT EXPRESSION COMPONENT or the POLICY ENFORCEMENT COMPONENT. When communicated by the CONSENT EXPRESSION COMPONENT, the purpose is to let SENDERS know what kind of CONSENT RULES they should follow in order for their email to be accepted. Examples of this might be when an ISP publishes a set of email policies for other domains which must be followed in order for the email to be received. When communicated by the POLICY ENFORCEMENT COMPONENT, the purpose of the communications will be to inform the SENDER of LACK OF CONSENT by the RECEIVER and to request a CONSENT TOKEN (if applicable). AGENTS communicating with each other may share CONSENT POLICIES to facilitate communications. They may also pass CONSENT TOKENS between themselves in order to dynamically grant or revoke consent to the RECEIVER, all according to the CONSENT POLICY SCOPE.
-------snip-----

> I'd like to see several layers to this, though they are all pretty much
> the same in operation but differentiated by scope.
>
> I'd like MUA's to be able to forward their policy to the incoming
> POP/IMAP server, this would then be available to be queried by delibery
> agents, and hence get into the SMTP network.

I must admit, I do like the idea of sending my policy to my ISP's
incoming mail server. At the very least this would allow them to
block spam on my behalf, saving me the need to download useless
messages which I'll only have to delete or locally filter anyway.


From Consent framework, ibid:

---snip----
A CONSENT POLICY of a specific RECEIVER does not merely reflect his choices. It is also based on the capabilities and settings of the CONSENT EXPRESSION COMPONENT used, the capabilities and settings of the POLICY ENFORCEMENT COMPONENT used, and by the SCOPE of the CONSENT POLICY of organization or ISP to which the RECEIVER belongs. The specific implementation being used by the RECEIVER, or his organization/ISP might support only specific types of CONSENT RULES which will be used in creation of the policy. CONSENT POLICIES from multiple RECEIVERS maybe combined to create a combined CONSENT POLICY for the entire organization or ISP. The organization or ISP may also impose its CONSENT POLICY on the RECEIVERS within its domain. Multiple ISPs and organizations may also shared CONSENT POLICIES in order to allow for interoperability between themselves. Standard CONSENT POLICIES may also be defined as Best Current Practices (BCP) documents.
---snip----


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



<Prev in Thread] Current Thread [Next in Thread>