Subject: Re: UPN + GROUP + UPNEXPAND question.

From: Doug Royer <[email-masked]>
Date: Thu, 9 Mar 2000 18:59:56 -0800 (PST)

> From: "Paul B. Hill" <[email-masked]>
> Subject: Re: UPN + GROUP + UPNEXPAND question.
> Cc: [email-masked]
> 
> At 09:10 PM 3/9/2000 -0500, Paul B. Hill wrote:
> >I may be confused but I think someone tried to sneak the equivalent of 
> >SMTP's EPN into CAP.
> 
> Oops, EPN should have been EXPN.

Okay. So, other than debuging - why do we want it (UPNEXPAND)?

With SMTP's EXPN, I think it is only used for debugging. I don't
think  MUA's use EXPN. The reason that I think that, is that
may MTA's do not allow VRFY or EXPN, they return unimplemented.
I would suspect the same for UPNEXPAND. Many will NOT want
to give out membership lists to spammers. And I do not see
any benifit for UPNEXPAND - other than debugging. And
it would not be used from a CUA, or at least it would not
be reliable from a CUA as it can be turned off at the CS.

If I am correct, I would make a motion to remove UPNEXPAND.

-Doug

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 09 Mar 2000 22:23:25 -0500

At 06:59 PM 3/9/2000 -0800, Doug Royer wrote:
>The reason that I think that, is that

SMTP is unauthenticated, CAP is not. A CS could have authorizations that 
determine which users are allowed to use UPNEXPAND.

It becomes more important when we consider the CS to CS usage of CAP. In 
this case the CSs might not share a common group definition. The UPNs that 
represent groups must be expanded prior to moving the data across a 
security context boundary so that a consistent evaluation can take place.

Paul

---

From: David Madeo <[email-masked]>
Date: Thu, 09 Mar 2000 23:07:44 -0500

> security context boundary so that a consistent evaluation can take place.

Even the CUA to CS model might have the CUA and CS having different user/group
directories.  The CUA needs to be able to ask the CS to expand the UPN for
it.  Especially on thin clients.

dmadeo

---

From: [email-masked]
Date: Thu, 09 Mar 2000 20:13:20 -0800 (PST)

> >be reliable from a CUA as it can be turned off at the CS.

An MTA that returns unimplemented for VRFY is in technical violation of
the SMTP specification.

> determine which users are allowed to use UPNEXPAND.

On the contrary, SMTP has authentication facilities. They are optional but they
are there. In fact deployment of them is happening pretty rapidly as they are
often used as part of a spam control strategy. And they can be used to
enable/disable use of EXPN.

				Ned

---

From: Doug Royer <[email-masked]>
Date: Fri, 10 Mar 2000 12:41:28 -0800

> An MTA that returns unimplemented for VRFY is in technical violation of

Right - I meant to say - EXPN returns "no I will not", which
I think is not a violation.

---

From: [email-masked]
Date: Fri, 10 Mar 2000 13:14:02 -0800 (PST)

> I think is not a violation.

Correct. Unfortunately, this sort of minutiae actually matters in practice,
since it affects what commands a client can expect to use. And there are some
very strange clients out there...

				Ned