Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records]

Here's are my first few examples:

Example1.com:
example1.com uses two providers: esp.com and personalmail.com .

Mail originating from personalmail.com is always conversational 
(corporate individual mailboxes) and rate limited to 100 messages a day 
by personalmail.com
Mail authored by example1.com originating from esp.com is rate limited 
to 4,000 messages a month by esp.com. This mail is bulk mail.
example1.com is a small b to b service business, as accredited by 
accreditors.com
Note: esp.com and personalmail.com set rate limits on a per customer 
basis; these limits are functions of the customer, not functions of the 
service that apply in an undifferentiated manner to all customers. I am 
taking it as given that esp.com and personalmail.com can write code to 
do lookups to check the veracity of their customer's statements on the 
MARID record.
Example2.com:
Example2.com is a new customer at both personalmail.com and esp.com. 
They have no accreditation or reputation, but each service rate limits 
them to 100 messages a day and 400 messages a month, with a total 
address count of 100. In other words, they can not correspond with more 
than 100 different recipients over the period of a month on either 
service.
Receivers side services can sum up the rate limits to calculate the 
total number of recipients and messages that can emanate from 
example2.com and decide whether it exceeds their policies on 
authenticated but unaccredited senders.
Example3.com:
Example3.com has limited internal controls and has decided to outsource 
the whole record management  and sending policy enforcement problem to 
maridRus.com. They know they send outbound mail through their inbound 
servers, but other than that they don't know how they send.
maridrus.com starts by publishing a record referencing the mx records. 
They need two kinds of feedback; abuse complaints, of which they want 
100%, and channels not listed in the example.com records, of which they 
want 1 in 1,000 messages.
Over time, example.com and maridRus.com conclude that esp1.com and 
esp2.com, in use by Departments A and B respectively, are authorized 
vendors, and that they don't need to duplicate complaint monitoring. 
They update the record such that complaints generated on mail on the 
esp1 or esp2 channel are  handled by the esps, and not copied to 
maridRus.com.
Example4.com
Example4.com is an esp bounce handling domain. This domain appears only 
in MAIL-FROM and never in SUBMITTER or the 2822 from address.
Example5.com:
[This is included because I think that over time it will be useful to 
everyone to have receiving as well as sending policies published, and 
having another syntax for that side of the policy equation doesn't make 
much sense to me]
Example5.com publishes their acceptance criteria as well their sending 
policies. They accept mail from authenticated but unaccredited senders 
who do not send more than 100 messages a day or 400 messages a month. 
Otherwise, they accept accreditations from accreditors.com (which 
presumably has pass-through arrangements with some number of other 
accreditors). example5.com requires confirmed opt in from everyone 
except senders accredited as financial institutions by 
verythoroughandexpensiveaccreditations.com. For financial institutions 
they require only prior business relationship, as defined by 
verythoroughandexpensiveaccreditations.com
This is used by esp.com to decide whether or not to send based on the 
characteristics of each of their customers, and to report back to their 
customers on what they need to do to get their mail delivered.
My real concern with SPF is the strong suspicion there is a lot we 
haven't thought of yet.
Margaret.

On Jun 16, 2004, at 6:54 PM, Marshall Rose wrote:

> the co-chairs think this is a useful thread; in fact, we're going to 
> place the following plan in front of the working group:
> it is clear to the co-chairs that the "tipping point" with respect to 
> the working group's deliberations revolve around the sufficiency of 
> the SPF syntax to address near-term concerns. if the syntax is 
> adequate, it is hard to argue for an alternative or future syntax; if 
> the syntax is inadequate, then the SPF syntax is of transitory use.
> in order to drive consensus on this issue, the chairs put forth this 
> plan:
> between now and sunday, june 20, 2004 23:59:59 us/pacific time, ALL 
> replies to this message must give examples of scenarios for which the 
> SPF syntax is insufficient. any requests for clarifications MUST be 
> sent directly to the authors of a scenario, who may then post a 
> clarification in reply to their own email.
> starting monday, june 21, 2004 00:00:00 us/pacific time, the working 
> group may reply to any of these scenario messages for the purpose of 
> explaining how the SPF syntax is sufficient.
> on thursday, june 24, 2004 23:59:59 us/pacific time, the chairs will 
> gauge the group's consensus on the issue of the sufficiency of the SPF 
> syntax.
> based on the chair's reading, the working group will be presented with 
> a plan for moving forward within the timeframe allotted by the 
> charter.
> so, to re-cap:
>
> 1. now until sunday evening: people post difficult examples
>
> 2. monday until thursday evening: people post explanations on dealing 
> with the difficulty
> 3. friday: chairs announce plan for moving forward.
>
> /mtr