Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 18 Jun 2004 20:55:35 -0700

Another example where SPF syntax comes unstuck.

A domain uses S/MIME authentication in addition to IP based auth. This
allows a mail message from a bank to display the logo of the bank in a
privilleged part of the display by means of the X.509 logotypes extension.

The following information is needed:

	* express statement 'all mail is signed'
	* express the message digest of the signing certificate
	* express the algorithm supported.

Now consider the following complications:

	* Also support pgp message format
	* express different signing policies 'mail signed when extension
offered'
	* handle the TLS protocol
	* encryption
	* different key distribution structures - web 'o trust, xkms, domain
key

I don't think anyone can fairly claim that the spf ad-hoc syntax is going to
cope with this. OK you can define ad hoc extensions, but the number of
degree of freedom are huge.

This is not a theoretical proposal. The use of signed mail is already under
serious discussion in anti-phishing forums. 

One could argue that this should be handled by a separate record. But then
we are back to the two parsers option anyway. 

It took me less than half an hour to write a schema for this application in
XML. I don't think anyone could claim to write a parser for a corresponding
SPF syntax in the same time.

---

From: Philip Miller <[email-masked]>
Date: Sat, 19 Jun 2004 10:57:44 -0400

> A domain uses S/MIME authentication in addition to IP based auth. This

S/MIME != MTA Authorization. S/MIME only deals with DATA contents, which can 
be identical from authorized and unauthorized MTAs. There is no reason that 
MARID should have anything to do with S/MIME. Thus, there's no problem with 
SPF syntax not supporting S/MIME.

> 	* express the algorithm supported.

Someone should definitely write a standard for expressing that in the DNS. 
However, that doesn't appear to be in scope for this group. I haven't read 
the Yahoo DomainKeys proposal, but isn't that exactly what it deals with?

> 	* express different signing policies 'mail signed when extension

PGP and content-signing have nothing to do with the MTA, same as S/MIME.

> 	* handle the TLS protocol

TLS is the only piece of this that I can see as being related to MTA 
authentication or authorization. How about a new mechanism in SPF syntax, 
'tls', that specifies the fingerprint of the certificate that the sending 
MTA will present, or of a CA cert that signed it? Then SPF doesn't need to 
specify IP addresses any more, since you could express "all mail sent by a 
server with this cert is from my domain, regardless of where it is 
connecting from".

If you meant "the connecting IP is part of a given set, and it uses TLS with 
a certain certificate", then I don't think any of the existing proposals 
cover that. Even if they did, what is the use-case for it?

> 	* encryption

Whether it encrypts or not has nothing to do with authentication or 
authorization.

> 	* different key distribution structures - web 'o trust, xkms, domain

Again, not relevant.

> degree of freedom are huge.

Many of us opposing a heavily extensible syntax want to limit that freedom, 
for simplicity of implementation and ease of deployment. Very simply, I 
don't want SPF ad-hoc syntax to deal with this, because it's not relevant to 
the goal we're trying to reach of authorizing the MTA, and not the data the 
MTA is sending.

> serious discussion in anti-phishing forums. 

Good, but it should be independent of protecting domains from MTA identity 
forgery.

> we are back to the two parsers option anyway. 

Two parsers, yes, but neither dependent on the other. One could check that 
the connecting MTA is authorized without checking the signature on the 
message it sends, or vice-versa, or both.

> SPF syntax in the same time.

No one needs to write that parser for SPF, because it's already written. In 
Perl, C, Java, and Python. From implementation code that I've looked at, one 
needs to be able to make a single function call into any one of those 
languages to check whether a connection is authorized or not.

Philip Miller

---

From: Sean Comeau <[email-masked]>
Date: Sat, 19 Jun 2004 14:29:32 -0700

> privilleged part of the display by means of the X.509 logotypes extension.

That sounds like something that belongs only in MUAs. I think that's way beyond 
the scope of SPF and its ilk. 

> 	* express the algorithm supported.

I claim, quite fairly, that spf syntax can handle this.

> 	* different key distribution structures - web 'o trust, xkms, domain

[ ... ]

> serious discussion in anti-phishing forums. 

It all sounds pretty vague to me. Perhaps you could explain more of the details.

> SPF syntax in the same time.

that doesn't make any sense. obviously defining a schema/format/syntax takes way 
less time than writing the code to actually read it.

