Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #104505 > unrolled thread

How to program round this poplib error?

Back to article view | Back to comp.lang.python

Contents

  How to program round this poplib error? cl@isbd.net - 2016-03-10 12:04 +0000
    Re: How to program round this poplib error? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 12:30 +0000
      Re: How to program round this poplib error? cl@isbd.net - 2016-03-10 14:07 +0000
    Re: How to program round this poplib error? Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-10 13:23 +0000
      Re: How to program round this poplib error? cl@isbd.net - 2016-03-10 14:09 +0000
    Re: How to program round this poplib error? dieter <dieter@handshake.de> - 2016-03-11 10:06 +0100

#104505 — How to program round this poplib error?

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 <module>
        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
·

[toc] | [next] | [standalone]

#104508

On 10/03/2016 12:04, cl@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 <module>
>          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

[toc] | [prev] | [next] | [standalone]

#104521

Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 10/03/2016 12:04, cl@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 <module>
> >          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
·

[toc] | [prev] | [next] | [standalone]

#104515

On 2016-03-10, cl@isbd.net <cl@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).

[toc] | [prev] | [next] | [standalone]

#104522

Jon Ribbens <jon+usenet@unequivocal.co.uk> wrote:
> On 2016-03-10, cl@isbd.net <cl@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
·

[toc] | [prev] | [next] | [standalone]

#104596

cl@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 <module>
>         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=50000

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web