1

I have a Mail.app rule script that worked fine in Mac OS X Snow Leopard. It is simply a script that allows for AND/OR boolean logic combined together to trigger one (rarely two) of the following actions:

  1. Move message to archive folder
  2. Delete email message (move to trash)
  3. Forward the message to someone
  4. Color the message (to signal importance)

You can review the script here. The bulk of the script is made of the boolean conditions I’m looking at (and yes, I know my multiple 'else if's' could have been combined into fewer if statements, but I just found it easier to have each ‘condition’ that I’m looking for in its own if statement).

In Snow Leopard, everything worked fine, but in Lion I get some strange behavior. My Inbox gets tricked/stuck thinking it has emails to download. Basically every message that would have been ‘moved/deleted’ somehow doesn’t get flagged as processed on my POP3 server. So every time I get mail, I see the following under Mail Activity: ‘Incoming Messages… X of Y’ (where Y is the growing number of emails affected by my script), yet nothing new is downloaded.

If I turn my Mail Rule off that runs the script, all emails are re-downloaded again into my Inbox. A few points of note:

  • I’m connecting to POP3 accounts
  • I used to use Growl 1.2.2, but I disabled that on a hunch that it wasn’t compatible with Lion. You’ll still see a sendGrowl function in the script, but you’ll notice that the entire function body is commented out.

Any suggestions or ideas on how to get this working again so I could tame my inbox would be EXTREMELY appreciated.

|improve this question
  • I don’t actually have a POP3 account to test this against (can’t even remember when I last used POP3 … must have been more than 10 years ago), but one issue might be that POP3 does not actually support folders; what happens when you file a POP3 received mail into a folder is that you file it in folder in your client’s local storage. Lion’s Mail.app, a rather drastic upgrade to previous versions, might have changed how these are handled, like asking for something along the lines of mailbox "foo" of account "Local" instead of simply "mailbox "foo". – kopischke May 22 '12 at 12:28
  • Unfortunately, I'm stuck with POP3, I know it stinks...I'm ashamed. The behavior of all my POP3 accounts in Mail.app preferences is to 'Remove copy from server after retrieving a message' when...'Moved from Inbox'. After discovering it was 'Moved from Inbox', I checked what settings were in Leopard because I usually say 'immediately'. It looks like default in Leopard is 'Immediately' and mine may have changed when I set up Lion, not sure. In any case, I've tried 'Immediately' as well, and I get the same behavior. I'm not exactly following what you are saying with your last statement. – Terry May 23 '12 at 20:56
  • I was referring to AppleScript technical details … never mind, for the time being :).. Your script is logging errors to ~/Library/Logs/AppleScript-events.log – what do you find in there after running it? – kopischke May 24 '12 at 14:53
  • oh, and another question: how many mail accounts are configured in Mail.app? Only the one POP account? – kopischke May 24 '12 at 19:28
  • I have 2 POP accounts that will be affected by rules. And I have no AppleScript-events.log file, so assuming no 'errors' (according to AppleScript) are occurring. I'm not getting the dialog about 'logging error' either, so pretty sure nothing is triggering log_event(). No IMAPI accounts configured FYI. – Terry May 25 '12 at 2:05
1

Judging from your description of the issue, it seems that Lion’s Mail.app has difficulties correctly executing a move AppleScript action on a PO3 server (or maybe just your POP3 server – not having a POP server to test myself, I cannot check). A solution could be to separate the two components of the move operation by replacing the line

move eachMessage to mailbox "Archived/BTR Monitoring Emails"

with

copy eachMessage to mailbox "Archived/BTR Monitoring Emails"
delete eachMessage

in the hope that an express deletion command will fare better. If that doesn’t alleviate the issue (because the deletions suffer from the same issue – I can’t say for sure from your question), you could also try setting the delete status of the message instead of sending it a delete command, i.e.

copy eachMessage to mailbox "Archived/BTR Monitoring Emails"
set deleted status of eachMessage to true

though I’m not entirely sure how that will go down within a POP server (it sounds like something designated for IMAP).

Finally, you could try commenting out the set read status of eachMessage to true lines in the filing and deletion blocks – this should, by rights, not affect the server, as POP3 has no notion of a “read status” (you need IMAP to store that server side), but it might conceivably be an issue if Mail’s AppleScript thinks otherwise. Setting the message status to read can also be achieved within a rule without resorting to AppleScript, so removing this from the script should be a non-issue.

|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .