Subject: Re: POP handling commands given in wrong state
From: Mykyta Yevstifeyev <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Paul Smith <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>
Date: Sat, 30 Jul 2011 12:38:10 +0300
List-Id: <ietf-pop3ext.imc.org>

29.07.2011 17:21, Chris Newman wrote:
> --On July 29, 2011 7:04:36 +0300 Mykyta Yevstifeyev 
> <[email-masked]> wrote:
>> I would really be happy if existing POP-over-TLS implementations adhered
>> usual POP behavior as defined in RFC 1939, and I would be happy to
>> describe it in the corresponding document.  However, if we want to 
>> define
>> the current practices, we should document the technology as-is.  If we
>> want to give POP-over-TLs a standard definition of operations, I don't
>> really think those implementation which used the discussed POP-over-TLS
>> algorithm will break their behavior.
>
> We have a choice to define POPS-with-client-certs based on what has 
> been deployed or define it based on how we think it should work. The 
> latter is an architecturally cleaner choice, but is unlikely to cause 
> the deployed implementations with the former behavior to change.

I actually have the same opinion, but in order to suit RFC 1939 
requirements, I think defining the mandatory use of SASL EXTERNAL 
mechanism after TLS-authenticated POP-over-TLS session establishment 
should resolve the issue.  Even if the server has authenticated the user 
upon TLS negotiation, formal authentication with RFC 5034 AUTH command 
using EXTERNAL mechanism will be obligatory to be preformed.

>
>> The "discouragement" of RFC 2595 actually has no considerable reasons.
>
> I disagree. I happen to support documenting POPS because I believe 
> people will continue to use it as they do today regardless of what 
> anyone thinks should be done, and I'd like our documents to give 
> accurate guidance for interoperability as long as it's possible and 
> what's deployed is not egregiously broken. I consider POP+STLS a 
> superior architecture that is cleaner are more interoperable and 
> consider it preferable to pops in almost all cases. I believe section 
> 7 of RFC 2595 remains largely correct today, but accept those 
> arguments are not sufficiently compelling to prevent deployment of 
> pops, so I'd prefer to document pops for interoperability reasons 
> despite its flawed architecture.

I also agree that STLS is a bit better that currently deployed 
POP-over-TLS, so we both concur here.

>
>> Those reasons mentioned in Section 7 of RFC 2595 concern that (1) ports
>> are limited resource, (2) new URI scheme needed, (3) there might be
>> confusion of users, (4) choose "to use or not to use POP-over-TLS" is
>> worse than "use TLS when possible, and negotiate it with STLS".
>> Regarding these points, I should say: (1) isn't a problem now; moreover,
>> 995 port number is already assigned,
>
> IPv4 address space is not a problem right now, either. But that does 
> not mean it will never be a problem and it's OK to unnecessarily waste 
> that resource. But port 995 is registered and won't go away, so I 
> grant that part of your point.

Well, RFC-to-be-6335 discourages use of separate port for "secure" 
versions of protocols, encouraging use of such technologies as STLS in 
POP or Upgrade: TLS in HTTP; so does it for service names.  However, as 
995 port number was assigned long before yet-unpublished RFC 6335 even 
was planned, this is just the matter of history.

>
>> (2) new URI scheme isn't a problem, too; http/https schemes illustrate 
> this as well,
>
> I disagree. Are you sure in all cases when you need to use http: and 
> when you need to use https:? Do you ever enter sensitive data into a 
> web page when "http:" is in the address bar? Are you sure that's safe? 
> If you're an ISP would you prefer to give your users just an email 
> address and password (RFC 6186), an email address and pop server (POP 
> + STLS) or an email address and pop URL (pop, pops). I'd say the 
> latter is the least desirable of these choices as it will result in 
> the most transcription errors and support calls.