---

From: Marshall Rose <[email-masked]>
Date: Sat, 19 Jun 2004 16:38:42 -0700

sean - did you miss the part in my email where i very specifically told 
people not to reply directly to any examples until after sunday, june 
20, 2004 23:59:59 us/pacific time?

phillip - i ask that you do not reply to sean's note.

sean - i ask you to resend that note after the deadline; furthermore, 
you have been warned.

/mtr

---

From: Marshall Rose <[email-masked]>
Date: Sat, 19 Jun 2004 16:39:30 -0700

philip miller - did you miss the part in my email where i very 
specifically told people not to reply directly to any examples until 
after sunday, june 20, 2004 23:59:59 us/pacific time?

phillip hallam-baker - i ask that you do not reply to philip miller's 
note.

/mtr

---

From: Mark Lentczner <[email-masked]>
Date: Mon, 21 Jun 2004 13:32:03 -0700

I'd like to respond to the three postings about why SPF syntax is not 
sufficient that appeared in this thread during the last few days.

First, I'd like to state my view that while there are many approaches 
and parts of the problem of unwanted mail, the original SPF was 
designed to implement a small, but important, slice of them.  When it 
was seen that several other approaches were converging on similar 
ground, there was a push to consolidate them and one result of that 
push was this working group.

In light of that, I see that each of the three postings argue that the 
SPF syntax can't handle something that it wasn't designed to handle.  
They are issues and approaches that are beyond the original scope of 
SPF and the similar projects that are trying to be merged here.  In 
particular:

1) Margaret Olson's examples
Alas, these examples didn't actually state what aspect SPF couldn't 
handle.  I don't know if the desire is to have mail rate information in 
SPF, or reputation information or what.  As a part of the system, SPF 
seems to me to work in all the examples given.

2) Jim Lyon's examples
These examples focused on assignment of reputation, and how that might 
depend on the route the mail takes, or even perhaps on different 
mailbox names within a domain.  I contend that these are issues for the 
reputation systems.  All SPF does is authenticate that the domain 
believes that it's mail could have traveled via a particular MTA.  If 
that check passes, normally, one just feeds the domain name into a 
reputation system (such as white or black lists.)  If there is need for 
finer grained reputation, then it is up to some reputation service to 
offer better assessments based on more information.  Nothing in any of 
the proposals tells clients how they should assess reputation.  If it 
is argued that domain name based reputation will be the only de facto 
available option, then I submit it isn't too hard for large entities to 
use multiple mail sub-domains:
     [email-masked] - mail from real people
     [email-masked] - mail from opt-in newsletters
     [email-masked] - unsolicited advertisement

3) Phillip Hallam-Baker's examples
These examples are a clear extension into other approaches.  None of 
these examples has anything to do with domain authentication of an IP.  
To quote Phillip about such extensions: "...the number of degree of 
freedom are huge".  To this end, these examples beg for something much 
larger than the part of the problem the current projects ever set out 
to handle.

I understand the desire to design a more comprehensive mail policy 
format.  And I understand the desire that such a format be extensible 
for future approaches that are now only contemplated.  However, the 
proposed XML syntax doesn't achieve this either:  While it is true that 
XML provides a much richer syntactic framework in which to extend an 
original document format, it says nothing about the semantic meaning of 
such extensions.

In the six months that the XML format has been in public discussion, I 
haven't seen one proposal that actually includes the rules for semantic 
interpretation of future extensions.  This is no surprise: It is a hard 
problem.  The myriad of possible extensions that have been expressed, 
and their subtle effects of the semantics of the original format make 
it clear that defining how clients are to interpret future extensions 
would be difficult.

