Subject: Re: [Off Topic] Need review for POP3 extension mechanism
From: "Mike Gahrns" <[email-masked]>
To: "Randall Gellens" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 22 Jul 1998 20:46:55 -0700

*** within

>At 9:18 PM -0700 7/21/98, Mike Gahrns (Exchange) wrote:
>
>>I do have one minor concern regarding the current wording of the
>>EXPIRE setting.
>>
>>The draft states:
>>"If the expiration policy might differ per user (that is, the EXPIRE
>>argument might change after authentication), the server MUST announce
>>in the AUTHENTICATION state the smallest value which might be used.
>>The server should announce the more accurate value in the TRANSACTION
>>state.
>>
>>It is unclear to me whether the intent of this is to force the server
>>to keep track of the smallest setting a user currently has set, or if
>>it is for the server to annouce the smallest value that an
>>administrator could conceivably set for a particular user.  If the
>>intent is the former, than this will be problematic for servers that
>>are not tightly coupled with their directory, as it effectively forces
>>the server to scan a list of all user settings at each log on time.
>
>The intent is to let the client know that the server does permit mail
>to be left on the server, and to present a value which is the smallest
>which might be set for the user.  This could be the smallest value
>currently in use for any user (so only one value per server), or even
>the smallest value which the server permits to be set for any user.
*** If it is the smallest value which the server permits to be set for any
user, I am happy with it.
Would it be possible for you to update the draft with the above paragraph?
If I had the question, I am sure others will... The more precise we are now
with things, will save us interoperability grief later and it really is just
a minor clarification so we won't need to worry about another last call.
(The smallest value currently in use by any user on a server is problematic
for us, but we do not have any objections if other servers want to present
this value if they can easily calculate it) This should not pose any interop
problems either.  Basically, if a client wants to get the accurate setting,
they need to re-issue the CAPA command after authenticating, so i do not
really think it matters too much what was presented in the unauthenticated
state.
Having said that, perhaps a better solution would be to define another
arguement called "USER".
If a client does a CAPA and gets an EXPIRE USER, in the unauthenticated
state, it knows that the server supports per user expiry settings.  It
explicitly informs the user when they need to re-issue the CAPA command
after authentication due to per user options.

>This way a client can decide (because the user has told the client to
>leave mail on the server for a larger number of days)  if it needs to
>reissue CAPA after authenticating and/or warn the user.
*** this is assuming that the client ui has something that allows the user
to specify the number of days to leave mail on the server.  I believe some
clients just have a "leave mail on server" option.  In this case, I guess
the client will always need to reissue the CAPA command after
authentication.

The interop problem I see is the following:
The client is running against a server where expiry is set on a per user
setting.  Let's say the server allows the admin to specify per user expiry
settings. For the client that is logged on, the per user expiry is set to
30.  However, on the server he is running against, there is a user who has
expiry set to 15.  Or it is a server, where the lowest expiry setting is not
available, so the server reports what the theoretical minimum it can be set
to, lets say 1.
Unless things are spelled out explicitly within your draft, I can see a
client issueing only a single CAPA before authentication.  Without it doing
another CAPA after authentication, the client would be spitting out bogus
warnings for the user saying "your messages will be deleted from the server
after 15 days" when really the setting is for 30 days.  Being really
explicit in the draft will ensure that client writers don't make that
mistake.

>
>
>>Another minor nit is the wording:
>>"If the authentication step negotiates an integrity protection layer,
>>the client SHOULD reissue the CAPA command after authenticating to
>>check for active down-negotiation attacks."
>>
>>I'd like to see the wording changed to something like:
>>"The client SHOULD reissue the CAPA command after authenticating to
>>check for active down-negotiation attacks and to get any per user
>>capability settings."
>
>The intent is to not require clients to issue two CAPA commands.  The
>client pretty much has to issue one before authenticating, to learn
>which SASL mechanisms are supported, but doesn't have to issue on
>afterwards, unless the first CAPA reveals that the server supports some
>capabilities whose parameters might change after authentication, and
>the client needs the most accurate values (it might be able to use the
>more general ones), or the client wants to check for down-negotiation
>attacks.
*** Agreed.  The point I was making is that it does not hurt to call out in
the doc the need to recheck parameters that might change after
authentication.  The wording you have only mentions down negotiation
attacks.

 A simple client that only uses a few basic SASL mechanisms,
>for example, and only needs to know if the server supports TOP, UIDL,
>and allows mail to be left on the server, doesn't need to issue two
>CAPAs.  (A client which only uses plaintext or APOP could issue only
>one CAPA, after authenticating.)
Agreed. And perhaps this adds more fuel to returning USER when there are per
user settings.

Date: Wed, 22 Jul 1998 12:08:00 -0700
To: "Mike Gahrns (Exchange)" <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: RE: [Off Topic] Need review for POP3 extension mechanism
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 9:18 PM -0700 7/21/98, Mike Gahrns (Exchange) wrote:

>I do have one minor concern regarding the current wording of the
>EXPIRE setting.
>
>The draft states:
>"If the expiration policy might differ per user (that is, the EXPIRE
>argument might change after authentication), the server MUST announce
>in the AUTHENTICATION state the smallest value which might be used. 
>The server should announce the more accurate value in the TRANSACTION
>state.
>
>It is unclear to me whether the intent of this is to force the server
>to keep track of the smallest setting a user currently has set, or if
>it is for the server to annouce the smallest value that an
>administrator could conceivably set for a particular user.  If the
>intent is the former, than this will be problematic for servers that
>are not tightly coupled with their directory, as it effectively forces
>the server to scan a list of all user settings at each log on time.

The intent is to let the client know that the server does permit mail
to be left on the server, and to present a value which is the smallest
which might be set for the user.  This could be the smallest value
currently in use for any user (so only one value per server), or even
the smallest value which the server permits to be set for any user.
This way a client can decide (because the user has told the client to
leave mail on the server for a larger number of days)  if it needs to
reissue CAPA after authenticating and/or warn the user.

>Another minor nit is the wording:
>"If the authentication step negotiates an integrity protection layer,
>the client SHOULD reissue the CAPA command after authenticating to
>check for active down-negotiation attacks."
>
>I'd like to see the wording changed to something like:
>"The client SHOULD reissue the CAPA command after authenticating to
>check for active down-negotiation attacks and to get any per user
>capability settings."

The intent is to not require clients to issue two CAPA commands.  The
client pretty much has to issue one before authenticating, to learn
which SASL mechanisms are supported, but doesn't have to issue on
afterwards, unless the first CAPA reveals that the server supports some
capabilities whose parameters might change after authentication, and
the client needs the most accurate values (it might be able to use the
more general ones), or the client wants to check for down-negotiation
attacks.  A simple client that only uses a few basic SASL mechanisms,
for example, and only needs to know if the server supports TOP, UIDL,
and allows mail to be left on the server, doesn't need to issue two
CAPAs.  (A client which only uses plaintext or APOP could issue only
one CAPA, after authenticating.)

From: "Mike Gahrns (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [Off Topic] Need review for POP3 extension mechanism
Date: Tue, 21 Jul 1998 21:18:19 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BDB527.C46A0970
Content-Type: text/plain;
	charset="iso-8859-1"

I apologize for such a late response, but i have been out of the office for
the last few weeks.

I agree with the others who view this as being a useful draft, and second
the motion that it should go as proposed instead of informational or
experimental.

Although the list has not had a lot of dicussion on it, I know Randy has
been discussing this with various people at venues like the ietf, so it has
been getting review.  My biggest concern was the former LMOS setting allowed
for expiration settings to be based on the command used to acccess the msg,
which Randy has addressed with the new EXPIRE setting.

I do have one minor concern regarding the current wording of the EXPIRE
setting. 

The draft states:
"If the expiration policy might differ per user (that is, the EXPIRE
argument might change after authentication), the server MUST announce in the
AUTHENTICATION state the smallest value which might be used.  The server
should announce the more accurate value in the TRANSACTION state.

It is unclear to me whether the intent of this is to force the server to
keep track of the smallest setting a user currently has set, or if it is for
the server to annouce the smallest value that an administrator could
conceivably set for a particular user.  If the intent is the former, than
this will be problematic for servers that are not tightly coupled with their
directory, as it effectively forces the server to scan a list of all user
settings at each log on time. 

I'll talk to Randy to get clarification, and perhaps come up with some
clarification wording in regards to this.

Another minor nit is the wording:
"If the authentication step negotiates an integrity protection layer, the
client SHOULD reissue the CAPA command after authenticating to check for
active down-negotiation attacks."

I'd like to see the wording changed to something like:
"The client SHOULD reissue the CAPA command after authenticating to check
for active down-negotiation attacks and to get any per user capability
settings."

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Wednesday, July 08, 1998 6:30 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Off Topic] Need review for POP3 extension mechanism

I apologize for an off-topic posting.  
Please send replies to [email-masked], not to the drums or ietf-smtp
lists.

On May 18, a Last Call was issued on for document
draft-gellens-pop3ext-05.txt ,
for Proposed Standard status.  Nobody has commented on the document.  I am 
reluctant to recommend that IESG approve this document without more evidence

of support.

So I'm asking for more review...

Should the document be adopted as is?  Does it need more wordsmithing?
Are all of these capabilities needed?
Are all of the capabilities defined with sufficient precision?

Should the document be standards track or should it be Informational or 
Experimental?

Should the extension mechanism be separated from (and perhaps a different 
status from) the extensions themselves?

If the document is approved for Proposed, should all of the proposed
extensions 
be included?  Or should some of the extensions be moved to a separate 
Informational or Experimental?   Which ones?

In the absence of more community input, my recommendation would be to direct
the authors to remove all of the capabilities from this document, except
those 
which are already defined in standards-track documents.  Additional
capabilities 
could be defined in a separate experimental or informational RFC.

thanks!

Keith Moore
APPS co-AD

------_=_NextPart_001_01BDB527.C46A0970
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: [Off Topic] Need review for POP3 extension mechanism</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I apologize for such a late response, but i have been =
out of the office for the last few weeks.</FONT>
</P>

<P><FONT SIZE=3D2>I agree with the others who view this as being a =
useful draft, and second the motion that it should go as proposed =
instead of informational or experimental.</FONT></P>

<P><FONT SIZE=3D2>Although the list has not had a lot of dicussion on =
it, I know Randy has been discussing this with various people at venues =
like the ietf, so it has been getting review.&nbsp; My biggest concern =
was the former LMOS setting allowed for expiration settings to be based =
on the command used to acccess the msg, which Randy has addressed with =
the new EXPIRE setting.</FONT></P>

<P><FONT SIZE=3D2>I do have one minor concern regarding the current =
wording of the EXPIRE setting. </FONT>
</P>

<P><FONT SIZE=3D2>The draft states:</FONT>
<BR><FONT SIZE=3D2>&quot;If the expiration policy might differ per user =
(that is, the EXPIRE argument might change after authentication), the =
server MUST announce in the AUTHENTICATION state the smallest value =
which might be used.&nbsp; The server should announce the more accurate =
value in the TRANSACTION state.</FONT></P>

<P><FONT SIZE=3D2>It is unclear to me whether the intent of this is to =
force the server to keep track of the smallest setting a user currently =
has set, or if it is for the server to annouce the smallest value that =
an administrator could conceivably set for a particular user.&nbsp; If =
the intent is the former, than this will be problematic for servers =
that are not tightly coupled with their directory, as it effectively =
forces the server to scan a list of all user settings at each log on =
time. </FONT></P>

<P><FONT SIZE=3D2>I'll talk to Randy to get clarification, and perhaps =
come up with some clarification wording in regards to this.</FONT>
</P>

<P><FONT SIZE=3D2>Another minor nit is the wording:</FONT>
<BR><FONT SIZE=3D2>&quot;If the authentication step negotiates an =
integrity protection layer, the client SHOULD reissue the CAPA command =
after authenticating to check for active down-negotiation =
attacks.&quot;</FONT></P>

