Re: POP handling commands given in wrong state
Paul Smith <[email protected]> Tue, 26 Jul 2011 14:32:16 +0100
| Newsgroups | gmane.ietf.pop3ext |
|---|---|
| Message-ID | <[email protected]> |
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: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by hoffman.proper.com id p6QDj0Xk003605
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
On 26/07/2011 14:19, Mykyta Yevstifeyev wrote:
<blockquote cite=3D"mid:[email protected]" type=3D"cite">
<blockquote cite=3D"mid:[email protected]" type=3D"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.=C2=A0 In such case issuing USER
will lead to -ERR, as the server is already in TRANSACTION then.=C2=
=A0
Other servers implement POP-over-TLS so that further
authentication is also required (eg. Gmail, which I personally am
using).<br>
<br>
<blockquote cite=3D"mid:[email protected]" type=3D"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<spa=
n
class=3D"Apple-style-span" style=3D"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=3D"Apple-style-span" style=3D"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.=C2=A0 However, it is=
now
used even wider than STLS, which led to effort to document this
mode.=C2=A0 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=3D"Apple-style-span"
style=3D"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=3D"Apple-style-span"
style=3D"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--