I maintain that, in the problem space these projects were designed for, 
namely authentication of the origin of mail based on the domain name, 
the SPF classic syntax does just fine.  There is a little room for 
extension (defined both syntactically and semantically), just enough to 
handle a few future ideas within this problem space.  I think Dave 
Crocker's posting from earlier today 
(http://www.imc.org/ietf-mxcomp/mail-archive/msg02139.html) speaks for 
this approach eloquently.  When a larger framework for mail policy 
emerges, SPF can easily add a modifier for pointing to it.  Or perhaps 
SPF will have run its course, and the newer framework will simple take 
over.  Either way is fine.

Solving the original small, but important slice that all of the 
original projects targeted should be our first priority.  If we can do 
that, then we show the world, and ourselves, that we are capable of 
tackling more.

	- Mark Lentczner

Mark Lentczner
http://www.ozonehouse.com/mark/
[email-masked]

---

From: Margaret Olson <[email-masked]>
Date: Mon, 21 Jun 2004 19:37:26 -0400

On Jun 21, 2004, at 4:32 PM, Mark Lentczner wrote:

> handle.  I don't know if the desire is to have mail rate information 
> in SPF, or reputation information or what.  As a part of the system, 
> SPF seems to me to work in all the examples given.
>
Yes, the desire is to have mail rate information in the MARID record. I 
apologize for not being clearer about that. Several people have noticed 
that you don't necessarily trust the record author - but that is why 
you accredit both the sender and any channels used with indirect 
pointers. The rate at which a domain sends mail is an important piece 
of the risk assessment puzzle - should I accept this mail or not? If I 
know that you send at a rate that is inconsistent with spamming or if 
you have a very thorough, audit driven accreditation, then I'll accept 
your mail.

There are many ways in which I can envision transmitting and enforcing 
rate information; my examples were intended simply to illustrate the 
problem.

MARID on it's own doesn't do very much; it just says that the domain is 
authorized to send mail via these MTAs. It is essential for a broader 
solution to the spam and phishing problems but not sufficient. Phill 
Hallam-Baker and Jim Lyons have made other suggestions for how we might 
incorporate the reputation, accreditation, signature, and other 
information that is necessary. I don't think any of us have the 
complete answer yet but these things are emerging. The will be tied to 
the authentication. We need to be able to accommodate the additional 
information, even though we don't have it completely designed at this 
moment in time. We know it is out there.

> mailbox names within a domain.  I contend that these are issues for 
> the reputation systems.  All SPF does is authenticate that the domain 
> reputation system (such as white or black lists.)  If there is need 
> for finer grained reputation, then it is up to some reputation service 
> to offer better assessments based on more information.  Nothing in any 
> of the proposals tells clients how they should assess reputation.  If 
> it is argued that domain name based reputation will be the only de 
> facto available option, then I submit it isn't too hard for large 
> entities to use multiple mail sub-domains:
Creating sub-domains to make up for a syntax limitation doesn't make 
any sense to me.

> proposed XML syntax doesn't achieve this either:  While it is true 
> that XML provides a much richer syntactic framework in which to extend 
> an original document format, it says nothing about the semantic 
> meaning of such extensions.
>
As Jim Lyons stated elsewhere in this thread, you need to stick to 
upwards compatible extensions. In practical terms, this means you can 
add information but you can't change the definition of existing 
information. The XML syntax handles this well. I agree that no amount 
of syntax will paper over the problems inherent in an extension that 
changes the meaning of existing published records.

Margaret.
[email-masked]
[email-masked]

---

From: wayne <[email-masked]>
Date: Mon, 21 Jun 2004 22:32:20 -0500

> Another example where SPF syntax comes unstuck.

[out of order reply:]
> degree of freedom are huge.

On the contrary, I think that these are cases that can easily be
handled directly with the current SPF syntax. 

I don't see any difference between defining extensions as SPF
modifiers and defining new labels in the XML markup.

> A domain uses S/MIME authentication [...]
>

use the modifier: smime=always

> 	* express the message digest of the signing certificate

use the modifier: smime.certdigest=<location>

> 	* express the algorithm supported.

use the modifier: smime.alg=rsa

Or, just use:  smime-info=<location>

> 	* Also support pgp message format

Use the modifier:  pgp=allowed

> 	* express different signing policies 'mail signed when extension

I don't understand this one.

> 	* handle the TLS protocol

that is handled just fine with the MTA isn't it?

> 	* encryption

use the modifier: encryption=

> 	* different key distribution structures - web 'o trust, xkms, domain

use the modifiers:  webotrust=<location> xkms=<location> dk=<location>

> we are back to the two parsers option anyway. 

No, because the MTAs would not be *required* to support two (or more)
parsers.  Many of these options wouldn't require a new parser anyway.

-wayne

---

From: Greg Connor <[email-masked]>
Date: Mon, 21 Jun 2004 22:38:16 -0700

A lot of good discussion is already going on, and I don't want to take too 
much time by repeating what others have said.  Therefore, I will try to be 
brief  (Hmm, I guess "try" is the operative word here :)

First off, extensibility is not bad.

I don't think anyone is seriously arguing "extensibility is bad".  Rather, 
I think everyone has their own ideas about how important "extensibility" is 
compared to other attributes like simplicity, human readability, 
byte-economy, etc.  Since this is a pretty wide spectrum, and "correct" 
answers lie all along the scale for various stakeholders, I will not try to 
pull anyone in any direction.  The best I can do is encourage everyone to 
take a few moments to rank qualities in their minds that make up a "good" 
proposal.

Second, let me stress that SPF syntax actually IS extensible.

SPF provides four vehicles for extension.  Let me review them quickly -- I 
know people are familiar with the draft and SPF site but just in case it 
wasn't stated clearly, here they are.

1. Modifiers

Modifiers are attribute=value pairs that the receiver may ignore if he 
doesn't understand them.  For example

example1.com. IN TXT { "v=spf1 a mx ptr "
	"rate=100 +include:example1.com.cust-spf.esp.com "
	"rate=133 +include:example1.com.spf.personalmail.com ~all" }

In this example (based on Margaret's first scenario) the "extra" 
information is understood by whoever wants to understand it, and ignored by 
anyone who doesn't.

(One sort of limiting factor about modifiers is that they are considered to 
be order-independent and the current spec encourages them to be placed at 
the end to make this clear.  If I were to propose any modification to the 
current spec, it would be to allow modifiers to be placed inline allowing 
for the possibility that they might apply/associate the terms appearing 
after them, if appropriate.  This minor change in the spec should not 
affect any current parser or published records and would just be a 
clarification...)

2. exists: mechanism

exists: makes it possible to do something DMP-like (factored) plus a lot 
more.  Most sites will not need it, but those that do will be quite 
thankful it is there.

I am describing exists: as a "vehicle for extensibility" because it makes a 
lot of things possible that would not otherwise be achieveable, including 
many we have not yet thought of.  Let me use an example based on Margaret's 
third situation.

example3.com. IN TXT "v=spf1 redirect=example3.com.cust.maridrus.com"
example3.com.cust.maridrus.com. IN TXT { "v=spf1 a mx ptr "
	"-exists:CL.%{i}.FR.%{s}.exceptions.maridrus.com. "
	" ?all abuse=[email-masked]" }
exceptions.maridrus.com IN NS ns-log1.maridrus.com.
exceptions.maridrus.com IN NS ns-log2.maridrus.com.

In this example, example3.com delegates their MARID policy management to a 
third party "maridrus.com".  They in turn use an exists: check which is 
(usually*) triggered only if the a, mx, and ptr tests are not met.  By this 
mechanism, the receiver is required to issue a query ending in 
exceptions.maridrus.com and containing the IP of the sending client, and 
the return path of the questionable message.  The queries are then logged 
and unforseen sources of example3.com mail become exposed.  (This is also a 
GREAT way to monitor how well your MARID record is doing at catching all 
situations, and also a great way to find forwarders that have not been 
white-listed by the receiver.)

(* I say "usually" here because all currently existing SPF implementations 
have the processing happening in strict order, but if a streamlined 
parallel-type processor is created later, it's not much of a problem.  As 
long as the receiver re-assembles the steps in the correct order and 
arrives at the same result, it is permitted to make "extra" queries -- it 
is the responsibility of the domain using exists: to screen out 
false-positives.  It's also possible for a malicious sender somewhere to 
just make extra queries to throw off the logging - anyone doing logging 
would need to be alert for this too.)

My second reason for describing "exists:" as a vehicle for extensibility is 
the little-known secret of exists: the domain owner may decide to customize 
the DNS server itself.  For example, let's say that the maridrus.com 
service provider wants to do something with the "exceptions.maridrus.com" 
zone that a static zone file can't do.  They want to answer YES to all 
exceptions *unless* a threshold is reached, and then reply NO to a certain 
IP, or sender address, or both, if that IP or address has been used too 
many times outside the policy.  They can teach their DNS server to answer 
NXDOMAIN for the first 100 uses of any IP or email address, and then answer 
127.0.0.2 after the limit is reached.  This requires a non-standard DNS 
server, but the sender may bear 100% of the costs of this type of 
extensibility and still be within the standard.  (I know the idea of 
returning inconsistent results will make Jonathan twitch, but the fact is 
that DNS servers that serve dynamic/varying information are already out 
there, e.g. 3DNS/akadns :)

3. Unknown/non-standard mechanisms.

The behavior when we come to a non-standard mechanism is well-defined: 
currently the spec in use today says that processing should stop 
immediately and an unknown result should be returned (as if ?all had 
appeared where the non-standard mechanism is).  This is not a "forbidden" 
or even a "bad" practice - it simply gives a reasonable escape clause if 
you decide to use a mechanism that is not in the pre-existing core set of 
features.

The SPF spec actually uses domainkeys as its example in the draft.
  v=spf1 a mx ptr domainkeys:_dk.%{d} -all

Basically, this means, if you understand what domainkeys: means, proceed 
ahead with either accepting the mail with DK, or rejecting unsigned mail 
with confidence.  But if you don't understand what domainkeys: means, the 
record behaves like this for you:
  v=spf1 a mx ptr ?all

That means there IS a way to add semantic (feature-wise) extensibility, but 
only one way.  The "default to unknown" rule is a reasonable default that 
probably applies well to 90%+ of the cases where you might ever want a new 
non-core feature.

I know that I have proposed alternatives to this default in the past, but 
frankly I have changed my stance on this a bit, after listening to all the 
feedback on what people really want from extensibility.  Semantic or 
feature-wise extensibility scares people, a bit.  It's not 100% clear that 
we need it built in the spec, so I am starting to think that "default to 
unknown" is an extremely reasonable rule.  Basically, this is a sane 
default that *DOES* allow for semantic extensibility -- if the sender and 
receiver both choose to use a new keyword, they can -- but provides a 
safety valve that everyone understands.  I doubt that people really want 
more feature-wise extensibility than this, but if they do, they can 
continue on to the next section.

4. A new version tag

This is basically the equivalent of publishing a new/enhanced spec, for 
example:

nekodojo.org. IN TXT "v=spf1 a mx ptr ?all"
nekodojo.org. IN TXT "v=marid2 a mx ptr on_error=? { magic:happens } -all"

But keep in mind that *anyone* can publish new TXT records with a different 
prefix; they are not necessarily constrained to obey only the v= values 
that we dole out.  For example:

nekodojo.org. IN TXT "v=spf1 a mx ptr ?all"
nekodojo.org. IN TXT "v=spf1+d +domainkeys:valid 
?exists:%{ir}.non-compliant-lists.yahoo.com -domainkeys:unsigned -all"

If length of either becomes a problem, we can do what we always do: use 
redirection for one version or the other (or both).

I know the idea of coming out with a new spec bothers people, but I think 
PHB's presentation at ETC last week underscores the need for this type of 
upward mobility: the perfect is the enemy of the good.  We can produce good 
protocols and update them after deployment, much faster than we can roll 
out perfect protocols.  (Demonstrated using example of SSL exploits and 
updates/fixes).

Finally, let me close with asking "What kind of extensibility is *enough*?"

Mark addresses this more eloquently than I probably can, so let me quote 
him a bit here.

--Mark Lentczner <[email-masked]> wrote:
> format.  And I understand the desire that such a format be extensible for
> future approaches that are now only contemplated.  However, the proposed
> XML syntax doesn't achieve this either:  While it is true that XML
> provides a much richer syntactic framework in which to extend an original
> document format, it says nothing about the semantic meaning of such
> extensions.
>
> namely authentication of the origin of mail based on the domain name, the
> SPF classic syntax does just fine.  There is a little room for extension
> (defined both syntactically and semantically), just enough to handle a
> few future ideas within this problem space.  I think Dave Crocker's
> posting from earlier today
> Solving the original small, but important slice that all of the original
> projects targeted should be our first priority.  If we can do that, then
> we show the world, and ourselves, that we are capable of tackling more.

I interpret this to mean:

1. Some extensibility, especially relating to our target problem, is good.

2. Our spec maybe (probably) will be part of a larger "email policy" 
framework in the future.

3. Creating the larger email policy is not exactly our job.  Creating a 
vehicle flexible enough to carry such a framework is not exactly our job. 
Perhaps we COULD do it, but I am concerned that trying to do so might get 
in the way of other objectives.

4. We all understand that the LMAP problem is but one step on a long road. 
If our spec becomes outdated, superseded, deprecated, dropped or whatever, 
it's probably because something better has come along.  That doesn't mean 
we failed.  If our spec is superseded in a year or two, and during that 
time it makes other things possible (like domain-based reputation systems) 
then we will have succeeded.

Thanks,
gregc

P.S.  You know, who says we have to stop working together when our first 
spec is proposed standard?  I think it's entirely possible that we can keep 
going with other proposals, best practices statements, etc.  If not us, 
who?  :)

--
Greg Connor <[email-masked]>

---

From: "Michael R. Brumm" <[email-masked]>
Date: Tue, 22 Jun 2004 04:35:28 -0600

>affect any current parser or published records and would just be a 

Out of all the SPF spec changes proposed in the name of "extensibility" in the last couple months, I'd have to say that IMHO, this is probably the most reasonable. I'd vote for it.

Michael R. Brumm

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 22 Jun 2004 08:16:37 -0400

----- Original Message ----- 
From: "Michael R. Brumm" <[email-masked]>
To: "IETF MARID WG" <[email-masked]>
Sent: Tuesday, June 22, 2004 6:35 AM
Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re
cords]