The new URI scheme is hypothetical only; the existing 'pop' URI scheme 
isn't meant to be widely-deployed as well, (as the author of RFC 2384 
claimed).  Should there be such need, though, the new URI scheme will be 
very easy to define.  (Actually, the initial idea which led to defining 
POP-over-TLS was 'pops' URI scheme - 
http://tools.ietf.org/html/draft-yevstifeyev-pops-uri-scheme.)

>
>> (3) currently, the users
>> don't usually set use of POP-over-TLS due to their willing, but rather
>> because this is how the user agent should be configured to match the
>> server, as server's administration points the user to do, and
>
> It intrudes into the UI forcing end-users to make choices related to 
> security they may not understand. That problem can be worked around 
> with an extra level of complexity such as that provided by RFC 6186, 
> but it is still an architectural design error.
>
>> (4) is eliminated when the server (server's administration) clearly 
> states that
>> POP-over-TLS should or should not be used.  POP-over-TLS isn't worse 
>> that
>> STLS.
>
> I am not convinced. The correct model is for clients to be 
> secure-by-default without the need for any statement from server 
> administration or any configuration by client users. That is, the 
> first time I run a mail client against a new server it will 
> "permanently latch on" SSL/TLS for that account if it is available (in 
> the event SSL/TLS is not available, the client should confirm with the 
> user that an insecure connection to that server is acceptable). This 
> can be done via RFC 6186 for servers that offer both POP and POPS and 
> can also be done for POP-with-STLS. It's faster and easier to code in 
> the latter case.

Secure-by-default is an ideal variant; but I don't think most of 
existing user agents have such behavior.  Nor do the servers; many of 
them allow to specify whether secure POP should be used.  Moreover, RFC 
6186 was published very recently, in March 2011, and currently I don't 
see it has already gained widespread deployment.

Mykyta

>
>         - Chris
>
>

Date: Fri, 29 Jul 2011 10:21:28 -0400
From: Chris Newman <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>, Paul Smith <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

--On July 29, 2011 7:04:36 +0300 Mykyta Yevstifeyev <[email-masked]> 
wrote:
> I would really be happy if existing POP-over-TLS implementations adhered
> usual POP behavior as defined in RFC 1939, and I would be happy to
> describe it in the corresponding document.  However, if we want to define
> the current practices, we should document the technology as-is.  If we
> want to give POP-over-TLs a standard definition of operations, I don't
> really think those implementation which used the discussed POP-over-TLS
> algorithm will break their behavior.

We have a choice to define POPS-with-client-certs based on what has been 
deployed or define it based on how we think it should work. The latter is 
an architecturally cleaner choice, but is unlikely to cause the deployed 
implementations with the former behavior to change.

> The "discouragement" of RFC 2595 actually has no considerable reasons.

I disagree. I happen to support documenting POPS because I believe people 
will continue to use it as they do today regardless of what anyone thinks 
should be done, and I'd like our documents to give accurate guidance for 
interoperability as long as it's possible and what's deployed is not 
egregiously broken. I consider POP+STLS a superior architecture that is 
cleaner are more interoperable and consider it preferable to pops in almost 
all cases. I believe section 7 of RFC 2595 remains largely correct today, 
but accept those arguments are not sufficiently compelling to prevent 
deployment of pops, so I'd prefer to document pops for interoperability 
reasons despite its flawed architecture.

> Those reasons mentioned in Section 7 of RFC 2595 concern that (1) ports
> are limited resource, (2) new URI scheme needed, (3) there might be
> confusion of users, (4) choose "to use or not to use POP-over-TLS" is
> worse than "use TLS when possible, and negotiate it with STLS".
> Regarding these points, I should say: (1) isn't a problem now; moreover,
> 995 port number is already assigned,

IPv4 address space is not a problem right now, either. But that does not 
mean it will never be a problem and it's OK to unnecessarily waste that 
resource. But port 995 is registered and won't go away, so I grant that 
part of your point.

> (2) new URI scheme isn't a problem, too; http/https schemes illustrate 
this as well,

I disagree. Are you sure in all cases when you need to use http: and when 
you need to use https:? Do you ever enter sensitive data into a web page 
when "http:" is in the address bar? Are you sure that's safe? If you're an 
ISP would you prefer to give your users just an email address and password 
(RFC 6186), an email address and pop server (POP + STLS) or an email 
address and pop URL (pop, pops). I'd say the latter is the least desirable 
of these choices as it will result in the most transcription errors and 
support calls.

> (3) currently, the users
> don't usually set use of POP-over-TLS due to their willing, but rather
> because this is how the user agent should be configured to match the
> server, as server's administration points the user to do, and

It intrudes into the UI forcing end-users to make choices related to 
security they may not understand. That problem can be worked around with an 
extra level of complexity such as that provided by RFC 6186, but it is 
still an architectural design error.

> (4) is eliminated when the server (server's administration) clearly 
states that
> POP-over-TLS should or should not be used.  POP-over-TLS isn't worse that
> STLS.

I am not convinced. The correct model is for clients to be 
secure-by-default without the need for any statement from server 
administration or any configuration by client users. That is, the first 
time I run a mail client against a new server it will "permanently latch 
on" SSL/TLS for that account if it is available (in the event SSL/TLS is 
not available, the client should confirm with the user that an insecure 
connection to that server is acceptable). This can be done via RFC 6186 for 
servers that offer both POP and POPS and can also be done for 
POP-with-STLS. It's faster and easier to code in the latter case.

		- Chris

Date: Fri, 29 Jul 2011 07:04:36 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

Paul,

I would really be happy if existing POP-over-TLS implementations adhered 
usual POP behavior as defined in RFC 1939, and I would be happy to 
describe it in the corresponding document.  However, if we want to 
define the current practices, we should document the technology as-is.  
If we want to give POP-over-TLs a standard definition of operations, I 
don't really think those implementation which used the discussed 
POP-over-TLS algorithm will break their behavior.

The "discouragement" of RFC 2595 actually has no considerable reasons.  
Those reasons mentioned in Section 7 of RFC 2595 concern that (1) ports 
are limited resource, (2) new URI scheme needed, (3) there might be 
confusion of users, (4) choose "to use or not to use POP-over-TLS" is 
worse than "use TLS when possible, and negotiate it with STLS".  
Regarding these points, I should say: (1) isn't a problem now; moreover, 
995 port number is already assigned, (2) new URI scheme isn't a problem, 
too; http/https schemes illustrate this as well, (3) currently, the 
users don't usually set use of POP-over-TLS due to their willing, but 
rather because this is how the user agent should be configured to match 
the server, as server's administration points the user to do, and (4) is 
eliminated when the server (server's administration) clearly states that 
POP-over-TLS should or should not be used.  POP-over-TLS isn't worse 
that STLS.

Regarding how POP-over-TLS session is set up.  The first variant is 
simple, and has no concerns.  I mean (1) TCP connection --> (2) TLS 
negotiation --> (3) USER-PASS/AUTH authentication -> (4) POP 
transaction.  This adheres the usual RFC 1939 definition and seems not 
to have any problems.

The second variant is the most fishy.  I mean (1) TCP connection --> (2) 
TLS negotiation, which stands for POP authorization --> (3a) 
USER-PASS/AUTH authentication, if (2) fails/ (3b) or, alternatively, use 
SASL EXTERNAL mechnism --> (4) POP transaction.  This algorithm violates 
RFC 1939, but it is a willful violation, if we don't consider (3b).  
Replacing some of required POP steps with TLS steps may be considered to 
lead to a new protocol.  Regarding the SASL EXTERNAL mechanism, I 
actually think it's appropriate to be used use, but the question - 
whether servers will also begin to use it?

Mykyta

27.07.2011 11:49, Paul Smith wrote:
> On 27/07/2011 05:57, Mykyta Yevstifeyev wrote:
>>> Hmm, I think if you are talking about existing implementations using 
>>> a deprecated system, then trying to alter the behaviour of them is 
>>> unlikely to achieve anything...
>> I wouldn't say it is deprecated; POP-over-TLS is used even more often 
>> that STLS, as I've already mentioned.  We're trying to give it the 
>> official documentation and set the standard behavior of the 
>> server/client.
>
> It is 'discouraged' then. Also, because, as of now, there is no 
> standards track document saying how POP3-over-TLS should work, I think 
> you can safely call it non-standard. Non-standard + 'discouraged' + a 
> better standardised option = seems to suggest that no one should be 
> starting to use that system now... There is no good reason to use 
> POP3-over-TLS instead of STLS, so I think it needs to be made clear 
> that POP3-over-TLS is second-best compared to STLS (as someone who's 
> implemented both, I found STLS a lot easier than POP3-over-TLS to 
> implement).
>
> If you are trying to specify what future servers who want to use this 
> 'discouraged' system should do, then simply say they must start up in 
> the authorization stage after the TLS session has been started (just 
> as with STLS). Anything else is too far from the POP3 standard, and as 
> Randall said 'magic'.
>
> I am not aware of any 'well known' POP3 clients which will skip the 
> authorization stage, so any server which requires this must just be 
> used for 'internal' use, and thus not really relevant for standards. 
> Internal use servers can do anything they want so these aren't doing 
> 'POP3-over-TLS', they're doing 'almost-POP3-over-TLS' which is fine 
> for internal use.
>
> The only reason to do a POP3-over-TLS implementation nowadays should 
> be to allow compatibility with some popular old software which doesn't 
> support STLS. AFAIK, that is essentially old versions of 
> Outlook/Outlook Express - those use USER/PASS after connecting over TLS.
>
> I strongly feel that the POP3 session should start in the 
> authorization stage, as understood by everyone who uses a standardised 
> POP3 service (ie one where the developer has read RFC 1939). So, 
> USER/AUTH/APOP is needed as one of the first commands after connecting.
>
> As Randall suggested, use SASL EXTERNAL if you want (isn't this the 
> whole point of SASL EXTERNAL?), but you should need an AUTH. What's 
> the problem with needing that?
>
>> In our case the AUTHORIZATION is safely replaced by TLS negotiation.  
>> It also happens directly after TCP connection, but skipping the 
>> greeting, which is replaced by TLS ServerHello message.
> Which is breaking the POP3 standard, because the greeting is specified 
> as a 'one line [text] greeting'
>
>>> If you are just wanting to document existing behaviour, then this 
>>> doesn't matter, as neither the extended response nor standard 
>>> compliant behaviour is possible.
>> But if we try to unify all existing behavior, this will be great, 
>> won't it?
>
> Well, what would be great IMHO would be to destroy all POP3-over-TLS 
> implementations... They should never have been done in the first place!
>
> But, failing that, it's fairly obvious the 'most correct' 
> implementation is to do it as Gmail, Thunderbird, etc, etc have done, 
> and have it as normal RFC 1939 but with a TLS 'wrapper' around the 
> session.
>
> The 'broken' implementation of not needing AUTH after session 
> establishment is the one that needs to be fixed somehow. Either you 
> kludge it by having some mechanism that the client needs to understand 
> for the server to say 'I'm in the wrong state now', or you fix it 
> properly by having the server enter AUTHORIZATION state.
>
>
>
>

Date: Wed, 27 Jul 2011 09:49:53 +0100
From: Paul Smith <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>
CC: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

On 27/07/2011 05:57, Mykyta Yevstifeyev wrote:
>> Hmm, I think if you are talking about existing implementations using 
>> a deprecated system, then trying to alter the behaviour of them is 
>> unlikely to achieve anything...
> I wouldn't say it is deprecated; POP-over-TLS is used even more often 
> that STLS, as I've already mentioned.  We're trying to give it the 
> official documentation and set the standard behavior of the server/client.

It is 'discouraged' then. Also, because, as of now, there is no 
standards track document saying how POP3-over-TLS should work, I think 
you can safely call it non-standard. Non-standard + 'discouraged' + a 
better standardised option = seems to suggest that no one should be 
starting to use that system now... There is no good reason to use 
POP3-over-TLS instead of STLS, so I think it needs to be made clear that 
POP3-over-TLS is second-best compared to STLS (as someone who's 
implemented both, I found STLS a lot easier than POP3-over-TLS to 
implement).

If you are trying to specify what future servers who want to use this 
'discouraged' system should do, then simply say they must start up in 
the authorization stage after the TLS session has been started (just as 
with STLS). Anything else is too far from the POP3 standard, and as 
Randall said 'magic'.

I am not aware of any 'well known' POP3 clients which will skip the 
authorization stage, so any server which requires this must just be used 
for 'internal' use, and thus not really relevant for standards. Internal 
use servers can do anything they want so these aren't doing 
'POP3-over-TLS', they're doing 'almost-POP3-over-TLS' which is fine for 
internal use.

The only reason to do a POP3-over-TLS implementation nowadays should be 
to allow compatibility with some popular old software which doesn't 
support STLS. AFAIK, that is essentially old versions of Outlook/Outlook 
Express - those use USER/PASS after connecting over TLS.

I strongly feel that the POP3 session should start in the authorization 
stage, as understood by everyone who uses a standardised POP3 service 
(ie one where the developer has read RFC 1939). So, USER/AUTH/APOP is 
needed as one of the first commands after connecting.

As Randall suggested, use SASL EXTERNAL if you want (isn't this the 
whole point of SASL EXTERNAL?), but you should need an AUTH. What's the 
problem with needing that?

> In our case the AUTHORIZATION is safely replaced by TLS negotiation.  
> It also happens directly after TCP connection, but skipping the 
> greeting, which is replaced by TLS ServerHello message.
Which is breaking the POP3 standard, because the greeting is specified 
as a 'one line [text] greeting'

>> If you are just wanting to document existing behaviour, then this 
>> doesn't matter, as neither the extended response nor standard 
>> compliant behaviour is possible.
> But if we try to unify all existing behavior, this will be great, 
> won't it?

Well, what would be great IMHO would be to destroy all POP3-over-TLS 
implementations... They should never have been done in the first place!

But, failing that, it's fairly obvious the 'most correct' implementation 
is to do it as Gmail, Thunderbird, etc, etc have done, and have it as 
normal RFC 1939 but with a TLS 'wrapper' around the session.

The 'broken' implementation of not needing AUTH after session 
establishment is the one that needs to be fixed somehow. Either you 
kludge it by having some mechanism that the client needs to understand 
for the server to say 'I'm in the wrong state now', or you fix it 
properly by having the server enter AUTHORIZATION state.

Date: Wed, 27 Jul 2011 08:05:18 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: Paul Smith <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

26.07.2011 17:35, Randall Gellens wrote:
> At 6:17 AM -0700 7/26/11, Randall Gellens wrote:
>
>>  Per RFC 3206, the server should issue the AUTH-RESP-CODE capability 
>> tag, indicating "that the server includes the AUTH response code with 
>> any authentication error caused by a problem with the user's 
>> credentials" and then in the case you cite, don't issue the AUTH 
>> response code in an -ERR response to USER.
>>
>>  By issuing the AUTH response code and then not including the AUTH 
>> response code, that indicates that the error has nothing to do with 
>> the user's credentials.
>
> Just to be clear, if the server issued AUTH-RESP-CODE, then the result 
> to USER can be interpreted:
>     +OK:            Accepted, proceed to PASS
>     -ERR [AUTH]:        Failed, problem with user credentials (not 
> likely with USER anyway)
>     -ERR [SYS/TEMP]:    Failed due to temporary system problem, try 
> again later
>     -ERR [SYS/PERM]:    Failed due to permanent system problem, advise 
> user to call for help
>     -ERR:                No problem w/ credentials nor system, if you 
> used TLS w/ cert, maybe authenticated already
This is an interesting idea.  We can also define the new code, AUTH-YET, 
to answer USER/PASS/AUTH given when already authenticated:

         -ERR [AUTH-YET]:      Already authenticated
         -ERR:                            Other error.

The initially proposed WRONG-STATE can be a generalization of the 
aforementioned AUTH-YET, eg.

C: STAT
S: -ERR [WRONG-STATE/AUTHORIZATION] Not authenticated yet; current state 
is AUTHORIZATION
---
C: <authenticates itself>
C: USER foo
S: -ERR [WRONG-STATE/TRANSACTION] Already in TRANSACTION.
---
etc.

Mykyta
>
>

Date: Wed, 27 Jul 2011 07:57:11 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030708020903000000070100
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

26.07.2011 16:32, Paul Smith wrote:
> On 26/07/2011 14:19, Mykyta Yevstifeyev wrote:
>>> Going straight from session establishment into transaction state 
>>> seems wrong to me, given the base POP3 spec which POP3-over-TLS is 
>>> building on.
>> The matter is that many POP servers support authentication using 
>> X.509 certificate which was supplied during TLS negotiation and do 
>> not require further authentication.  In such case issuing USER will 
>> lead to -ERR, as the server is already in TRANSACTION then.  Other 
>> servers implement POP-over-TLS so that further authentication is also 
>> required (eg. Gmail, which I personally am using).
>>
>>>
>>>
>>> BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete 
>>> - isn't the 'STLS' command (RFC 2595) the way we should be doing 
>>> things now? I thought the POP3S way was deprecated.
>>>
>>> Note that the RFC 2595 says:
>>> "The STLS command is only permitted in AUTHORIZATION state and the 
>>> server remains in AUTHORIZATION state, even if client credentials 
>>> are supplied during the TLS negotiation." so with STLS you have to 
>>> authenticate (not sure why it's called 'authorization' state when 
>>> it's really 'authentication' state, but that's not relevant) even if 
>>> the TLS has already supplied the user details.
>> Yes, RFC 2595 discouraged use of POP-over-TLS.  However, it is now 
>> used even wider than STLS, which led to effort to document this 
>> mode.  See above for note on why authorization might not be necessary 
>> after TLS negotiation.
>
> Hmm, I think if you are talking about existing implementations using a 
> deprecated system, then trying to alter the behaviour of them is 
> unlikely to achieve anything...
I wouldn't say it is deprecated; POP-over-TLS is used even more often 
that STLS, as I've already mentioned.  We're trying to give it the 
official documentation and set the standard behavior of the server/client.
>
> Personally, I'd say that a POP3 server that skips the authorization 
> state because of the certificate is not standards compliant, because 
> there is no standard which allows that behaviour.
>
> RFC 1939 section 3 says "Once the TCP connection has been opened and 
> the POP3 server has sent the greeting, the session enters the 
> AUTHORIZATION state. In this state, the client must identify itself to 
> the POP3 server."
In our case the AUTHORIZATION is safely replaced by TLS negotiation.  It 
also happens directly after TCP connection, but skipping the greeting, 
which is replaced by TLS ServerHello message.
>
> Potentially, the client could identify itself using the certificate - 
> HOWEVER, this has to happen *after the POP3 server has sent the 
> greeting* for it to be standards compliant, so it can't be done using 
> the certificate with POP3-over-TLS (it could have been, using the STLS 
> extension, except that specifically excludes that option)
This assumes use of STLS, which performs TLS negotiation during POP3 
session.  POP-over-TLS deliberately makes use of TLS before POP session.
>
> So, any server which does not enter AUTHORIZATION state after the 
> connection has been opened and the POP3 server has sent the greeting 
> is NOT RFC 1939 compliant.
See above.  Server greeting = ServerHello TLS message; authentication = 
TLS negotiation.
>
> If you are wanting to change the behaviour of existing POP3-over-TLS 
> server implementations so they send a POP3 extended response, then you 
> should rather change their behaviour so they are compliant to the 
> existing RFC 1939 instead...
They can't be anyway as some required steps of RFC 1939 are replaced by 
TLS steps.  This results in a modified protocol.
>
> If you are just wanting to document existing behaviour, then this 
> doesn't matter, as neither the extended response nor standard 
> compliant behaviour is possible.
But if we try to unify all existing behavior, this will be great, won't it?

Mykyta Yevstifeyev
>
> IMHO
>
>
>

--------------030708020903000000070100
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    26.07.2011 16:32, Paul Smith wrote:
    <blockquote cite="mid:[email-masked]" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      On 26/07/2011 14:19, Mykyta Yevstifeyev wrote:
      <blockquote cite="mid:[email-masked]" type="cite">
        <blockquote cite="mid:[email-masked]" type="cite">
          Going straight from session establishment into transaction
          state seems wrong to me, given the base POP3 spec which
          POP3-over-TLS is building on.<br>
        </blockquote>
        The matter is that many POP servers support authentication using
        X.509 certificate which was supplied during TLS negotiation and
        do not require further authentication.  In such case issuing
        USER will lead to -ERR, as the server is already in TRANSACTION
        then.  Other servers implement POP-over-TLS so that further
        authentication is also required (eg. Gmail, which I personally
        am using).<br>
        <br>
        <blockquote cite="mid:[email-masked]" type="cite">
          <br>
          <br>
          BTW - why are you looking at POP3-over-TLS? Isn't this idea
          obsolete - isn't the 'STLS' command (RFC 2595) the way we
          should be doing things now? I thought the POP3S way was
          deprecated.<br>
          <br>
          Note that the RFC 2595 says:<br>
          "The STLS command is only permitted in AUTHORIZATION state and
          the server remains in AUTHORIZATION state, even if client
          credentials are supplied during the TLS negotiation." so with
          STLS you have to authenticate (not sure why it's called
          'authorization' state when it's really 'authentication' state<span
            class="Apple-style-span" style="border-collapse: separate;
            color: rgb(0, 0, 0); font-family: 'Times New Roman';
            font-style: normal; font-variant: normal; font-weight:
            normal; letter-spacing: normal; line-height: normal;
            orphans: 2; text-indent: 0px; text-transform: none;
            white-space: normal; widows: 2; word-spacing: 0px;
            font-size: medium;"><span class="Apple-style-span"
              style="color: rgb(46, 44, 44); font-family: Georgia,'Times
              New Roman',Times,serif; font-size: 15px; line-height:
              22px;"></span></span>, but that's not relevant) even if
          the TLS has already supplied the user details.<br>
        </blockquote>
        Yes, RFC 2595 discouraged use of POP-over-TLS.  However, it is
        now used even wider than STLS, which led to effort to document
        this mode.  See above for note on why authorization might not be
        necessary after TLS negotiation.<br>
      </blockquote>
      <br>
      Hmm, I think if you are talking about existing implementations
      using a deprecated system, then trying to alter the behaviour of
      them is unlikely to achieve anything...<br>
    </blockquote>
    I wouldn't say it is deprecated; POP-over-TLS is used even more
    often that STLS, as I've already mentioned.  We're trying to give it
    the official documentation and set the standard behavior of the
    server/client.<br>
    <blockquote cite="mid:[email-masked]" type="cite"> <br>
      Personally, I'd say that a POP3 server that skips the
      authorization state because of the certificate is not standards
      compliant, because there is no standard which allows that
      behaviour.<br>
      <br>
      RFC 1939 section 3 says "Once the TCP connection has been opened
      and the POP3 server has sent the greeting, the session enters the
      AUTHORIZATION state. In this state, the client must identify
      itself to the POP3 server.<span class="Apple-style-span"
        style="border-collapse: separate; color: rgb(0, 0, 0);
        font-family: 'Times New Roman'; font-style: normal;
        font-variant: normal; font-weight: normal; letter-spacing:
        normal; line-height: normal; orphans: 2; text-indent: 0px;
        text-transform: none; white-space: normal; widows: 2;
        word-spacing: 0px; font-size: medium;"></span><span
        class="Apple-style-span" style="border-collapse: separate;
        color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style:
        normal; font-variant: normal; font-weight: normal;
        letter-spacing: normal; line-height: normal; orphans: 2;
        text-indent: 0px; text-transform: none; white-space: normal;
        widows: 2; word-spacing: 0px; font-size: medium;"></span>"<br>
    </blockquote>
    In our case the AUTHORIZATION is safely replaced by TLS
    negotiation.  It also happens directly after TCP connection, but
    skipping the greeting, which is replaced by TLS ServerHello message.<br>
    <blockquote cite="mid:[email-masked]" type="cite"> <br>
      Potentially, the client could identify itself using the
      certificate - HOWEVER, this has to happen *after the POP3 server
      has sent the greeting* for it to be standards compliant, so it
      can't be done using the certificate with POP3-over-TLS (it could
      have been, using the STLS extension, except that specifically
      excludes that option)<br>
    </blockquote>
    This assumes use of STLS, which performs TLS negotiation during POP3
    session.  POP-over-TLS deliberately makes use of TLS before POP
    session.<br>
    <blockquote cite="mid:[email-masked]" type="cite"> <br>
      So, any server which does not enter AUTHORIZATION state after the
      connection has been opened and the POP3 server has sent the
      greeting is NOT RFC 1939 compliant. <br>
    </blockquote>
    See above.  Server greeting = ServerHello TLS message;
    authentication = TLS negotiation.<br>
    <blockquote cite="mid:[email-masked]" type="cite"> <br>
      If you are wanting to change the behaviour of existing
      POP3-over-TLS server implementations so they send a POP3 extended
      response, then you should rather change their behaviour so they
      are compliant to the existing RFC 1939 instead...<br>
    </blockquote>
    They can't be anyway as some required steps of RFC 1939 are replaced
    by TLS steps.  This results in a modified protocol.<br>
    <blockquote cite="mid:[email-masked]" type="cite"> <br>
      If you are just wanting to document existing behaviour, then this
      doesn't matter, as neither the extended response nor standard
      compliant behaviour is possible.<br>
    </blockquote>
    But if we try to unify all existing behavior, this will be great,
    won't it?<br>
    <br>
    Mykyta Yevstifeyev<br>
    <blockquote cite="mid:[email-masked]" type="cite"> <br>
      IMHO<br>
      <br>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------030708020903000000070100--

Date: Tue, 26 Jul 2011 11:36:29 -0700
To: Mykyta Yevstifeyev <[email-masked]>, Paul Smith <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: POP handling commands given in wrong state
CC: <[email-masked]>
Sender: [email-masked]

At 4:19 PM +0300 7/26/11, Mykyta Yevstifeyev wrote:

>  The matter is that many POP servers support authentication using 
> X.509 certificate which was supplied during TLS negotiation and do 
> not require further authentication.  In such case issuing USER will 
> lead to -ERR, as the server is already in TRANSACTION then.

Could you use AUTH with SASL EXTERNAL for this case?  Seems a little 
cleaner.  Otherwise it's magic that you don't need AUTH/USER

>   Other servers implement POP-over-TLS so that further 
> authentication is also required (eg. Gmail, which I personally am 
> using).

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of
     Western Civilization?
Gandhi: I think it would be a good idea.

Date: Tue, 26 Jul 2011 07:35:42 -0700
To: Mykyta Yevstifeyev <[email-masked]>, Paul Smith <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: POP handling commands given in wrong state
CC: <[email-masked]>, Alexey Melnikov <[email-masked]>
Sender: [email-masked]

At 6:17 AM -0700 7/26/11, Randall Gellens wrote:

>  Per RFC 3206, the server should issue the AUTH-RESP-CODE capability 
> tag, indicating "that the server includes the AUTH response code 
> with any authentication error caused by a problem with the user's 
> credentials" and then in the case you cite, don't issue the AUTH 
> response code in an -ERR response to USER.
>
>  By issuing the AUTH response code and then not including the AUTH 
> response code, that indicates that the error has nothing to do with 
> the user's credentials.

Just to be clear, if the server issued AUTH-RESP-CODE, then the 
result to USER can be interpreted:
	+OK:			Accepted, proceed to PASS
	-ERR [AUTH]:		Failed, problem with user credentials (not 
likely with USER anyway)
	-ERR [SYS/TEMP]:	Failed due to temporary system problem, try again later
	-ERR [SYS/PERM]:	Failed due to permanent system problem, 
advise user to call for help
	-ERR:				No problem w/ credentials nor system, if you 
used TLS w/ cert, maybe authenticated already

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Too often, we see a failure to distinguish sufficiently clearly
between the intrinsic problems of computer science and the
difficulties resulting from the shortcomings of our various
educational systems.                       --Edsger W. Dijkstra

Date: Tue, 26 Jul 2011 07:30:15 -0700
To: Paul Smith <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: POP handling commands given in wrong state
CC: Mykyta Yevstifeyev <[email-masked]>, <[email-masked]>, Alexey Melnikov <[email-masked]>
Sender: [email-masked]

At 2:35 PM +0100 7/26/11, Paul Smith wrote:

>  On 26/07/2011 14:17, Randall Gellens wrote:
>
>>
>>  Per RFC 4206, the server should issue the AUTH-RESP-CODE 
>> capability tag, indicating "that the server includes the AUTH 
>> response code with any authentication error caused by a problem 
>> with the user's credentials" and then in the case you cite, don't 
>> issue the AUTH response code in an -ERR response to USER.
>>
>
>  Hmm - maybe you have the wrong RFC number there - or I'm missing 
> something in our implementation because our mail server doesn't do 
> anything about "Label Switched Paths (LSP) Hierarchy with 
> Generalized Multi-Protocol Label Switching (GMPLS) Traffic 
> Engineering (TE)"... :)

Sorry about that, slip of the fingers.  It's RFC 3206 (not 4206).

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
See, in my line of work, you got to keep repeating things over and
over and over again for the truth to sink in, to kind of catapult
the propaganda.
        --U.S. President George W. Bush in New York, May 24, 2005

Date: Tue, 26 Jul 2011 14:35:06 +0100
From: Paul Smith <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: Mykyta Yevstifeyev <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------010602000702070802040002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 26/07/2011 14:17, Randall Gellens wrote:
>
> Per RFC 4206, the server should issue the AUTH-RESP-CODE capability 
> tag, indicating "that the server includes the AUTH response code with 
> any authentication error caused by a problem with the user's 
> credentials" and then in the case you cite, don't issue the AUTH 
> response code in an -ERR response to USER.

Hmm - maybe you have the wrong RFC number there - or I'm missing 
something in our implementation because our mail server doesn't do 
anything about "Label Switched Paths (LSP) Hierarchy with Generalized 
Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"... :)

--------------010602000702070802040002
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 26/07/2011 14:17, Randall Gellens wrote:
    <blockquote cite="mid:p0624060cca546d8a1a68@%5B130.129.83.90%5D"
      type="cite"><br>
      Per RFC 4206, the server should issue the AUTH-RESP-CODE
      capability tag, indicating "that the server includes the AUTH
      response code with any authentication error caused by a problem
      with the user's credentials" and then in the case you cite, don't
      issue the AUTH response code in an -ERR response to USER.
      <br>
    </blockquote>
    <br>
    Hmm - maybe you have the wrong RFC number there - or I'm missing
    something in our implementation because our mail server doesn't do
    anything about "Label Switched Paths (LSP) Hierarchy with
    Generalized Multi-Protocol Label Switching (GMPLS) Traffic
    Engineering (TE)<span class="Apple-style-span"
      style="border-collapse: separate; color: rgb(0, 0, 0);
      font-family: 'Times New Roman'; font-style: normal; font-variant:
      normal; font-weight: normal; letter-spacing: normal; line-height:
      normal; orphans: 2; text-indent: 0px; text-transform: none;
      white-space: normal; widows: 2; word-spacing: 0px; font-size:
      medium;"></span>"... :)<br>
    <br>
    <br>
  <br></body>
</html>

--------------010602000702070802040002--

Date: Tue, 26 Jul 2011 14:32:16 +0100
From: Paul Smith <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>
CC: [email-masked]
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------050608030700090309090108
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 26/07/2011 14:19, Mykyta Yevstifeyev wrote:
>> Going straight from session establishment into transaction state 
>> seems wrong to me, given the base POP3 spec which POP3-over-TLS is 
>> building on.
> The matter is that many POP servers support authentication using X.509 
> certificate which was supplied during TLS negotiation and do not 
> require further authentication.  In such case issuing USER will lead 
> to -ERR, as the server is already in TRANSACTION then.  Other servers 
> implement POP-over-TLS so that further authentication is also required 
> (eg. Gmail, which I personally am using).
>
>>
>>
>> BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete 
>> - isn't the 'STLS' command (RFC 2595) the way we should be doing 
>> things now? I thought the POP3S way was deprecated.
>>
>> Note that the RFC 2595 says:
>> "The STLS command is only permitted in AUTHORIZATION state and the 
>> server remains in AUTHORIZATION state, even if client credentials are 
>> supplied during the TLS negotiation." so with STLS you have to 
>> authenticate (not sure why it's called 'authorization' state when 
>> it's really 'authentication' state, but that's not relevant) even if 
>> the TLS has already supplied the user details.
> Yes, RFC 2595 discouraged use of POP-over-TLS.  However, it is now 
> used even wider than STLS, which led to effort to document this mode.  
> See above for note on why authorization might not be necessary after 
> TLS negotiation.

Hmm, I think if you are talking about existing implementations using a 
deprecated system, then trying to alter the behaviour of them is 
unlikely to achieve anything...

Personally, I'd say that a POP3 server that skips the authorization 
state because of the certificate is not standards compliant, because 
there is no standard which allows that behaviour.

RFC 1939 section 3 says "Once the TCP connection has been opened and the 
POP3 server has sent the greeting, the session enters the AUTHORIZATION 
state. In this state, the client must identify itself to the POP3 server."

Potentially, the client could identify itself using the certificate - 
HOWEVER, this has to happen *after the POP3 server has sent the 
greeting* for it to be standards compliant, so it can't be done using 
the certificate with POP3-over-TLS (it could have been, using the STLS 
extension, except that specifically excludes that option)

So, any server which does not enter AUTHORIZATION state after the 
connection has been opened and the POP3 server has sent the greeting is 
NOT RFC 1939 compliant.

If you are wanting to change the behaviour of existing POP3-over-TLS 
server implementations so they send a POP3 extended response, then you 
should rather change their behaviour so they are compliant to the 
existing RFC 1939 instead...

If you are just wanting to document existing behaviour, then this 
doesn't matter, as neither the extended response nor standard compliant 
behaviour is possible.

IMHO

--------------050608030700090309090108
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 26/07/2011 14:19, Mykyta Yevstifeyev wrote:
    <blockquote cite="mid:[email-masked]" type="cite">
      <blockquote cite="mid:[email-masked]" type="cite">
        Going straight from session establishment into transaction state
        seems wrong to me, given the base POP3 spec which POP3-over-TLS
        is building on.<br>
      </blockquote>
      The matter is that many POP servers support authentication using
      X.509 certificate which was supplied during TLS negotiation and do
      not require further authentication.  In such case issuing USER
      will lead to -ERR, as the server is already in TRANSACTION then. 
      Other servers implement POP-over-TLS so that further
      authentication is also required (eg. Gmail, which I personally am
      using).<br>
      <br>
      <blockquote cite="mid:[email-masked]" type="cite"> <br>
        <br>
        BTW - why are you looking at POP3-over-TLS? Isn't this idea
        obsolete - isn't the 'STLS' command (RFC 2595) the way we should
        be doing things now? I thought the POP3S way was deprecated.<br>
        <br>
        Note that the RFC 2595 says:<br>
        "The STLS command is only permitted in AUTHORIZATION state and
        the server remains in AUTHORIZATION state, even if client
        credentials are supplied during the TLS negotiation." so with
        STLS you have to authenticate (not sure why it's called
        'authorization' state when it's really 'authentication' state<span
          class="Apple-style-span" style="border-collapse: separate;
          color: rgb(0, 0, 0); font-family: 'Times New Roman';
          font-style: normal; font-variant: normal; font-weight: normal;
          letter-spacing: normal; line-height: normal; orphans: 2;
          text-indent: 0px; text-transform: none; white-space: normal;
          widows: 2; word-spacing: 0px; font-size: medium;"><span
            class="Apple-style-span" style="color: rgb(46, 44, 44);
            font-family: Georgia,'Times New Roman',Times,serif;
            font-size: 15px; line-height: 22px;"></span></span>, but
        that's not relevant) even if the TLS has already supplied the
        user details.<br>
      </blockquote>
      Yes, RFC 2595 discouraged use of POP-over-TLS.  However, it is now
      used even wider than STLS, which led to effort to document this
      mode.  See above for note on why authorization might not be
      necessary after TLS negotiation.<br>
    </blockquote>
    <br>
    Hmm, I think if you are talking about existing implementations using
    a deprecated system, then trying to alter the behaviour of them is
    unlikely to achieve anything...<br>
    <br>
    Personally, I'd say that a POP3 server that skips the authorization
    state because of the certificate is not standards compliant, because
    there is no standard which allows that behaviour.<br>
    <br>
    RFC 1939 section 3 says "Once the TCP connection has been opened and
    the POP3 server has sent the greeting, the session enters the
    AUTHORIZATION state. In this state, the client must identify itself
    to the POP3 server.<span class="Apple-style-span"
      style="border-collapse: separate; color: rgb(0, 0, 0);
      font-family: 'Times New Roman'; font-style: normal; font-variant:
      normal; font-weight: normal; letter-spacing: normal; line-height:
      normal; orphans: 2; text-indent: 0px; text-transform: none;
      white-space: normal; widows: 2; word-spacing: 0px; font-size:
      medium;"></span><span class="Apple-style-span"
      style="border-collapse: separate; color: rgb(0, 0, 0);
      font-family: 'Times New Roman'; font-style: normal; font-variant:
      normal; font-weight: normal; letter-spacing: normal; line-height:
      normal; orphans: 2; text-indent: 0px; text-transform: none;
      white-space: normal; widows: 2; word-spacing: 0px; font-size:
      medium;"></span>"<br>
    <br>
    Potentially, the client could identify itself using the certificate
    - HOWEVER, this has to happen *after the POP3 server has sent the
    greeting* for it to be standards compliant, so it can't be done
    using the certificate with POP3-over-TLS (it could have been, using
    the STLS extension, except that specifically excludes that option)<br>
    <br>
    So, any server which does not enter AUTHORIZATION state after the
    connection has been opened and the POP3 server has sent the greeting
    is NOT RFC 1939 compliant. <br>
    <br>
    If you are wanting to change the behaviour of existing POP3-over-TLS
    server implementations so they send a POP3 extended response, then
    you should rather change their behaviour so they are compliant to
    the existing RFC 1939 instead...<br>
    <br>
    If you are just wanting to document existing behaviour, then this
    doesn't matter, as neither the extended response nor standard
    compliant behaviour is possible.<br>
    <br>
    IMHO<br>
    <br>
    <br>
  <br></body>
</html>

--------------050608030700090309090108--

Date: Tue, 26 Jul 2011 06:17:24 -0700
To: Mykyta Yevstifeyev <[email-masked]>, Paul Smith <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: POP handling commands given in wrong state
CC: <[email-masked]>, Alexey Melnikov <[email-masked]>
Sender: [email-masked]

At 12:22 PM +0300 7/26/11, Mykyta Yevstifeyev wrote:

>  I meant just the situation like this.  Eg., when one is using 
> POP3-over-TLS whereas TLS connection is established before POP 
> transaction starts, TLS negotiation may be used instead USER-PASS 
> or AUTH authentication, entering the server into the TRANSACTION 
> state; on the other hand, the server may require authentication 
> under TLS layer, entering AUTHORIZATION state after establishing 
> TLS connection.  I and Alexey Melnikov are currently working on the 
> POP-over-TLS specification 
> (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) 
> and the problem is that the client don't know what state is the 
> server in after TLS negotiation.  If the client tries giving USER 
> and received -ERR, it may mean that the user name is unknown or 
> that the user is authenticated already, and the client can't know 
> for sure what does it mean.  Don't you have other idea of 
> indicating the state?

Per RFC 4206, the server should issue the AUTH-RESP-CODE capability 
tag, indicating "that the server includes the AUTH response code with 
any authentication error caused by a problem with the user's 
credentials" and then in the case you cite, don't issue the AUTH 
response code in an -ERR response to USER.

By issuing the AUTH response code and then not including the AUTH 
response code, that indicates that the error has nothing to do with 
the user's credentials.

I agree that you would have to infer that the user is already 
authenticated, which isn't as nice as having an explicit response 
code.  I'm not sure if it's worth adding the explicit tag or not, but 
don't have an objection to it.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Think twice before speaking, but don't say "think think click click".

Date: Tue, 26 Jul 2011 16:19:01 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------040709010300010303090803
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

26.07.2011 12:51, Paul Smith wrote:
> On 26/07/2011 10:22, Mykyta Yevstifeyev wrote:
>> 26.07.2011 11:12, Paul Smith wrote:
>>> On 26/07/2011 05:59, Mykyta Yevstifeyev wrote:
>>>
>>> [ . .  .]
>>>
>>> If the state was server defined, so that it may change on the 
>>> server's decision, rather than by purely bad coding in the client, 
>>> then yes, an extended response code may be useful, but when it is 
>>> only bad coding in the client which can make it happen - no.
>> Paul,
>>
>> [Adding Alexey Melnikov to CC list; see below.]
>>
>> I meant just the situation like this.  Eg., when one is using 
>> POP3-over-TLS whereas TLS connection is established before POP 
>> transaction starts, TLS negotiation may be used instead USER-PASS or 
>> AUTH authentication, entering the server into the TRANSACTION state; 
>> on the other hand, the server may require authentication under TLS 
>> layer, entering AUTHORIZATION state after establishing TLS 
>> connection.  I and Alexey Melnikov are currently working on the 
>> POP-over-TLS specification 
>> (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) and 
>> the problem is that the client don't know what state is the server in 
>> after TLS negotiation.  If the client tries giving USER and received 
>> -ERR, it may mean that the user name is unknown or that the user is 
>> authenticated already, and the client can't know for sure what does 
>> it mean.  Don't you have other idea of indicating the state?
>
> Hmm. I'd say that was a problem with the POP3 over TLS idea
>
> It seems wrong to have to try to do something, and see if you get an 
> error to see what you should do next. I know ESMTP does it, and the 
> POP3 'CAPA' do it, but that's because those things were added as a 
> hindsight after the base spec had been deployed. For a new standard to 
> need it just feels wrong.
>
> Personally, I'd expect authentication to always be required, even if 
> it's redundant. It just seems too much of a change from the base POP3 
> spec to skip the authorization stage.
>
> So, you could have the TLS session established which establishes the 
> user's identity, and then do
> USER anything
> +OK
> PASS anything
> +OK
>
> or you could use the USER/PASS as a part of two factor authentication 
> (the certificate is something you have, the username/password is 
> something you know)
>
> Going straight from session establishment into transaction state seems 
> wrong to me, given the base POP3 spec which POP3-over-TLS is building on.
The matter is that many POP servers support authentication using X.509 
certificate which was supplied during TLS negotiation and do not require 
further authentication.  In such case issuing USER will lead to -ERR, as 
the server is already in TRANSACTION then.  Other servers implement 
POP-over-TLS so that further authentication is also required (eg. Gmail, 
which I personally am using).
>
>
> BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete - 
> isn't the 'STLS' command (RFC 2595) the way we should be doing things 
> now? I thought the POP3S way was deprecated.
>
> Note that the RFC 2595 says:
> "The STLS command is only permitted in AUTHORIZATION state and the 
> server remains in AUTHORIZATION state, even if client credentials are 
> supplied during the TLS negotiation." so with STLS you have to 
> authenticate (not sure why it's called 'authorization' state when it's 
> really 'authentication' state, but that's not relevant) even if the 
> TLS has already supplied the user details.
Yes, RFC 2595 discouraged use of POP-over-TLS.  However, it is now used 
even wider than STLS, which led to effort to document this mode.  See 
above for note on why authorization might not be necessary after TLS 
negotiation.

Mykyta
>
>
>

--------------040709010300010303090803
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    26.07.2011 12:51, Paul Smith wrote:
    <blockquote cite="mid:[email-masked]" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      On 26/07/2011 10:22, Mykyta Yevstifeyev wrote:
      <blockquote cite="mid:[email-masked]" type="cite">26.07.2011

        11:12, Paul Smith wrote: <br>
        <blockquote type="cite">On 26/07/2011 05:59, Mykyta Yevstifeyev
          wrote: <br>
          <br>
          [ . .  .] <br>
          <br>
          If the state was server defined, so that it may change on the
          server's decision, rather than by purely bad coding in the
          client, then yes, an extended response code may be useful, but
          when it is only bad coding in the client which can make it
          happen - no. <br>
        </blockquote>
        Paul, <br>
        <br>
        [Adding Alexey Melnikov to CC list; see below.] <br>
        <br>
        I meant just the situation like this.  Eg., when one is using
        POP3-over-TLS whereas TLS connection is established before POP
        transaction starts, TLS negotiation may be used instead
        USER-PASS or AUTH authentication, entering the server into the
        TRANSACTION state; on the other hand, the server may require
        authentication under TLS layer, entering AUTHORIZATION state
        after establishing TLS connection.  I and Alexey Melnikov are
        currently working on the POP-over-TLS specification (<a
          moz-do-not-send="true" class="moz-txt-link-freetext"
          href="https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/">https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/</a>)
        and the problem is that the client don't know what state is the
        server in after TLS negotiation.  If the client tries giving
        USER and received -ERR, it may mean that the user name is
        unknown or that the user is authenticated already, and the
        client can't know for sure what does it mean.  Don't you have
        other idea of indicating the state? <br>
      </blockquote>
      <br>
      Hmm. I'd say that was a problem with the POP3 over TLS idea<br>
      <br>
      It seems wrong to have to try to do something, and see if you get
      an error to see what you should do next. I know ESMTP does it, and
      the POP3 'CAPA' do it, but that's because those things were added
      as a hindsight after the base spec had been deployed. For a new
      standard to need it just feels wrong.<br>
      <br>
      Personally, I'd expect authentication to always be required, even
      if it's redundant. It just seems too much of a change from the
      base POP3 spec to skip the authorization stage. <br>
      <br>
      So, you could have the TLS session established which establishes
      the user's identity, and then do<br>
      USER anything<br>
      +OK<br>
      PASS anything<br>
      +OK<br>
      <br>
      or you could use the USER/PASS as a part of two factor
      authentication (the certificate is something you have, the
      username/password is something you know)<br>
      <br>
      Going straight from session establishment into transaction state
      seems wrong to me, given the base POP3 spec which POP3-over-TLS is
      building on.<br>
    </blockquote>
    The matter is that many POP servers support authentication using
    X.509 certificate which was supplied during TLS negotiation and do
    not require further authentication.  In such case issuing USER will
    lead to -ERR, as the server is already in TRANSACTION then.  Other
    servers implement POP-over-TLS so that further authentication is
    also required (eg. Gmail, which I personally am using).<br>
    <blockquote cite="mid:[email-masked]" type="cite"> <br>
      <br>
      BTW - why are you looking at POP3-over-TLS? Isn't this idea
      obsolete - isn't the 'STLS' command (RFC 2595) the way we should
      be doing things now? I thought the POP3S way was deprecated.<br>
      <br>
      Note that the RFC 2595 says:<br>
      "The STLS command is only permitted in AUTHORIZATION state and the
      server remains in AUTHORIZATION state, even if client credentials
      are supplied during the TLS negotiation." so with STLS you have to
      authenticate (not sure why it's called 'authorization' state when
      it's really 'authentication' state<span class="Apple-style-span"
        style="border-collapse: separate; color: rgb(0, 0, 0);
        font-family: 'Times New Roman'; font-style: normal;
        font-variant: normal; font-weight: normal; letter-spacing:
        normal; line-height: normal; orphans: 2; text-indent: 0px;
        text-transform: none; white-space: normal; widows: 2;
        word-spacing: 0px; font-size: medium;"><span
          class="Apple-style-span" style="color: rgb(46, 44, 44);
          font-family: Georgia,'Times New Roman',Times,serif; font-size:
          15px; line-height: 22px;"></span></span>, but that's not
      relevant) even if the TLS has already supplied the user details.<br>
    </blockquote>
    Yes, RFC 2595 discouraged use of POP-over-TLS.  However, it is now
    used even wider than STLS, which led to effort to document this
    mode.  See above for note on why authorization might not be
    necessary after TLS negotiation.<br>
    <br>
    Mykyta<br>
    <blockquote cite="mid:[email-masked]" type="cite"> <br>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------040709010300010303090803--

Date: Tue, 26 Jul 2011 10:51:12 +0100
From: Paul Smith <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>, [email-masked]
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------010506080401080605030006
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 26/07/2011 10:22, Mykyta Yevstifeyev wrote:
> 26.07.2011 11:12, Paul Smith wrote:
>> On 26/07/2011 05:59, Mykyta Yevstifeyev wrote:
>>
>> [ . .  .]
>>
>> If the state was server defined, so that it may change on the 
>> server's decision, rather than by purely bad coding in the client, 
>> then yes, an extended response code may be useful, but when it is 
>> only bad coding in the client which can make it happen - no.
> Paul,
>
> [Adding Alexey Melnikov to CC list; see below.]
>
> I meant just the situation like this.  Eg., when one is using 
> POP3-over-TLS whereas TLS connection is established before POP 
> transaction starts, TLS negotiation may be used instead USER-PASS or 
> AUTH authentication, entering the server into the TRANSACTION state; 
> on the other hand, the server may require authentication under TLS 
> layer, entering AUTHORIZATION state after establishing TLS 
> connection.  I and Alexey Melnikov are currently working on the 
> POP-over-TLS specification 
> (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) and 
> the problem is that the client don't know what state is the server in 
> after TLS negotiation.  If the client tries giving USER and received 
> -ERR, it may mean that the user name is unknown or that the user is 
> authenticated already, and the client can't know for sure what does it 
> mean.  Don't you have other idea of indicating the state?

Hmm. I'd say that was a problem with the POP3 over TLS idea

It seems wrong to have to try to do something, and see if you get an 
error to see what you should do next. I know ESMTP does it, and the POP3 
'CAPA' do it, but that's because those things were added as a hindsight 
after the base spec had been deployed. For a new standard to need it 
just feels wrong.

Personally, I'd expect authentication to always be required, even if 
it's redundant. It just seems too much of a change from the base POP3 
spec to skip the authorization stage.

So, you could have the TLS session established which establishes the 
user's identity, and then do
USER anything
+OK
PASS anything
+OK

or you could use the USER/PASS as a part of two factor authentication 
(the certificate is something you have, the username/password is 
something you know)

Going straight from session establishment into transaction state seems 
wrong to me, given the base POP3 spec which POP3-over-TLS is building on.

BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete - 
isn't the 'STLS' command (RFC 2595) the way we should be doing things 
now? I thought the POP3S way was deprecated.

Note that the RFC 2595 says:
"The STLS command is only permitted in AUTHORIZATION state and the 
server remains in AUTHORIZATION state, even if client credentials are 
supplied during the TLS negotiation." so with STLS you have to 
authenticate (not sure why it's called 'authorization' state when it's 
really 'authentication' state, but that's not relevant) even if the TLS 
has already supplied the user details.

--------------010506080401080605030006
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 26/07/2011 10:22, Mykyta Yevstifeyev wrote:
    <blockquote cite="mid:[email-masked]" type="cite">26.07.2011
      11:12, Paul Smith wrote:
      <br>
      <blockquote type="cite">On 26/07/2011 05:59, Mykyta Yevstifeyev
        wrote:
        <br>
        <br>
        [ . .  .]
        <br>
        <br>
        If the state was server defined, so that it may change on the
        server's decision, rather than by purely bad coding in the
        client, then yes, an extended response code may be useful, but
        when it is only bad coding in the client which can make it
        happen - no.
        <br>
      </blockquote>
      Paul,
      <br>
      <br>
      [Adding Alexey Melnikov to CC list; see below.]
      <br>
      <br>
      I meant just the situation like this.  Eg., when one is using
      POP3-over-TLS whereas TLS connection is established before POP
      transaction starts, TLS negotiation may be used instead USER-PASS
      or AUTH authentication, entering the server into the TRANSACTION
      state; on the other hand, the server may require authentication
      under TLS layer, entering AUTHORIZATION state after establishing
      TLS connection.  I and Alexey Melnikov are currently working on
      the POP-over-TLS specification
      (<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/">https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/</a>)
      and the problem is that the client don't know what state is the
      server in after TLS negotiation.  If the client tries giving USER
      and received -ERR, it may mean that the user name is unknown or
      that the user is authenticated already, and the client can't know
      for sure what does it mean.  Don't you have other idea of
      indicating the state?
      <br>
    </blockquote>
    <br>
    Hmm. I'd say that was a problem with the POP3 over TLS idea<br>
    <br>
    It seems wrong to have to try to do something, and see if you get an
    error to see what you should do next. I know ESMTP does it, and the
    POP3 'CAPA' do it, but that's because those things were added as a
    hindsight after the base spec had been deployed. For a new standard
    to need it just feels wrong.<br>
    <br>
    Personally, I'd expect authentication to always be required, even if
    it's redundant. It just seems too much of a change from the base
    POP3 spec to skip the authorization stage. <br>
    <br>
    So, you could have the TLS session established which establishes the
    user's identity, and then do<br>
    USER anything<br>
    +OK<br>
    PASS anything<br>
    +OK<br>
    <br>
    or you could use the USER/PASS as a part of two factor
    authentication (the certificate is something you have, the
    username/password is something you know)<br>
    <br>
    Going straight from session establishment into transaction state
    seems wrong to me, given the base POP3 spec which POP3-over-TLS is
    building on.<br>
    <br>
    <br>
    BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete
    - isn't the 'STLS' command (RFC 2595) the way we should be doing
    things now? I thought the POP3S way was deprecated.<br>
    <br>
    Note that the RFC 2595 says:<br>
    "The STLS command is only permitted in AUTHORIZATION state and the
    server remains in AUTHORIZATION state, even if client credentials
    are supplied during the TLS negotiation." so with STLS you have to
    authenticate (not sure why it's called 'authorization' state when
    it's really 'authentication' state<span class="Apple-style-span"
      style="border-collapse: separate; color: rgb(0, 0, 0);
      font-family: 'Times New Roman'; font-style: normal; font-variant:
      normal; font-weight: normal; letter-spacing: normal; line-height:
      normal; orphans: 2; text-indent: 0px; text-transform: none;
      white-space: normal; widows: 2; word-spacing: 0px; font-size:
      medium;"><span class="Apple-style-span" style="color: rgb(46, 44,
        44); font-family: Georgia,'Times New Roman',Times,serif;
        font-size: 15px; line-height: 22px;"></span></span>, but that's
    not relevant) even if the TLS has already supplied the user details.<br>
    <br>
    <br>
  <br></body>
</html>

--------------010506080401080605030006--

Date: Tue, 26 Jul 2011 12:22:42 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

26.07.2011 11:12, Paul Smith wrote:
> On 26/07/2011 05:59, Mykyta Yevstifeyev wrote:
>
> [ . .  .]
>
> If the state was server defined, so that it may change on the server's 
> decision, rather than by purely bad coding in the client, then yes, an 
> extended response code may be useful, but when it is only bad coding 
> in the client which can make it happen - no.
Paul,

[Adding Alexey Melnikov to CC list; see below.]

I meant just the situation like this.  Eg., when one is using 
POP3-over-TLS whereas TLS connection is established before POP 
transaction starts, TLS negotiation may be used instead USER-PASS or 
AUTH authentication, entering the server into the TRANSACTION state; on 
the other hand, the server may require authentication under TLS layer, 
entering AUTHORIZATION state after establishing TLS connection.  I and 
Alexey Melnikov are currently working on the POP-over-TLS specification 
(https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) and the 
problem is that the client don't know what state is the server in after 
TLS negotiation.  If the client tries giving USER and received -ERR, it 
may mean that the user name is unknown or that the user is authenticated 
already, and the client can't know for sure what does it mean.  Don't 
you have other idea of indicating the state?

<thinking>The user agent may allow the user to choose the authentication 
way for POP-over-TLS transaction.  Eg., Thunderbird allows me to set 
POP-over-TLS and then one of the following: (1) plain auth. under TLS, 
(2) use AUTH command, (3) use Kerberos, or (4) use TLS certificate.  I 
suppose if (4) is chosen, -ERR indicates that TLS certificate didn't 
lead to successful authentication and server is in AUTHORIZATION and +OK 
means that server is in TRANSACTION.  (1), (2) and (3) assume that the 
server enters the TRANSACTION state after TLS negotiation and requires 
additional authentication.  I don't know the situation with Outlook 
and/or something else, but I suppose it will be rather the same and this 
issue may be successfully resolved.  So what's your opinion, Alexey? 
(Comments from 3rd parties are welcome as well, of course.)</thinking>

Mykyta
> Just my 2p worth

Date: Tue, 26 Jul 2011 09:12:56 +0100
From: Paul Smith <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>, [email-masked]
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

On 26/07/2011 05:59, Mykyta Yevstifeyev wrote:
>
> Hello,
>
> Post Office Protocol (POP) currently has no means of explicit 
> indicating that the command is given in the wrong state.
>
>>     A server MUST respond to a command issued when the
>>     session is in an incorrect state by responding with a negative 
>> status
>>     indicator.
>
> doesn't give enough information to the client.  The -ERR response 
> indicating wrong state may override -ERR response given with its 
> natural meaning.  I propose to define the new POP extension response 
> code (RFC 2449), WRONG-STATE, to indicate this.  Eg.:
>
>> C: <connects to the server>
>> S: +OK server ready
>> C: STAT
>> S: -ERR [WRONG-STATE] Not in TRANSACTION state yet
>
> Any thoughts?
I wouldn't have thought it would matter

AIUI the extension response codes are so that the client can understand 
it enough to tell the user what the error means (eg mailbox in use, 
rather than invalid password, during the login phase, so don't bother 
asking for the correct password)

Client code should never issue commands in the wrong state by the time 
it has been released to users... It may happen during development or 
testing, but at that time the interested people should have enough 
technical ability to read the standard and realise what has happened...

For that use:
-ERR not in transaction state yet
is just as good as
-ERR [WRONG-STATE] not in transaction state yet

If the state was server defined, so that it may change on the server's 
decision, rather than by purely bad coding in the client, then yes, an 
extended response code may be useful, but when it is only bad coding in 
the client which can make it happen - no.

Just my 2p worth

Date: Tue, 26 Jul 2011 07:59:24 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: [email-masked]
Subject: POP handling commands given in wrong state
Sender: [email-masked]

Hello,

Post Office Protocol (POP) currently has no means of explicit indicating 
that the command is given in the wrong state.

>     A server MUST respond to a command issued when the
>     session is in an incorrect state by responding with a negative status
>     indicator.

doesn't give enough information to the client.  The -ERR response 
indicating wrong state may override -ERR response given with its natural 
meaning.  I propose to define the new POP extension response code (RFC 
2449), WRONG-STATE, to indicate this.  Eg.:

> C: <connects to the server>
> S: +OK server ready
> C: STAT
> S: -ERR [WRONG-STATE] Not in TRANSACTION state yet

Any thoughts?

Mykyta Yevstifeyev