Re: What might suddenly provoke this poplib error?

[Peter J. Holzer]

[The OP has stated that the problem has been fixed. The following are
generic comments about troubleshooting.]

On 2022-10-14 11:31:56 +1300, dn wrote:
> On 14/10/2022 01.47, Chris Green wrote:
> >File "/usr/lib/python3.10/poplib.py", line 157, in _getresp
> >  raise error_proto(resp)
> >  poplib.error_proto: b'-ERR internal server error'
...
> > It seems to be saying that the POP3 server has a problem, if so
> > there's not much I can do about it as it's my hosting provider's
> > mail server.  Is it really saying the server has a problem?
> 
> 
> There's a range of possibilities here. The first question to ask (as
> you probably have) is "what has changed?" - has the Python/PSL on this
> computer been updated*, has the computer's SSL/TLS library been
> updated, etc. Then there are possible changes at 'the other end' - per
> previous responses.

I think this should be the second question. The first quesion is: What
are the actual symptoms?

In this case we have a relatively clear error message which was
obviously[2] sent by the server. So anything else must[1] be consistent
with this error message (and the fact that we were able to get this
error message in the first place).

So it can't[1] be TLS, because if you can't establish a connection, the
server can't send an error message.

The message also says "internal server error", and this is not something
a client should be able to provoke. So it's unlikely to be anything on
the client side.

What's left is that there was a change or operational error on the
server side, so further analysis must be conducted there.

hp


[1] Take absolute assertions like this with a grain of salt. There are
always misleading error messages, weird edge cases, etc. But
consider those only after ruling out everything else.

[2] What may be obvious to one person is of course not necessarily
obvious to another.

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What might suddenly provoke this poplib error?

[Chris Green]

Peter J. Holzer  wrote:
> [-- text/plain, encoding quoted-printable, charset: us-ascii, 28 lines --]
> 
> On 2022-10-13 13:47:07 +0100, Chris Green wrote:
> > I have a short python3 program that collects E-Mails from a 'catchall'
> > mailbox, sends the few that might be interesting to me and dumps the
> > rest.
> > 
> > It has suddenly (after working for some years) started throwing the
> > following:-
> [...]
> > poplib.error_proto: b'-ERR internal server error'
> [...]
> > It seems to be saying that the POP3 server has a problem,
> 
> Yes. "-ERR" is the normal start of a POP error reply, so the message
> "-ERR internal server error" was sent by the POP server.
> 
> > if so there's not much I can do about it as it's my hosting provider's
> > mail server.
> 
> You can call you hosting provider and ask them to fix the problem.
> 
After a couple of hours someone obviously fixed something and the
error has stopped now.

Thanks everyone.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What might suddenly provoke this poplib error?

[Chris Green]

MRAB  wrote:
[snip boring code]
> > 
> > It seems to be saying that the POP3 server has a problem, if so there's not
> > much I can do about it as it's my hosting provider's mail server.  Is it
> > really saying the server has a problem?
> > 
> As you've already ascertained that it's a server error, I'd just like to 
> suggest that you add a sleep before retrying. If it has timed out after 
> 5 minutes, I doubt there's much point in retrying immediately.

I guess I could do that but this has only happened once in quite a few
years so I'm not sure if I;ll bother! :-)

The program is only run half-hourly by cron.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What might suddenly provoke this poplib error?

[dn]

On 14/10/2022 01.47, Chris Green wrote:

I have a short python3 program that collects E-Mails from a 'catchall'
mailbox, sends the few that might be interesting to me and dumps the
rest.

It has suddenly (after working for some years) started throwing the
following:-

 Traceback (most recent call last):
   File "/home/chris/.mutt/bin/getCatchall.py", line 83, in 
 pop3.pass_('brzmilla')
   File "/usr/lib/python3.10/poplib.py", line 218, in pass_
 return self._shortcmd('PASS %s' % pswd)
   File "/usr/lib/python3.10/poplib.py", line 181, in _shortcmd
 return self._getresp()
   File "/usr/lib/python3.10/poplib.py", line 157, in _getresp
 raise error_proto(resp)
 poplib.error_proto: b'-ERR internal server error'


The section of code throwing the error is as follows:-

 #
 #
 # Connect to the POP3 server, get message count, exit if no messages
 #
 for t in range(10): # retry 10 times
 try:
 pop3 = poplib.POP3_SSL('mail3.gridhost.co.uk',timeout=300)
 break
 except TimeoutError:
 if t == 9:
 log.err("Timed out 10 times, giving up")
 exit(1)
 else:
 log.warn("Timed out, try " + str(t))

 pop3.user('catch...@isbd.net')
 pop3.pass_('brzmilla')
 numMessages = len(pop3.list()[1])
 if (numMessages == 0):
 break


It seems to be saying that the POP3 server has a problem, if so there's not
much I can do about it as it's my hosting provider's mail server.  Is it
really saying the server has a problem?



There's a range of possibilities here. The first question to ask (as you 
probably have) is "what has changed?" - has the Python/PSL on this 
computer been updated*, has the computer's SSL/TLS library been updated, 
etc. Then there are possible changes at 'the other end' - per previous 
responses.


* IIRC the last changes to email lib were circa 3.5, but poplib's doc 
page shows more recent updates - including to timeouts in v3.9 (YMMV).



There are changes afoot in the TLS arena. Older algorithms being dumped, 
and newer, stronger, harder, faster, better mechanisms (with racing 
stripes) being added. Not using POP3, I can't say how much impact such 
may have...


Try using an independent checker to investigate continuity of access. 
From your own machine (I use "s_client -connect..." but for IMAP), thus 
should be able to replicate the 'error' conversation at the level of the 
POP3 'conversation'. Alternately, use an on-line service such as: 
https://www.wormly.com/test-pop3-mail-server
Disclaimer: again, not using POP3, I have never used this service, it 
'popped-up' whilst searching on DuckDuckGo.



Many general-purpose service/server-providers seem rather heavy-handed 
when it comes to email security, often as a result of some knee-jerk 
response to a 'live-issue' - ultimately caused by them not having 
competent email-specialists on-staff. Accordingly, they may have 
'changed policy' and 'forgotten' to let mere-clients know. (although, if 
your standard email access continues unabated, this seems less-likely) 
That said, it never hurts to ask/be in friendly-contact...



PS is that really your password? If so, ...
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: What might suddenly provoke this poplib error?

[Peter J. Holzer]

On 2022-10-13 13:47:07 +0100, Chris Green wrote:
> I have a short python3 program that collects E-Mails from a 'catchall'
> mailbox, sends the few that might be interesting to me and dumps the
> rest.
> 
> It has suddenly (after working for some years) started throwing the
> following:-
[...]
> poplib.error_proto: b'-ERR internal server error'
[...]
> It seems to be saying that the POP3 server has a problem,

Yes. "-ERR" is the normal start of a POP error reply, so the message
"-ERR internal server error" was sent by the POP server.

> if so there's not much I can do about it as it's my hosting provider's
> mail server.

You can call you hosting provider and ask them to fix the problem.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What might suddenly provoke this poplib error?

[MRAB]

On 2022-10-13 13:47, Chris Green wrote:

I have a short python3 program that collects E-Mails from a 'catchall'
mailbox, sends the few that might be interesting to me and dumps the
rest.

It has suddenly (after working for some years) started throwing the
following:-

 Traceback (most recent call last):
   File "/home/chris/.mutt/bin/getCatchall.py", line 83, in 
 pop3.pass_('brzmilla')
   File "/usr/lib/python3.10/poplib.py", line 218, in pass_
 return self._shortcmd('PASS %s' % pswd)
   File "/usr/lib/python3.10/poplib.py", line 181, in _shortcmd
 return self._getresp()
   File "/usr/lib/python3.10/poplib.py", line 157, in _getresp
 raise error_proto(resp)
 poplib.error_proto: b'-ERR internal server error'


The section of code throwing the error is as follows:-

 #
 #
 # Connect to the POP3 server, get message count, exit if no messages
 #
 for t in range(10): # retry 10 times
 try:
 pop3 = poplib.POP3_SSL('mail3.gridhost.co.uk',timeout=300)
 break
 except TimeoutError:
 if t == 9:
 log.err("Timed out 10 times, giving up")
 exit(1)
 else:
 log.warn("Timed out, try " + str(t))

 pop3.user('catch...@isbd.net')
 pop3.pass_('brzmilla')
 numMessages = len(pop3.list()[1])
 if (numMessages == 0):
 break


It seems to be saying that the POP3 server has a problem, if so there's not
much I can do about it as it's my hosting provider's mail server.  Is it
really saying the server has a problem?

As you've already ascertained that it's a server error, I'd just like to 
suggest that you add a sleep before retrying. If it has timed out after 
5 minutes, I doubt there's much point in retrying immediately.

--
https://mail.python.org/mailman/listinfo/python-list

What might suddenly provoke this poplib error?

[Chris Green]

I have a short python3 program that collects E-Mails from a 'catchall'
mailbox, sends the few that might be interesting to me and dumps the
rest.

It has suddenly (after working for some years) started throwing the
following:-

Traceback (most recent call last):
  File "/home/chris/.mutt/bin/getCatchall.py", line 83, in 
pop3.pass_('brzmilla')
  File "/usr/lib/python3.10/poplib.py", line 218, in pass_
return self._shortcmd('PASS %s' % pswd)
  File "/usr/lib/python3.10/poplib.py", line 181, in _shortcmd
return self._getresp()
  File "/usr/lib/python3.10/poplib.py", line 157, in _getresp
raise error_proto(resp)
poplib.error_proto: b'-ERR internal server error'


The section of code throwing the error is as follows:-

#
#
# Connect to the POP3 server, get message count, exit if no messages   
#
for t in range(10): # retry 10 times
try:
pop3 = poplib.POP3_SSL('mail3.gridhost.co.uk',timeout=300)
break
except TimeoutError: 
if t == 9:
log.err("Timed out 10 times, giving up")
exit(1)
else:
log.warn("Timed out, try " + str(t))

pop3.user('catch...@isbd.net')
pop3.pass_('brzmilla')
numMessages = len(pop3.list()[1])
if (numMessages == 0):
break


It seems to be saying that the POP3 server has a problem, if so there's not
much I can do about it as it's my hosting provider's mail server.  Is it
really saying the server has a problem?



-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What might suddenly provoke this poplib error?

[Chris Green]

A further little bit of information, I tried running getCatchall.py
from the command prompt and there was a long wait before it output the
same error message.  I.e. it looks rather as if the server is not
responding to requests. (A 'long wait' is a minute or two)

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue486079] poplib contains unuseable code

[admin]

Change by admin :


--
github: None -> 35603

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue403329] Update poplib to use re

[admin]

Change by admin :


--
github: None -> 33759

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12706] timeout sentinel in ftplib and poplib documentation

[Irit Katriel]

Change by Irit Katriel :


--
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.5, Python 3.6, Python 
3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)

[Ned Deily]

Change by Ned Deily :


--
Removed message: https://bugs.python.org/msg342092

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)

[Ned Deily]

Ned Deily  added the comment:


New changeset 942cc04ae44825ea120e3a19a80c9b348b8194d0 by larryhastings (Ned 
Deily) in branch '3.4':
[3.4] bpo-32981: Fix catastrophic backtracking vulns (GH-5955) (#6035)
https://github.com/python/cpython/commit/942cc04ae44825ea120e3a19a80c9b348b8194d0


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)

[STINNER Victor]

STINNER Victor  added the comment:

FYI I tracked this vulnerability at:
http://python-security.readthedocs.io/vuln/cve-2018-1060_difflib_and_poplib_catastrophic_backtracking.html

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)

[Ned Deily]

Ned Deily  added the comment:

> Is this ready to close?

The fixes are now available from the cpython repo for all current security and 
maintenance branches (3.4 to 3.7 plus 2.7).  They are now released in 3.6.5rc1 
and will be available in the next releases of other branches: 3.7.0, 3.5.6, 
3.4.9, and 2.7.15.

Thanks again for reporting the issues, James, and helping to resolve them!

--
nosy: +ned.deily
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)

[Larry Hastings]

Larry Hastings  added the comment:

Is this ready to close?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)

[Larry Hastings]

Larry Hastings  added the comment:


New changeset 937ac1fe069a4dc8471dff205f553d82e724015b by larryhastings (Ned 
Deily) in branch '3.5':
[3.5] bpo-32981: Fix catastrophic backtracking vulns (GH-5955) (#6034)
https://github.com/python/cpython/commit/937ac1fe069a4dc8471dff205f553d82e724015b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)

[Larry Hastings]

Larry Hastings  added the comment:


New changeset 942cc04ae44825ea120e3a19a80c9b348b8194d0 by larryhastings (Ned 
Deily) in branch '3.4':
[3.4] bpo-32981: Fix catastrophic backtracking vulns (GH-5955) (#6035)
https://github.com/python/cpython/commit/942cc04ae44825ea120e3a19a80c9b348b8194d0


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)

[Ned Deily]

Change by Ned Deily <n...@python.org>:


--
keywords: +security_issue
nosy: +larry
priority: normal -> critical
title: Catastrophic backtracking in poplib and difflib -> Catastrophic 
backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 
3.8

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32981>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +5797

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +5796

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset c9516754067d71fd7429a25ccfcb2141fc583523 by Benjamin Peterson in 
branch '3.6':
[3.6] bpo-32981: Fix catastrophic backtracking vulns (GH-5955)
https://github.com/python/cpython/commit/c9516754067d71fd7429a25ccfcb2141fc583523


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset e052d40cea15f582b50947f7d906b39744dc62a2 by Benjamin Peterson in 
branch '2.7':
[2.7] bpo-32981: Fix catastrophic backtracking vulns (GH-5955)
https://github.com/python/cpython/commit/e052d40cea15f582b50947f7d906b39744dc62a2


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset 0902a2d6b2d1d9dbde36aeaaccf1788ceaa97143 by Benjamin Peterson 
(Miss Islington (bot)) in branch '3.7':
bpo-32981: Fix catastrophic backtracking vulns (GH-5955)
https://github.com/python/cpython/commit/0902a2d6b2d1d9dbde36aeaaccf1788ceaa97143


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[Benjamin Peterson]

Change by Benjamin Peterson :


--
pull_requests: +5737

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[Benjamin Peterson]

Change by Benjamin Peterson :


--
pull_requests: +5736

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset 0e6c8ee2358a2e23117501826c008842acb835ac by Benjamin Peterson 
(Jamie Davis) in branch 'master':
bpo-32981: Fix catastrophic backtracking vulns (#5955)
https://github.com/python/cpython/commit/0e6c8ee2358a2e23117501826c008842acb835ac


--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[miss-islington]

Change by miss-islington :


--
keywords: +patch
pull_requests: +5735
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32981] Catastrophic backtracking in poplib and difflib

[James Davis]

New submission from James Davis <davis...@vt.edu>:

Hi Python security team,

My name is James Davis. I'm a security researcher at Virginia Tech.

The python core (cpython) has 2 regular expressions vulnerable to catastrophic 
backtracking that look like potential DOS vectors.
The vulnerable expressions are listed below.

Each vulnerability has the following keys, explained in more detail below:
 - pattern
 - filesIn (as of December/January; I excluded any appearances in 
irrelevant-looking dirs, and in '.min' files)
 - stringLenFor10Sec
 - nPumpsFor10Sec
 - attackFormat
 - blowupCurve

The attack format describes how to generate an attack string.
On my machine, an attack string generated using nPumpsFor10Sec repetitions 
("pumps") of the pump string(s)
blocks the python regex engine for 10 seconds, though this will vary based on 
your hardware.

Compose an attack string like this:
  'prefix 1' + 'pump 1' X times + 'prefix 2' + 'pump 2' X times + ... + suffix
Example:
  With pumpPairs: [{'prefix': 'a', 'pump': 'b'}], suffix: 'c', an attack string 
with three pumps would be:
abbbc

Catastrophic backtracking blows up at either an exponential rate or a 
super-linear (power law) rate.
The blowupCurve indicates how severe the blow-up is.
The 'type' is either EXP(onential) or POW(er law) in the number of pumps (x).
The 'parms' are the parameters for the two curve types. The second parameter is 
more important, because:
  EXP: f(x) = parms[0] * parms[1]^x
  POW: f(x) = parms[0] * x^parms[1]

JSON formatted:

Vuln 1:

{
   "attackFormat" : {
  "pumpPairs" : [
 {
"pump" : "<a",
"prefix" : "+OKa"
 }
  ],
  "suffix" : "+"
   },
   "blowupCurve" : {
  "parms" : [
 2.71096268836868e-08,
 1.83422078906374
  ],
  "type" : "POWER",
  "r2" : 0.997503282766243
   },
   "stringLenFor10Sec" : 96655,
   "nPumpsFor10Sec" : "48325",
   "pattern" : "\\+OK.*(<[^>]+>)",
   "filesIn" : [
  [
 "Lib/poplib.py"
  ]
   ]
}

Vuln 2:

{
   "blowupCurve" : {
  "parms" : [
 1.31911634447601e-08,
 1.89691808610459
  ],
  "r2" : 0.998387790742004,
  "type" : "POWER"
   },
   "stringLenFor10Sec" : 48328,
   "attackFormat" : {
  "pumpPairs" : [
 {
"pump" : "\t",
"prefix" : "\t"
     }
  ],
  "suffix" : "##"
   },
   "pattern" : "\\s*#?\\s*$",
   "filesIn" : [
  [
 "Lib/difflib.py"
  ]
   ],
   "nPumpsFor10Sec" : "48325"
}

--
components: Library (Lib)
messages: 313119
nosy: davisjam
priority: normal
pull_requests: 5723
severity: normal
status: open
title: Catastrophic backtracking in poplib and difflib
type: security

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32981>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Christian Heimes]

Change by Christian Heimes :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Christian Heimes]

Christian Heimes  added the comment:


New changeset 8d4d17399fb82801eaaca5beeb97a19908b40222 by Christian Heimes in 
branch '2.7':
bpo-31518: Change TLS protocol for Debian (#3661)
https://github.com/python/cpython/commit/8d4d17399fb82801eaaca5beeb97a19908b40222


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Christian Heimes]

Christian Heimes  added the comment:


New changeset aab225840360719516eca55a7a69cfee45aee2af by Christian Heimes in 
branch '3.6':
bpo-31518: Change TLS protocol for Debian (#3660)
https://github.com/python/cpython/commit/aab225840360719516eca55a7a69cfee45aee2af


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12706] timeout sentinel in ftplib and poplib documentation

[Marcel Widjaja]

Change by Marcel Widjaja :


--
pull_requests: +5156
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12706] timeout sentinel in ftplib and poplib documentation

[Greg]

Greg  added the comment:

Completely forgot about this, please take my patch and submit a pr

On Fri, Dec 29, 2017 at 10:55 AM, Marcel Widjaja 
wrote:

>
> Marcel Widjaja  added the comment:
>
> Greg, I wonder if you are planning to submit a PR for your patch? If not,
> I'm plan to take your patch, make some minor adjustment and submit a PR.
>
> --
> nosy: +mawidjaj
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12706] timeout sentinel in ftplib and poplib documentation

[Marcel Widjaja]

Marcel Widjaja  added the comment:

Greg, I wonder if you are planning to submit a PR for your patch? If not, I'm 
plan to take your patch, make some minor adjustment and submit a PR.

--
nosy: +mawidjaj

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Christian Heimes]

Christian Heimes added the comment:

PR 3660 and PR 3661 address most of the failing tests. The two failures in 
msg302531 are discussed in issue #31453.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Matthias Klose]

Matthias Klose added the comment:

Christian, I assume you'd like to see a test which can be done at *runtime*, 
not *buildtime*.  Assuming you have that openssl upstream patch available in 
your build dependency, would that help with the detection?  If yes, I'll talk 
to Debian's and Ubuntu's openssl maintainers to backport it, so the _ssl module 
could use it depending on a configure check.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Christian Heimes]

Changes by Christian Heimes :


--
pull_requests: +3650

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Christian Heimes]

Changes by Christian Heimes :


--
keywords: +patch
pull_requests: +3649
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Christian Heimes]

Christian Heimes added the comment:

Two tests are failing in 3.7 branch:

==
ERROR: test_PROTOCOL_TLS (test.test_ssl.ThreadedTests)
Connecting to an SSLv23 server with various client options
--
Traceback (most recent call last):
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 2660, in 
test_PROTOCOL_TLS
try_protocol_combo(ssl.PROTOCOL_TLS, ssl.PROTOCOL_TLSv1, 'TLSv1')
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 2343, in 
try_protocol_combo
chatty=False, connectionchatty=False)
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 2268, in 
server_params_test
s.connect((HOST, server.port))
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1108, in connect
self._real_connect(addr, False)
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1099, in _real_connect
self.do_handshake()
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1076, in do_handshake
self._sslobj.do_handshake()
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 697, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version 
(_ssl.c:864)

==
ERROR: test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1.1 server with various client options.
--
Traceback (most recent call last):
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 2734, in 
test_protocol_tlsv1_1
try_protocol_combo(ssl.PROTOCOL_TLS, ssl.PROTOCOL_TLSv1_1, 'TLSv1.1')
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 2343, in 
try_protocol_combo
chatty=False, connectionchatty=False)
  File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 2268, in 
server_params_test
s.connect((HOST, server.port))
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1108, in connect
self._real_connect(addr, False)
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1099, in _real_connect
self.do_handshake()
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1076, in do_handshake
self._sslobj.do_handshake()
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 697, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version 
(_ssl.c:864)

--

Matthias,
is there any way to detect Debian's modifications of OpenSSL from header files 
or with an API call? Otherwise we have no way to reliable detect and correctly 
skip the test. At the moment there is no way to retrieve the minimum protocol 
from OpenSSL SSL_CTX. I landed an OpenSSL patch just a couple of days ago to 
add SSL_CTX_get_min_proto_version(), 
https://github.com/openssl/openssl/pull/4364

--
versions: +Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Christian Heimes]

Christian Heimes added the comment:

3.7 does no longer use PROTOCOL_TLSv1 except for test_ssl.py, see #31346

By the way Debian Sid/Buster broke support for SSL and TLS < 1.2. see #31453. 
There is no way to enable the protocols from Python.

--
versions:  -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Matthias Klose]

Matthias Klose added the comment:

failing tests:

https://ci.debian.net/data/packages/unstable/amd64/p/python3.6/latest-autopkgtest/log.gz

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31518] ftplib, urllib2, poplib, httplib, urllib2_localnet use ssl.PROTOCOL_TLSv1 unconditionally

[Matthias Klose]

New submission from Matthias Klose:

Debian's OpenSSL now disables TLS 1.0 and 1.1, letting some of the python tests 
fail.  Please make them use a newer protocol version, or make the use of the 
older versions conditional.

--
assignee: christian.heimes
components: SSL
messages: 302524
nosy: christian.heimes, doko
priority: normal
severity: normal
status: open
title: ftplib, urllib2, poplib, httplib, urllib2_localnet use 
ssl.PROTOCOL_TLSv1 unconditionally
versions: Python 2.7, Python 3.6, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31518>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30329] poplib and imaplib should catch "OSError: [WinError 10022] An invalid argument was supplied" on shutdown

[STINNER Victor]

STINNER Victor added the comment:

> The bug should now be catched.

Oops, I wanted to write: "should now be fixed", sorry!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30329] poplib and imaplib should catch "OSError: [WinError 10022] An invalid argument was supplied" on shutdown

[STINNER Victor]

STINNER Victor added the comment:

The bug should now be catched.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30329] poplib and imaplib should catch "OSError: [WinError 10022] An invalid argument was supplied" on shutdown

[STINNER Victor]

STINNER Victor added the comment:


New changeset 800e4b7ad6b6f86c17408429852dfb47493d366e by Victor Stinner in 
branch '2.7':
bpo-30329: Catch Windows error 10022 on shutdown() (#1538) (#1624)
https://github.com/python/cpython/commit/800e4b7ad6b6f86c17408429852dfb47493d366e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30329] poplib and imaplib should catch "OSError: [WinError 10022] An invalid argument was supplied" on shutdown

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1713

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30329] poplib and imaplib should catch "OSError: [WinError 10022] An invalid argument was supplied" on shutdown

[STINNER Victor]

STINNER Victor added the comment:


New changeset c9ba45d1b71d86321e5422e8a2cbe6e52aaba6f4 by Victor Stinner in 
branch '3.5':
bpo-30329: Catch Windows error 10022 on shutdown() (#1538) (#1621)
https://github.com/python/cpython/commit/c9ba45d1b71d86321e5422e8a2cbe6e52aaba6f4


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30329] poplib and imaplib should catch "OSError: [WinError 10022] An invalid argument was supplied" on shutdown

[STINNER Victor]

STINNER Victor added the comment:


New changeset aaa053652556aa4e59cb68f3983a09ced1d1fe2a by Victor Stinner in 
branch '3.6':
bpo-30329: Catch Windows error 10022 on shutdown() (#1538) (#1620)
https://github.com/python/cpython/commit/aaa053652556aa4e59cb68f3983a09ced1d1fe2a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30329] poplib and imaplib should catch "OSError: [WinError 10022] An invalid argument was supplied" on shutdown

[STINNER Victor]

Changes by STINNER Victor <victor.stin...@gmail.com>:


--
components: +Library (Lib)
title: test_imaplib.test_login_cram_md5(): OSError: [WinError 10022] An invalid 
argument was supplied on AMD64 Windows8.1 Non-Debug 3.6 -> poplib and imaplib 
should catch "OSError: [WinError 10022] An invalid argument was supplied" on 
shutdown
versions: +Python 3.5, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30329>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12706] timeout sentinel in ftplib and poplib documentation

[Berker Peksag]

Berker Peksag added the comment:

Documentation changes look good to me. However, I'd prefer using 
socket._GLOBAL_DEFAULT_TIMEOUT in the timeout parameter of FTP.connect().

--
keywords: +easy
nosy: +berker.peksag
versions: +Python 3.5, Python 3.6, Python 3.7 -Python 2.7, Python 3.2, Python 
3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How to program round this poplib error?

[dieter]

c...@isbd.net writes:

> I have a (fairly simple) Python program that scans through a
> 'catchall' E-Mail address for things that *might* be for me.  It sends
> anything that could be for me to my main E-Mail and discards the rest.
>
> However I *occasionally* get an error from it as follows:-
>
> Traceback (most recent call last):
>   File "/home/chris/.mutt/bin/getCatchall.py", line 65, in 
> pop3.dele(i+1)
>   File "/usr/lib/python2.7/poplib.py", line 240, in dele
> return self._shortcmd('DELE %s' % which)
>   File "/usr/lib/python2.7/poplib.py", line 160, in _shortcmd
> return self._getresp()
>   File "/usr/lib/python2.7/poplib.py", line 132, in _getresp
> resp, o = self._getline()
>   File "/usr/lib/python2.7/poplib.py", line 377, in _getline
> raise error_proto('line too long')
> poplib.error_proto: line too long
>
>
> Does anyone have any idea how I can program around this somehow?

This is bug "https://bugs.python.org/issue23906;.

Following a recommendation from "Laura Creighton", I work around it
by

import poplib; poplib._MAXLINE=5


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to program round this poplib error?

[cl]

Jon Ribbens <jon+use...@unequivocal.co.uk> wrote:
> On 2016-03-10, c...@isbd.net <c...@isbd.net> wrote:
> > # Read each message into a string and then parse with the email 
> > module, if 
> > # there's an error retrieving the message then just throw it away 
> > # 
> > try:
> > popmsg = pop3.retr(i+1)
> > except:
> > pop3.dele(i+1)
> > continue
> >
> > The trouble is that the error is (presumably) some sort of buffer size
> > limitation in pop3.dele().  If I trap the error then I still can't get
> > rid of the rogue E-Mail and, more to the point, I can't even identify
> > it so that the trap could report the error and tell me which message
> > was causing it.
> 
> You really, really should not be using bare "except:".
> Always specify which exceptions you are trying to catch.
> 
Yes, I know, but it doesn't really relate to the problem does it.


> In this case, I think there are two problems. Firstly, I think
> whoever implemented poplib mis-read the POP3 specification, as
> they are applying the line-length limit to not just the POP3
> commands and responses, but the email contents too.
> 
> Secondly, you are just trying to carry on with the POP3 connection
> after it has thrown an exception. You can't do that, because you
> don't know what the problem was. My guess would be that what you
> are mostly seeing is a line in the email content that is over 2kB,
> which causes 'retr' to throw a "line too long" exception.
> 
> You then blindly throw a "DELE" at the server, and when you try to
> read the response to that command it throws another "line too long"
> exception because (a) the server's actually still in the middle of
> sending the email contents and (b) there's a bug in the SSL poplib
> which means once it's thrown "line too long" it will keep doing so
> repeatedly.
> 
> So what I think you need to do is:
> 
>   (a) after your "import poplib" add "poplib._MAXLINE = 10*1024*1024"
>   or somesuch (i.e. increase it a lot),
> 
Ah, that's a much better way of doing it than actually changing the
code, thank you.


>   (b) get rid of your "except:" and work out what you really meant,
>   checking what the error returned was before blindly throwing
>   commands at a POP3 server in an unknown state. You may well
>   need to disconnect and reconnect before continuing - or indeed
>   you may well not need to catch any exception at all at this
>   point after doing (a).

Yes, hopefully the exception will go away.

Thank you again.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to program round this poplib error?

[cl]

Mark Lawrence  wrote:
> On 10/03/2016 12:04, c...@isbd.net wrote:
> > I have a (fairly simple) Python program that scans through a
> > 'catchall' E-Mail address for things that *might* be for me.  It sends
> > anything that could be for me to my main E-Mail and discards the rest.
> >
> > However I *occasionally* get an error from it as follows:-
> >
> >  Traceback (most recent call last):
> >File "/home/chris/.mutt/bin/getCatchall.py", line 65, in 
> >  pop3.dele(i+1)
> >File "/usr/lib/python2.7/poplib.py", line 240, in dele
> >  return self._shortcmd('DELE %s' % which)
> >File "/usr/lib/python2.7/poplib.py", line 160, in _shortcmd
> >  return self._getresp()
> >File "/usr/lib/python2.7/poplib.py", line 132, in _getresp
> >  resp, o = self._getline()
> >File "/usr/lib/python2.7/poplib.py", line 377, in _getline
> >  raise error_proto('line too long')
> >  poplib.error_proto: line too long
> >
> >
> > Does anyone have any idea how I can program around this somehow?  As
> > it is at the moment I have to go to the webmail system at my ISP and
> > manually delete the message which is a bit of a nuisance.
> >
> 
> How about a try/except in your code that catches poplib.error_proto?
> 
... and?  I'm still stuck because I can't identify the E-Mail in any
way to enable me to go and find it and delete it.  So the program
keeps trapping on the same E-Mail and never gets to process anything
after that.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to program round this poplib error?

[Jon Ribbens]

On 2016-03-10, c...@isbd.net <c...@isbd.net> wrote:
> # Read each message into a string and then parse with the email 
> module, if 
> # there's an error retrieving the message then just throw it away 
> # 
> try:
> popmsg = pop3.retr(i+1)
> except:
> pop3.dele(i+1)
> continue
>
> The trouble is that the error is (presumably) some sort of buffer size
> limitation in pop3.dele().  If I trap the error then I still can't get
> rid of the rogue E-Mail and, more to the point, I can't even identify
> it so that the trap could report the error and tell me which message
> was causing it.

You really, really should not be using bare "except:".
Always specify which exceptions you are trying to catch.

In this case, I think there are two problems. Firstly, I think
whoever implemented poplib mis-read the POP3 specification, as
they are applying the line-length limit to not just the POP3
commands and responses, but the email contents too.

Secondly, you are just trying to carry on with the POP3 connection
after it has thrown an exception. You can't do that, because you
don't know what the problem was. My guess would be that what you
are mostly seeing is a line in the email content that is over 2kB,
which causes 'retr' to throw a "line too long" exception.

You then blindly throw a "DELE" at the server, and when you try to
read the response to that command it throws another "line too long"
exception because (a) the server's actually still in the middle of
sending the email contents and (b) there's a bug in the SSL poplib
which means once it's thrown "line too long" it will keep doing so
repeatedly.

So what I think you need to do is:

  (a) after your "import poplib" add "poplib._MAXLINE = 10*1024*1024"
  or somesuch (i.e. increase it a lot),

  (b) get rid of your "except:" and work out what you really meant,
  checking what the error returned was before blindly throwing
  commands at a POP3 server in an unknown state. You may well
  need to disconnect and reconnect before continuing - or indeed
  you may well not need to catch any exception at all at this
  point after doing (a).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to program round this poplib error?

[Mark Lawrence]

On 10/03/2016 12:04, c...@isbd.net wrote:

I have a (fairly simple) Python program that scans through a
'catchall' E-Mail address for things that *might* be for me.  It sends
anything that could be for me to my main E-Mail and discards the rest.

However I *occasionally* get an error from it as follows:-

 Traceback (most recent call last):
   File "/home/chris/.mutt/bin/getCatchall.py", line 65, in 
 pop3.dele(i+1)
   File "/usr/lib/python2.7/poplib.py", line 240, in dele
 return self._shortcmd('DELE %s' % which)
   File "/usr/lib/python2.7/poplib.py", line 160, in _shortcmd
 return self._getresp()
   File "/usr/lib/python2.7/poplib.py", line 132, in _getresp
 resp, o = self._getline()
   File "/usr/lib/python2.7/poplib.py", line 377, in _getline
 raise error_proto('line too long')
 poplib.error_proto: line too long


Does anyone have any idea how I can program around this somehow?  As
it is at the moment I have to go to the webmail system at my ISP and
manually delete the message which is a bit of a nuisance.



How about a try/except in your code that catches poplib.error_proto?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

How to program round this poplib error?

[cl]

I have a (fairly simple) Python program that scans through a
'catchall' E-Mail address for things that *might* be for me.  It sends
anything that could be for me to my main E-Mail and discards the rest.

However I *occasionally* get an error from it as follows:-

Traceback (most recent call last):
  File "/home/chris/.mutt/bin/getCatchall.py", line 65, in 
pop3.dele(i+1)
  File "/usr/lib/python2.7/poplib.py", line 240, in dele
return self._shortcmd('DELE %s' % which)
  File "/usr/lib/python2.7/poplib.py", line 160, in _shortcmd
return self._getresp()
  File "/usr/lib/python2.7/poplib.py", line 132, in _getresp
resp, o = self._getline()
  File "/usr/lib/python2.7/poplib.py", line 377, in _getline
raise error_proto('line too long')
poplib.error_proto: line too long


Does anyone have any idea how I can program around this somehow?  As
it is at the moment I have to go to the webmail system at my ISP and
manually delete the message which is a bit of a nuisance.

The piece of code that produces the error is as follows:-

# 
# 
# Read each message into a string and then parse with the email module, 
if 
# there's an error retrieving the message then just throw it away 
# 
try:
popmsg = pop3.retr(i+1)
except:
pop3.dele(i+1)
continue

The trouble is that the error is (presumably) some sort of buffer size
limitation in pop3.dele().  If I trap the error then I still can't get
rid of the rogue E-Mail and, more to the point, I can't even identify
it so that the trap could report the error and tell me which message
was causing it.

I guess one way to get around the problem would be to increase
_MAXLINE in /usr/lib/python2.7/poplib.py, it's on my own system so I
could do this.  Can anyone think of a better approach?



-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue23906] poplib maxline behaviour may be wrong

[R. David Murray]

R. David Murray added the comment:

If maxline is too small, messages won't get through.  If maxline is too large 
*huge* messages will get through...and the DDOS danger of exhausting the 
server's resources will occur.  So, we really ought to provide a way to limit 
the maximum message size *anyway*...at which point a separate maxline value 
doesn't make any sense, since the RFC specifies no maximum line size.

I'm much more comfortable setting a large maximum message size than setting a 
large enough maximum line size to permit that size of message consisting of 
mostly a single line.  Since we aren't going to back out the DDOS fix, we have 
to put the limit *somewhere*.  At least in 3.6 we can make it easy for the 
application to set it.  (Programs using earlier versions will just have to 
monkey-patch, unfortunately...which they have to do right now anyway.)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[shiyao.ma]

shiyao.ma added the comment:

Instead of setting a MAXSIZE for the email body, rasing up the MAXLINE might be 
more meaningful.


Consider the case of MAXSIZE, it's essentially the same as MAXLINE. If MAXSIZE 
is relatively small, some messages won't pass through. If the MAXSIZE is 
relatively large, then what's the meaning of setting it?


Thus, it might be more practical to increase the value of MAXLINE so that 99% 
messages can pass through.

--
nosy: +introom

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[R. David Murray]

R. David Murray added the comment:

It has been, see the referenced issue.  Now we just need someone to write a 
patch.

--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[R. David Murray]

R. David Murray added the comment:

Note that the max message size solution can be applied to the maintenance 
releases as a fix for this issue by choosing a suitable large default message 
size.  The 'feature' part is just the part exposing the size limit in the 
library API...that part is a feature for 3.6.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Stephen Coulson]

Stephen Coulson added the comment:

Broke for me today. Hacked the _MAXLINE to get around it.
I don't see any size limit on multi-line in rfc. Only requirement is 
dot-stuffing. I think this fix might need a rethink.