> Out of all the SPF spec changes proposed in the name of "extensibility" in
> the last couple months, I'd have to say that IMHO, this is probably the
> most reasonable. I'd vote for it.

hmmm, Michael, I think it would be better for SPF to being a new version
number at this point with the goal of cleanly defining its new needs.  A
"V=SPF2" or whatever where the client software would have new and clearer
functional specifications in the implementation.   For V=SPF1,  clients need
to continue to support the original functional specs in order to support
legacy systems.  A legacy client can't be broken with a SPF1 record now
having unexpected "parts," including having unknown extensions before the
ALL directive or trailing the ALL directive..  Trailing Extensions is a
lesser issue, but its support is limited to only those clients that expects
the trailing extensions.

SPF2 clients will be backward compatible and easily handle both.  SPF
Documentation won't be a mess. It will be clearly separated - a clean slate
to move forward with a new "clean" format and more importantly with MARID in
mind, without inline kludges and conflicts with directive processing order
presented with attempting to add extensions.

From a sysop or domain standpoint, if he wants the use the core original SPF
features, then he would define a traditional V=SPF1 without any SPF2
features.  This will give him the widest support for legacy SPF1 system and
new SPF2 systems.  But if he needs SPF2 features, then he would use V=SPF2.
Period.  Lets not confuse the design.  After all, using SPF2 features in a
SPF1 record will mostly break the rule processing in legacy SPF1 clients
anyway so he is limited to SPF2 systems only.  I don't see that as an issue.
He will understand that the feature set chosen is only doable with old or
new systems anyway.  A neat straight forward "Feature/Version Table" will
illustrate this to the sysop and help him decide what's he needs.

