[Twisted-Python] Trouble with example imap client on unread messages
I'm having trouble running Twisted/doc/mail/examples/imap4client.py on imap folders which have unread messages. When the client issues: proto.fetchSpecific('1:*', headerType='HEADER.FIELDS', headerArgs=['SUBJECT'] ) My server is returning: * 243 FETCH (BODY[HEADER.FIELDS ("SUBJECT")] {47} Subject: DELIVERY REPORTS ABOUT YOUR E-MAIL ) * 244 FETCH (BODY[HEADER.FIELDS ("SUBJECT")] {42} Subject: AW: [syslinux] bug(?) in 2.11 ) * 244 FETCH (FLAGS (\Seen)) 243 is a previously read message, 244 is an unread message. The callback for the above fetchSpecific call is receiving: { 243 : [['BODY', ['HEADER.FIELDS', ['SUBJECT']], 'Subject: DELIVERY REPORTS ABOUT YOUR E-MAIL\r\n\r\n']], 244 : [['FLAGS', ['\\Seen']]] } ie, I'm not getting the subject for unread messages. Just wondering if this is a problem at twisted's end (is it incorrectly reducing the server response for 244 to [['FLAGS', ['\\Seen']]]?), my imap server (is it incorrect that my server is including the extra * 244 FETCH (FLAGS (\Seen)) line ? I'm using BincIMAP v1.2.12) or me :) (am I running something wrong here?) cheers, Andy.
Quoting Andy Gayton <andy@thecablelounge.com>:
I'm having trouble running Twisted/doc/mail/examples/imap4client.py on imap folders which have unread messages. When the client issues:
proto.fetchSpecific('1:*', headerType='HEADER.FIELDS', headerArgs=['SUBJECT'] )
My server is returning:
* 243 FETCH (BODY[HEADER.FIELDS ("SUBJECT")] {47} Subject: DELIVERY REPORTS ABOUT YOUR E-MAIL
) * 244 FETCH (BODY[HEADER.FIELDS ("SUBJECT")] {42} Subject: AW: [syslinux] bug(?) in 2.11
) * 244 FETCH (FLAGS (\Seen))
The problem I see is here : why does the server had this line ? It doesn't seem to be an answer, but more the consequence of the fetch (which mark messages as seen). This message should appeared *after* fetch called... Maybe Bincimap is too fast :). You could try this instead (which don't mark message seen) : proto.fetchSpecific('1:*', headerType='HEADER.FIELDS', headerArgs=['SUBJECT'], peek=True )
243 is a previously read message, 244 is an unread message.
The callback for the above fetchSpecific call is receiving:
{ 243 : [['BODY', ['HEADER.FIELDS', ['SUBJECT']], 'Subject: DELIVERY REPORTS ABOUT YOUR E-MAIL\r\n\r\n']], 244 : [['FLAGS', ['\\Seen']]] }
ie, I'm not getting the subject for unread messages.
Well actually it's logical, because Twisted parses result in a dictionnary so you have : res[243] = < subject >, then res[244] = < subject >, but res[244] = < flags > which overrides previous value.
Just wondering if this is a problem at twisted's end (is it incorrectly reducing the server response for 244 to [['FLAGS', ['\\Seen']]]?), my imap server (is it incorrect that my server is including the extra * 244 FETCH (FLAGS (\Seen)) line ? I'm using BincIMAP v1.2.12) or me :) (am I running something wrong here?)
I would say it's server fault, but if Twisted can cope with it it's better. -- Thomas
In a message of Fri, 08 Jul 2005 10:36:32 +0200, Thomas HERVE writes:
Quoting Andy Gayton <andy@thecablelounge.com>:
* 244 FETCH (FLAGS (\Seen))
The problem I see is here : why does the server had this line ?
The flags changed, and the server is telling you about it, as it should.
The callback for the above fetchSpecific call is receiving:
{ 243 : [['BODY', ['HEADER.FIELDS', ['SUBJECT']], 'Subject: DELIVERY REPORTS ABOUT YOUR E-MAIL\r\n\r\n']], 244 : [['FLAGS', ['\\Seen']]] }
ie, I'm not getting the subject for unread messages.
Well actually it's logical, because Twisted parses result in a dictionnary so you have : res[243] = < subject >, then res[244] = < subject >, but res[244] = < flags > which overrides previous value.
This is bad, RFC-3501 says: A client MUST be prepared to accept any server response at all times. This includes server data that was not requested. Server data SHOULD be recorded, so that the client can reference its recorded copy rather than sending a command to the server to request the data. In the case of certain server data, the data MUST be recorded. so I'd say twisted's IMAP-client is broken. /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | iko@cd.chalmers.se Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87
Quoting Andy Gayton <andy@thecablelounge.com>:
proto.fetchSpecific('1:*', headerType='HEADER.FIELDS', headerArgs=['SUBJECT']
Thomas HERVE wrote:
The problem I see is here : why does the server had this line ? It doesn't seem to be an answer, but more the consequence of the fetch (which mark messages as seen). This message should appeared *after* fetch called... Maybe Bincimap is too fast :).
You could try this instead (which don't mark message seen) :
proto.fetchSpecific('1:*', headerType='HEADER.FIELDS', headerArgs=['SUBJECT'], peek=True )
Thanks Thomas, this workaround does work. I'm sure there's going to be trouble down the track when I need my actions to change the state of the messages, but it at least confirms what you and Anders observed. Anders wrote:
This is bad, RFC-3501 says: A client MUST be prepared to accept any server response at all times. This includes server data that was not requested. Server data SHOULD be recorded, so that the client can reference its recorded copy rather than sending a command to the server to request the data. In the case of certain server data, the data MUST be recorded.
so I'd say twisted's IMAP-client is broken.
I agree with Anders. But man, what a bitch to handle :) Actually this reminds me of a reply to an excellent intro to twisted clients thread which featured an imap client: http://twistedmatrix.com/pipermail/twisted-python/2004-May/007781.html Ideally I guess the message's subject should be passed to the callback, as expected, and a method call should be triggered for the change in the messages status. I've raised a bug for it: http://twistedmatrix.com/bugs/issue1105 Hope this is ok .. cheers, Andy.
participants (3)
-
Anders Hammarquist -
Andy Gayton -
Thomas HERVE