I noticed that the module was not able to delete the email after they are retrieved into my drupal.
In order to solve this issue I had to do the following changes in mailhandler.retrieve.inc

This approach should be done for users who has pop3 account and not imap since it should delete normally.

  if ($mailbox['delete_after_read']) {
	if( !imap_delete($result, $i, FT_UID))
	 watchdog('mailhandler', 'Failed to delete messages from the inbox account', 0, WATCHDOG_NOTICE);
	 else
	 imap_expunge($result);
  }

Why to do this??
after checking the php manual i noticed the following note for the function IMAP_DELETE()

Note: POP3 mailboxes do not have their message flags saved between connections, so imap_expunge() must be called during the
same connection in order for messages marked for deletion to actually be purged.

good luck

CommentFileSizeAuthor
#2 mailhandler_pop_deletion.patch632 bytesneochief

Comments

Jean-Philippe Fleury’s picture

Jean-Philippe Fleury commented

I have this bug too with Drupal 6.13 and Mailhandler 6.x-1.8.

neochief’s picture

neochief commented
Version: 5.x-1.x-dev » 6.x-1.x-dev
Status: Patch (to be ported) » Needs review
StatusFileSize
new mailhandler_pop_deletion.patch632 bytes

Fix for 6.x

awolfey’s picture

awolfey commented

Works for me.

chrisfromredfin’s picture

chrisfromredfin
he/him/his
Primary language English
Location Portland, Maine
commented
Status: Needs review » Reviewed & tested by the community

I independently came to the exact conclusion of this patch, and THEN found this issue.

Ian Ward’s picture

Ian Ward commented
Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

In 6.x-1.8 this should work without the patch (it seems to be working for me using a pop3 account). When run from cron, one connection is open, messages are processed, and then the connection is closed using imap_close($result, CL_EXPUNGE); (http://www.php.net/manual/en/function.imap-close.php "If set to CL_EXPUNGE, the function will silently expunge the mailbox before closing, removing all messages marked for deletion. You can achieve the same thing by using imap_expunge()")

I have a few questions for anyone w/ this problem to make sure the corner cases are covered:

1) Are any of you using a gmail account for your mailhandler mailbox? I ask because there is a separate issue whereby gmail has a custom method for deleting messages from their mailboxes which should be handled in a future version of mailhandler
2) When you say messages are not getting deleted, are they remaining in your inbox, or getting moved to trash/bin, and just not getting emptied from trash/bin?
3) Can you test and see if you notice this problem when retrieving via cron as well as when retrieving using the UI?

Thanks,
Ian

awolfey’s picture

awolfey commented

I was testing with a gmail account and a private server account. I'll double check when I come back to this.

tsaker’s picture

tsaker commented
Version: 6.x-1.x-dev » 6.x-1.8

I'm experiencing the same issue as initially reported. I'm using a Gmail POP3 account and the messages don't get deleted nor marked as read. I double-checked the Mailhandler settings to verify the 'Delete messages after they are processed?' flag is enabled.

Configuration:
- Drupal 6.14
- Mailhandler 6.x-1.8
- OG Mailhandler 6.x-1.x-dev

Jean-Philippe Fleury’s picture

Jean-Philippe Fleury commented

Hi Ian,

Here are my answers to your questions:

1) Are any of you using a gmail account for your mailhandler mailbox?

No, I don't.

2) When you say messages are not getting deleted, are they remaining in your inbox, or getting moved to trash/bin, and just not getting emptied from trash/bin?

The messages are remaining in the inbox. They're marked as read, but each time Mailhandler retrieves messages, it retrieves all those (read or not) found in the inbox, so it creates duplicate content.

3) Can you test and see if you notice this problem when retrieving via cron as well as when retrieving using the UI?

It seems that the problem occurs only when I'm using the UI. Via cron, the messages are well deleted.

chrisfromredfin’s picture

chrisfromredfin
he/him/his
Primary language English
Location Portland, Maine
commented

I would mostly mimic #9:
- not using GMail (using Dovecot)
- remaining in the inbox
- not sure, but cron seems overall more reliable than "retrieve"

We were able to get IMAP running on Dovecot and so we've moved away from this issue a litte.

sheldon rampton’s picture

sheldon rampton commented

I'm having the same experience as #9 and #10. I'm not using GMail, and messages are not getting deleted when I use "retrieve," thus creating duplicate content. However, cron does delete the messages. I've tried this and gotten the same result with two different POP3 accounts using different internet service providers.

I'm not sure I understand all of the code in the mailhandler module, but it looks to me like the mailhandler_cron_retrieve() function is working as expected, while the mailhandler_admin_retrieve() function is not. I would guess that the problem is probably with the following lines of code (lines 717-721 at the end of the mailhandler_retrieve_message() function):

  // If using batch API, must close imap stream.  Cron uses single stream.
  $args = func_get_args();
  if (!$args[0]) {
    imap_close($result, CL_EXPUNGE);
  }

It looks to me like this code is testing to see whether mailhandler_retrieve_message() was called using the batch API. If the answer is yes, it is supposed to run imap_close. However, the batch API does pass arguments to the mailhandler_retrieve_message() function, so wouldn't that test fail?

Ian Ward’s picture

Ian Ward commented
Status: Postponed (maintainer needs more info) » Fixed

Thank you everyone for the additional information. During UI retrieval:

  if (!$args[0]) {
    imap_close($result, CL_EXPUNGE);
  }

was indeed not getting reached. I committed a change to check a different way whether UI retrieval is being used. A small additional change was then needed to fix the message number when using POP and using UI retrieval.

This is now fixed in HEAD and should be available in the dev version soon.

sheldon rampton’s picture

sheldon rampton commented

Incidentally, the fact that messages are NOT deleted during UI retrieval is actually coming in handy for me right now while I'm building and testing a module that uses hook_mailhandler. It lets me develop my code without having to send a new email every time I want to test an iteration.

Maybe it's worth developing this bug into a feature, such as a check box that people can use to disable message deletion. :-)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.