Reputation: 642
I'm trying to fetch unread messages from IMAP. When I'm trying to parse email content I get len(email_message.keys()) == 0
. So that I never get From
, To
and Subject
.
Printed email (email.message_from_string(email_str)
):
From nobody Fri Sep 14 13:42:50 2012
1 (RFC822 {1015}
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from ec2.....amazonaws.com (unknown [IP])
(Authenticated sender: [email protected])
by domain.com (Postfix) with ESMTPA id EACD436CF
for <[email protected]>; Fri, 14 Sep 2012 12:47:54 +0000 (UTC)
DKIM-Signature: ....
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: [email protected]
To: [email protected]
Subject: welcome
Dear recipient,
Welcome.
Best,
Robot
And here's the code:
def fetch_new_emails(host, port, user, password):
conn = imaplib.IMAP4(host=host, port=port)
try:
(retcode, capabilities) = conn.login(user, password)
conn.select(readonly=1) # Select inbox or default namespace
(retcode, messages) = conn.search(None, '(UNSEEN)')
results = []
if retcode == 'OK':
for message in messages[0].split(' '):
(ret, raw_email) = conn.fetch(message, '(RFC822)')
if ret == 'OK':
print raw_email[0]
email_str = string.join(raw_email[0], "\n")
email_message = email.message_from_string(email_str)
email_from = email_message['From']
to = email_message['To']
subject = email_message['Subject']
results.append({
'from': email_from,
'to': to,
'subject': subject})
except:
print sys.exc_info()[1]
sys.exit(1)
finally:
conn.close()
return results
The problem:
print email_message['From']
>>None
print email_message['To']
>>None
print email_message['Subject']
>>None
Upvotes: 1
Views: 332
Reputation: 189948
There's a weird empty line after the From nobody...
line. Technically an empty line is the end of headers, and everything after that is body, so the message really doesn't have those headers.
Anyway, an IMAP message should not have a From
line (this is typical of Berkeley mbox format, which few IMAP servers use; and even if yours does, this detail of its storage implementation should not be visible to IMAP clients).
The weird 1 (RFC822 {1015}
line doesn't belong, either; it looks vaguely like part of an IMAP protocol response, not part of the actual message. The message proper starts with the Return-Path:
header in this particular case.
Is the IMAP server and/or the client code not production versions?
Upvotes: 2