--
nosy: +scoulson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[Chris Smowton]

Chris Smowton added the comment:

Created #24706 to describe the unflushed connection problem.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[Chris Smowton]

Chris Smowton added the comment:

Why wouldn't that fix the problem? The issue is poplib not tolerating server 
behaviour seen in the wild, and if you limit by message size not line length 
you shouldn't see this problem?

(Side note, I'm surprised not to have been emailed when you replied, any idea 
what I'm missing?)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24706] poplib: Line too long error causes knock-on failure to retrieve all subsequent messages

[Chris Smowton]

New submission from Chris Smowton:

As mentioned in #23906, when poplib bails from receiving a message with a 'line 
too long' error it neither flushes nor re-establishes the TCP connection. This 
means that subsequent commands fail because instead of the expected response we 
receive part of the unflushed data from the message that triggered the original 
error.

--
components: Library (Lib)
messages: 247283
nosy: Chris Smowton
priority: normal
severity: normal
status: open
title: poplib: Line too long error causes knock-on failure to retrieve all 
subsequent messages
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24706
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[R. David Murray]

R. David Murray added the comment:

Sorry, I was unclear.  In order to implement maximum message size we have to do 
a bit more to the logic than just use the max message size as the readline 
limit.  But it does seem like the right approach to me.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Chris Smowton]

Chris Smowton added the comment:

+1 to the above; suggest this should be rolled back and replaced with a total 
message size limit.

--
nosy: +Chris Smowton

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[Chris Smowton]

Chris Smowton added the comment:

I found the same problem retrieving mail from my ISP's (unknown) POP3 server. I 
was sent an HTML email as one long 50KB line, which naturally broke everything.

Instead of limiting line length, I suggest you should limit total message body 
size, since that's what you're actually trying to defend against here. You 
could also either use the +OK XXX octets line to set a more conservative limit 
(and fail fast if it announces intent to send more than your limit).

As above the workaround was to insert import poplib; poplib._MAXLINE = 100 
at the top of the 'getmail' script.

A side-note: one message that is broken this way causes all future messages to 
fail because poplib does not flush the connection when bailing due to a 'line 
too long' error. If it isn't prepared to read the rest of the incoming data, it 
*must* hang up the connection and re-login to fetch the next message.

--
nosy: +Chris Smowton

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[R. David Murray]

R. David Murray added the comment:

Could you open a separate bug for the recovery problem, please?

Using a maximum message size would not solve this problem, but it would give 
the library user control of when it failed, so it is a good feature request.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Ingo Ruhnke]

Ingo Ruhnke added the comment:

This fix has broken mail retrieval from both gmx.de, gmail.com and plenty of 
other provider.

It manifests in getmail as:

Retrieval error: server for BrokenUIDLPOP3SSLRetriever:1860...@pop.gmx.net:995 
is broken; offered message 239 but failed to provide it.  Please notify the 
administrator of the server.  Skipping message...

After setting the _MAXLINE in /usr/lib/python2.7/poplib.py to something higher 
everything was working again.

See issue #23906

--
nosy: +Ingo Ruhnke

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[Ingo Ruhnke]

Ingo Ruhnke added the comment:

This also breaks mail retrieval from both gmx.de and gmail.com (two rather 
large and popular mail provider). After setting _MAXLINE 
in/usr/lib/python2.7/poplib.py to some arbitrary higher number mail retrieval 
from both services worked fine again.

This this 2048 does definitively looks badly broken.

--
nosy: +Ingo Ruhnke

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[R. David Murray]

Changes by R. David Murray rdmur...@bitdance.com:


--
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[R. David Murray]

R. David Murray added the comment:

The RFC is in fact not clear on this point.  It is entirely possible to read it 
as saying that each line of a mulitline response is limited to 512 octets.  I 
agree, however, that that is not the most reasonable interpretation.  Instead, 
the line length of RETR message lines should be governed by RFC 5322, which 
specifies a maximum line length of 998 octets.

That, however, means that technically dovecot is still broken, since 2048 is 
quite a bit larger than 998.  In reality, it means that the *internet* is 
broken, in that I presume the root of the problem is that there are mail 
originators out there that are not obeying RFC 5322 (and its 
predecessors...this limit goes back to 821/822).

We use 8192 in smtplib, and that hasn't caused any problems...but then again 
smtplib is originating email, not receiving it.  The IMAP protocol has its own 
problems, quite aside from the length of message body lines, so we ended up 
with a very large MAXLINE there.  It may be that we have no choice except to do 
something similar in poplib.

An interesting question in this context is what smtp servers do. since if 
anyone was going to reject messages with overlong lines, it would be the smtp 
server's job to do it.

--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23906] poplib maxline behaviour may be wrong

[Remy Blank]

Changes by Remy Blank remy.bl...@pobox.com:


--
nosy: +rblank

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23906
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21804] Implement thr UTF8 command (RFC 6856) in poplib.

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6ea762200e27 by R David Murray in branch 'default':
#21804: Add RFC 6856 (UTF8) support to poplib.
https://hg.python.org/cpython/rev/6ea762200e27

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21804
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21804] Implement thr UTF8 command (RFC 6856) in poplib.

[R. David Murray]

R. David Murray added the comment:

Thanks, Milan.

--
resolution:  - fixed
stage: commit review - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21804
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21804] Implement thr UTF8 command (RFC 6856) in poplib.

[R. David Murray]

Changes by R. David Murray rdmur...@bitdance.com:


--
stage:  - commit review
type:  - enhancement

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21804
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Roundup Robot]

Roundup Robot added the comment:

New changeset 339f877cca11 by Benjamin Peterson in branch '2.7':
in poplib, limit maximum line length that we read from the network (closes 
#16041)
https://hg.python.org/cpython/rev/339f877cca11

--
resolution:  - fixed
stage: patch review - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Matthias Klose]

Matthias Klose added the comment:

this looks ok to me, can we apply this for 2.7.9?

--
nosy: +doko

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Berker Peksag]

Berker Peksag added the comment:

Here is a patch for 2.7.

--
nosy: +berker.peksag
stage: needs patch - patch review
Added file: http://bugs.python.org/file36970/issue16041_27.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Berker Peksag]

Changes by Berker Peksag berker.pek...@gmail.com:


Added file: http://bugs.python.org/file36971/issue16041_27.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Berker Peksag]

Changes by Berker Peksag berker.pek...@gmail.com:


Removed file: http://bugs.python.org/file36970/issue16041_27.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Georg Brandl]

Changes by Georg Brandl ge...@python.org:


--
versions:  -Python 3.1

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Roundup Robot]

Roundup Robot added the comment:

New changeset 76be07730f8d by Georg Brandl in branch '3.2':
Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
https://hg.python.org/cpython/rev/76be07730f8d

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16041] poplib: unlimited readline() from connection

[Georg Brandl]

Changes by Georg Brandl ge...@python.org:


--
versions:  -Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21804] Implement thr UTF8 command (RFC 6856) in poplib.

[Milan Oberkirch]

Milan Oberkirch added the comment:

I got the Exception policy of the POP3 class wrong (ignore my review comment on 
that) and needed to add 'UTF8' to the list of optional commands.

--
Added file: http://bugs.python.org/file35823/poputf8-v2.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21804
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21804] Implement thr UTF8 command (RFC 6856) in poplib.

[Milan Oberkirch]

New submission from Milan Oberkirch:

The poplib classes already use Unicode internally (for everything but 
capability names). So to implement the UTF8 part of RFC 6856 we only need to 
enable the user to switch to UTF-8 mode if supported by the server.

--
components: email
files: poputf8.patch
keywords: patch
messages: 220956
nosy: barry, jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: Implement thr UTF8 command (RFC 6856) in poplib.
versions: Python 3.5
Added file: http://bugs.python.org/file35686/poputf8.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21804
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21804] Implement thr UTF8 command (RFC 6856) in poplib.

[Milan Oberkirch]

Changes by Milan Oberkirch milan...@oberkirch.org:


Removed file: http://bugs.python.org/file35686/poputf8.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21804
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21804] Implement thr UTF8 command (RFC 6856) in poplib.

[Milan Oberkirch]

Changes by Milan Oberkirch milan...@oberkirch.org:


Added file: http://bugs.python.org/file35687/poputf8.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21804
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12706] timeout sentinel in ftplib and poplib documentation

[Greg]

Greg added the comment:

In the definition of FTP.connect(), I've changed the code to actually use None 
as a lack-of-explicit-timeout sentinel instead of -999. For FTP and FTP_TLS, 
I've changed the documentation to reflect what the code is doing.

--
keywords: +patch
nosy: +εσχατοκυριος
Added file: http://bugs.python.org/file35524/patch.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12706
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20549] Use specific asserts in mailbox, smtplib and poplib tests

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1c3fcba31708 by Serhiy Storchaka in branch '2.7':
Issue #20549: Use specific asserts in mailbox, smtplib and poplib tests.
http://hg.python.org/cpython/rev/1c3fcba31708

New changeset bd1d6916b689 by Serhiy Storchaka in branch '3.3':
Issue #20549: Use specific asserts in mailbox, smtplib and poplib tests.
http://hg.python.org/cpython/rev/bd1d6916b689

New changeset 2e5e66f9e228 by Serhiy Storchaka in branch 'default':
Issue #20549: Use specific asserts in mailbox, smtplib and poplib tests.
http://hg.python.org/cpython/rev/2e5e66f9e228

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20549
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20549] Use specific asserts in mailbox, smtplib and poplib tests

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you for your review David.

--
assignee:  - serhiy.storchaka
resolution:  - fixed
stage: patch review - committed/rejected
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20549
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20549] Use specific asserts in mailbox, smtplib and poplib tests

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

The proposed patch makes the mailbox, smtplib and poplib modules tests use more 
specific asserts. This will provide more useful failure report.

--
components: Tests
files: test_mailbox_asserts.patch
keywords: easy, patch
messages: 210546
nosy: giampaolo.rodola, petri.lehtinen, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in mailbox, smtplib and poplib tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33974/test_mailbox_asserts.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20549
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20549] Use specific asserts in mailbox, smtplib and poplib tests

[R. David Murray]

R. David Murray added the comment:

Looks good to me.

--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20549
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20352] Add support for AUTH command to poplib

[Daniël van Eeden]

Daniël van Eeden added the comment:

As far as I understood the RFC:

A client should send CAPA and check if there is a SASL tag in the response 
(e.g. SASL PLAIN).

===
+OK Dovecot ready.
AUTH PLAIN base64_encoded_info
+OK Logged in.
LIST
===
I've replace the base64 encoded authentication info with 'base64_encoded_info'

For other authentication mechanisms the response can be longer (it may contain 
a challenge) and the request may only contain the mechanim.

I don't have a server which supports anything else than AUTH PLAIN, so I could 
verify/test this.

--
keywords: +patch
Added file: http://bugs.python.org/file33651/poplib_auth.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20352
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20352] Add support for AUTH command to poplib

[R. David Murray]

R. David Murray added the comment:

imaplib has an API for handling that kind of thing.  Maybe we can model the 
poplib support off of that API.  It would be nice to be consistent, assuming it 
in fact makes sense for poplib as well.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20352
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20352] Add support for AUTH command to poplib

[Daniël van Eeden]

New submission from Daniël van Eeden:

I use 'AUTH PLAIN secret' to login to a POP3 server with a proxy user. I 
can't use 'pass_()' as I need to supply a admin user and the user to proxy into.

class adminpopserver(poplib.POP3):
def auth(self, method, secret):
return self._shortcmd('AUTH %s %s' % (method, secret))

secret = {user}\0{adminuser}\0{password}.format(
user=user, 
adminuser=adminuser, 
password=password)
secret = secret.encode('base64').strip('\n')

--
components: Library (Lib)
messages: 208837
nosy: dveeden
priority: normal
severity: normal
status: open
title: Add support for AUTH command to poplib
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20352
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20352] Add support for AUTH command to poplib

[R. David Murray]

R. David Murray added the comment:

This is basically rfc 5034 support?  Sounds like a good idea.

I'm going to mark this issue as 'easy' because it isn't a whole lot of code, 
but for anyone who wants to tackle it, know that understanding the RFC and 
getting it *right* is not necessarily trivial, because: rfc :)

--
components: +email
keywords: +easy
nosy: +barry, r.david.murray
stage:  - needs patch
type:  - enhancement
versions: +Python 3.5 -Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20352
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19784] No SSL match_hostname() in poplib

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1ce752754280 by Christian Heimes in branch 'default':
Issue #19784: poplib now supports SSLContext.check_hostname and server name
http://hg.python.org/cpython/rev/1ce752754280

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19784
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com