Also, with the new SPF2 specification,  it could include a possible
provision for domains to defined both records if so desired.  SPF1 clients
will only read SPF1 and SPF2 clients will read the SPF2 record.  The issues
regarding duplicity or large record requirements will have to be something
the sysops needs to weight. I see this as a now issue.

From my standpoint,  this will make it easier for me to implement, easily to
explain and document for sysop/customers to decide.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Meng Weng Wong <[email-masked]>
Date: Tue, 22 Jun 2004 11:10:17 -0400

I would like to request that participants in this working
group avoid the use of unspecific language where possible;
they lead to confusion.

For instance, the "you" intended by the author of a message
may or may not match the "you" interpreted by its audience.

On Mon, Jun 21, 2004 at 07:37:26PM -0400, Margaret Olson wrote:
| Yes, the desire is to have mail rate information in the MARID record. I 
| apologize for not being clearer about that. Several people have noticed 
| that you don't necessarily trust the record author - but that is why 
| you accredit both the sender and any channels used with indirect 
| pointers.

Please correct me if I'm wrong: in the above paragraph, I
take the first "you" to mean a receiver with no preexisting
relationship with a sender domain.

But the second "you" seems to mean "the system in general
should provide an architecture in which it is possible for
accreditation services to".

---

From: Margaret Olson <[email-masked]>
Date: Tue, 22 Jun 2004 11:59:14 -0400

> accreditation services to".

Your interpretations are correct. My apologies for the sloppiness - I 
wrote that message quickly and it shows.
Margaret.