<P><FONT SIZE=3D2>I'd like to see the wording changed to something =
like:</FONT>
<BR><FONT SIZE=3D2>&quot;The client SHOULD reissue the CAPA command =
after authenticating to check for active down-negotiation attacks and =
to get any per user capability settings.&quot;</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Keith Moore [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, July 08, 1998 6:30 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: [Off Topic] Need review for POP3 extension =
mechanism</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I apologize for an off-topic posting.&nbsp; </FONT>
<BR><FONT SIZE=3D2>Please send replies to [email-masked], not to =
the drums or ietf-smtp lists.</FONT>
</P>

<P><FONT SIZE=3D2>On May 18, a Last Call was issued on for document =
draft-gellens-pop3ext-05.txt ,</FONT>
<BR><FONT SIZE=3D2>for Proposed Standard status.&nbsp; Nobody has =
commented on the document.&nbsp; I am </FONT>
<BR><FONT SIZE=3D2>reluctant to recommend that IESG approve this =
document without more evidence </FONT>
<BR><FONT SIZE=3D2>of support.</FONT>
</P>

<P><FONT SIZE=3D2>So I'm asking for more review...</FONT>
</P>

<P><FONT SIZE=3D2>Should the document be adopted as is?&nbsp; Does it =
need more wordsmithing?</FONT>
<BR><FONT SIZE=3D2>Are all of these capabilities needed?</FONT>
<BR><FONT SIZE=3D2>Are all of the capabilities defined with sufficient =
precision?</FONT>
</P>

<P><FONT SIZE=3D2>Should the document be standards track or should it =
be Informational or </FONT>
<BR><FONT SIZE=3D2>Experimental?</FONT>
</P>

<P><FONT SIZE=3D2>Should the extension mechanism be separated from (and =
perhaps a different </FONT>
<BR><FONT SIZE=3D2>status from) the extensions themselves?</FONT>
</P>

<P><FONT SIZE=3D2>If the document is approved for Proposed, should all =
of the proposed extensions </FONT>
<BR><FONT SIZE=3D2>be included?&nbsp; Or should some of the extensions =
be moved to a separate </FONT>
<BR><FONT SIZE=3D2>Informational or Experimental?&nbsp;&nbsp; Which =
ones?</FONT>
</P>

<P><FONT SIZE=3D2>In the absence of more community input, my =
recommendation would be to direct</FONT>
<BR><FONT SIZE=3D2>the authors to remove all of the capabilities from =
this document, except those </FONT>
<BR><FONT SIZE=3D2>which are already defined in standards-track =
documents.&nbsp; Additional capabilities </FONT>
<BR><FONT SIZE=3D2>could be defined in a separate experimental or =
informational RFC.</FONT>
</P>

<P><FONT SIZE=3D2>thanks!</FONT>
</P>

<P><FONT SIZE=3D2>Keith Moore</FONT>
<BR><FONT SIZE=3D2>APPS co-AD</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BDB527.C46A0970--

Date: Fri, 10 Jul 1998 10:56:05 -0700
To: [email-masked], [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: 8BITMIME to 7BIT
Sender: [email-masked]

A discussion started over on the international mail list, but the question
I had seemed more appropriate for ietf-smtp and ietf-822. I've Bcc'ed the
international mail list.

On 7/8/98 at 7:21 PM -0700, Ned Freed wrote:

>You have to check for and make sure not to change anything within a
>multipart/signed. (Multipart/encrypted is a nonissue, as the entire part is
>encoded.) If the multipart/signed contains 8bit I currently default to sending
>it through untouched, which of course is technically illegal but works often
>enough that it rarely results in a problem. I also support configurations
>where
>the signature is simply removed in such cases, either with or without an
>attempt to verify.
>...
>Note, however, that the contents of multipart/signed are supposed to be
>7bit-friendly when multipart/signed is used with potentially 7bit-only
>transports like SMTP. Unfortunately clients exist that botch this.

So I was thinking: Would it be reasonable for us to create a field for the
signature sort of like:

        Content-Signed-Part-Encoding: 8bit

which would indicate the CTE used to compute the signature? That way, if an
MTA does downgrade a message, the signature can still be verified because
you can always recover the original content after a downgrade.

The rule for gateways would be: When downgrading a multipart/signed which
already has a Content-Signed-Part-Encoding, preserve that field exactly as
it was. If there is no Content-Signed-Part-Encoding, add one.

Anyone who's currently following the rules and sending 7bit encodings would
still be fine. Anyone who's breaking the rules and sending 8bit or binary
encodings without any labeling may get some help during the downgrade. The
only problem's going to be recipients who can't verify the signature
because they don't recognize to upgrade back to the CSPE, but there was
some chance that those would fail anyway because the originator sent 8bit
blindy in the first place.

Comments?

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

To: [email-masked], [email-masked]
Subject: [Off Topic] Need review for POP3 extension mechanism
cc: [email-masked], [email-masked]
From: Keith Moore <[email-masked]>
Reply-To: [email-masked]
Date: Wed, 08 Jul 1998 21:30:01 -0400
Sender: [email-masked]

I apologize for an off-topic posting.  
Please send replies to [email-masked], not to the drums or ietf-smtp lists.

On May 18, a Last Call was issued on for document draft-gellens-pop3ext-05.txt ,
for Proposed Standard status.  Nobody has commented on the document.  I am 
reluctant to recommend that IESG approve this document without more evidence 
of support.

So I'm asking for more review...

Should the document be adopted as is?  Does it need more wordsmithing?
Are all of these capabilities needed?
Are all of the capabilities defined with sufficient precision?

Should the document be standards track or should it be Informational or 
Experimental?

Should the extension mechanism be separated from (and perhaps a different 
status from) the extensions themselves?

If the document is approved for Proposed, should all of the proposed extensions 
be included?  Or should some of the extensions be moved to a separate 
Informational or Experimental?   Which ones?

In the absence of more community input, my recommendation would be to direct
the authors to remove all of the capabilities from this document, except those 
which are already defined in standards-track documents.  Additional capabilities 
could be defined in a separate experimental or informational RFC.

thanks!

Keith Moore
APPS co-AD