Subject: RE: [Asrg] SMTP level unsubscribe

From: Andrew Akehurst <[email-masked]>
Date: Thu, 14 Aug 2003 15:09:18 +0100 (BST)

>> If there were a standard for expressing and communicating such
>> policies, it would allow any MUA to communicate policy with any
>> compliant MTA. Then far more people would have the benefit of
>> using such a system.
>>
>> I'm willing to volunteer to help draft such a standard, in line
>> with Section 2.6 of the Consent Framework. Who wants to help?

> If you're proposing to draft a protocol which allows individual
> block and pass prefrences to be expressed and passed freely around the
> network I'd be very interested.

As per my latest posting, my interest is primarily in the format to
express a consent policy. We will need people to work on a protocol
to exchange such policies (and consent tokens for them) as well.

For now I think we need to work on the format for expressing the
policy, otherwise such protocols will have nothing to exchange. But
unless the volume of posts becomes too big I expect we'll keep it
all on-list, so feel free to join in at whichever stage interests
you most.

> 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.

> 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.

> I'd like server level "blanket" policy to be expressable, and varying
> degrees of domain, sub-domain and user groups to also be specified,
> such that a sender MTA can build up a set of rules imposed by various
> *organisational* levels of the recipent's network admin.

So far most of the discussion I've seen has centered around the idea
that the "recipient is king", much of it has been about the
recipient's personal consent policy.

Of course from the MTA administrator's point of view, they need to
protect their network from massive abuse. And of course it is the
right of the organisation to block whatever traffic it chooses from
its own network. Some people might be against the idea of additional
filtering over and above the personal consent policy of the
recipient, although I can understand why such filtering may be
necessary in practice.

My "gut-feeling" is that the consent policy of an individual
recipient is distinct from the organisation's network abuse policy
although there is likely to be some overlap between what annoys an
admin and what bothers their end-users.

Some might say that administrative filtering is more within the
scope of a BCP rather than a standard. I'm not sure either way.

> Then any sender will be able to impose the rules before transport, and
> the recipient will be able to apply them after and still benefit from
> any saving made by having some mail delivery never even attempted.

This is an interesting approach. It suggests the idea of two protocols
(or maybe one protocol used for two different purposes):

 - for sending personal consent policy to the ISP's MTA
 - for a sending MTA to query a remote MTA's policy details

The latter is likely to be the more controversial.

> I have access to MTA software to experiment with, and a first hand
> knowledge of the implementation of many existing mail RFC's.

Excellent, we need some people who are in a position to try out any
proposed solutions. It's early days yet but that's why we need to
move things forward. Once we get some standards drafted we can try
them out and then feed back the results into improving such standards.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 14 Aug 2003 13:40:24 -0400

At 10:09 AM 8/14/2003, Andrew Akehurst wrote:

>..........

 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-----

>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.