What is the difference between account hooks and folder hooks in Mutt? If I understand Mutt correctly, it can only have one IMAP connection open at a time. So why can't I just let an account hook to set up everything?
What needs to be set in account hooks and what should be left for folder hooks and why?
As explained in the section Managing Multiple Accounts of the mutt HTML manual, the difference between folder-hook and account-hook lies in the fact that folder-hook is triggered when a folder is opened whereas account-hook is triggered whenever mutt tries to connect to the remote server of a mailbox, this happens both when you open a folder but also when you browse the list of your mailboxes (i.e. folders).
Related
We have a script that checks a Gmail inbox for new messages, processes any it finds based on the subject and sender, marks said messages read, and then after processing moves the messages to a folder called "ProcessedMessages". This script has been running for several years without incident.
We recently migrated to Azure, and this script began failing on the last command:
<cfimap action="movemail"
connection="myConnection"
MessageNumber="#x#"
newfolder="ProcessedMessages">
This line started generating this error every night:
The cause of this exception was: java.lang.IllegalStateException: This operation is not allowed on a closed folder.
I'm not sure what a closed folder is, but we have tried:
Closing any Gmail browser window on any computer logged in as this account.
Running the process manually by hitting the url to make sure the task scheduler wasn't the problem.
Running the process from a browser window on the server itself pointing to it's own IP to make sure the new CF cluster wasn't causing the problem.
Looking around Gmail for some sort of 'closed' flag associated with a folder
Moving the messages from the inbox to that folder via the Gmail web interface to make sure there wasn't an account problem (it worked fine)
No changes were made to this Gmail account since the switchover to Azure; in fact no one had even logged into it for at least a month before. The username and password are set correctly on the new Azure server, as evidenced by the fact the script can log in and read message and mark them read.
What does this error message mean and what could cause it?
This is what I found (same issue):
"A common cause of this kind of issues is that the folder is being modified concurrently using the same account and credentials thus leaving the operations in an inconsistent state." from here:
https://help.mulesoft.com/s/article/Intermittent-IMAP-S-error-This-operation-is-not-allowed-on-a-closed-folder
In my case, it's running every 15 seconds, on 3 different email folders, so it would make sense.
I hope this clarifies the reasons for the issue.
I am pretty sure my understanding is correct but since I cannot find any Google documentation that explicitly highlights this I wanted to ask here.
Per https://developers.google.com/apps-script/guides/triggers/installable:
Installable triggers always run under the account of the person who created them.
And we know that when you create a trigger it will ask to authorize for all the scopes the script uses.
Then, that means that anyone with edit access to the script could leverage the Google identity of the user used to create the trigger to access the scopes the trigger is authorized for.
For example:
User 1 creates a Google Apps Script that uses GmailApp to send an e-mail
(i.e. GmailApp.sendEmail("one#example.com", "test subject", "email body");)
User 1 creates a trigger to run said script every hour and authorizes it with the appropriate GmailApp scopes
User 1 gives User 2 edit access to said script
Now, User 2 can go into said script and make changes to the code and access User 1's Gmail account. For example, user 2 could change the code to:
var emails = GmailApp.search("search string to find sensitive emails")
// use GmailApp.sendEmail to forward those details to someone else like User 2
All they would have to do is make changes to the code and save; they wouldn't need to re-create the trigger since it already exists. And the next time the trigger runs it would run the newer/updated code.
I was able to confirm this behavior by creating a test script on one of my accounts and giving another account edit access.
So my question is, what is the official/recommended way to mitigate this risk? The obvious answer is to not give anyone else edit access but what if that is not an option -- what if for support purposes multiple people need to be able to access the script, then what?
As you say, the only official/recommend way is to limit editing access to trusted persons.
In your particular example, User 1 could have chosen MailApp instead of GmailApp. The two seemingly redundant services are available separately because MailApp has very limited privledges exposed compared to GmailApp. (For instance, User 2 cannot search the victims Gmail with the MailApp service.)
You can collaborate while avoiding giving direct access to your script file using clasp and git. Only you push with clasp to the script. Everyone else submits changes through git. You can setup the system to be fully automatic (i.e. a git push triggers a clasp push) or manual (i.e. you review all changes first), bit either way you have good records of who did what, when with git.
There's inherent trust when you provide edit access to the script project. You either trust the person or don't trust them. There's no inbetween.
Some "theoretical" ways you may still protect the data:
Create and use different Google accounts.
Install Triggers at the specific deployment/not at Head:
Possible only if done manually. Installable triggers created programmatically can only be used at Head
When you deploy a web-app/api, You can deploy it a specific version.
This deployment version can then be provided, When you create a new trigger for a project here.
There is no need for a working web-app/api. We're only looking to get a deployment id.
In this way, even if user changes the script, your trigger will only run at the old version deployed.
Deployed versions can be seen at Publish> Deploy from manifest.
As the previous answer states, git would be a better call.
For all practical purposes, any data you share with a malicious entity should be considered compromised.
I'm just getting started with the Outlook REST API. My baseline is the tutorial that uses node-outlook.
First order of business is to retrieve all of the folders in my mail account.
So I issue this REST request:
GET https://outlook.office.com/api/v2.0/Me/MailFolders
Instead of returning all of my folders, it only returns the "well known" folders:
Clutter
Deleted Items
Drafts
Inbox
Junk Email
Outbox
Sent Items
Trash
Am I missing a query parameter or something that says, "no, really, all of them please"?
UPDATE
I tried a different email account, and I also don't get all of my actual folders, but I get a different subset (some of which are well-known, others aren't).
I am implementing the paging protocol (using the #nextLink parameter) so it's not a matter of page sizes. I am getting these 8 folders on one account, and 18 folders on another.
So there must be something that decides what folders will be returned.
UPDATE 2
I changed to doing a folder sync instead using the "beta" API. In this case, I also get an unnamed folder in the list, which is the parent of the other folders. It comes along with a ChildFolderCount which is accurate. However, when I do a child folder request on that folder id I get the same list.
UPDATE 3
Here's the request url I'm using when I attempt to read the child folders of the one folder that comes back with a non-zero ChildFolderCount.
GET https://outlook.office.com/api/beta/Me/MailFolders/AAMkADRmMzFmNjZmLWU3MjctNGZiNi1iZTg4LTRmNGQwYTVhMDgxYgAuAAAAAAB8IxaZ5KGbQom4EPywGCSdAQDVy0eYwAzLS63k5pohzykCAAAAAAEJAAA=/childfolders
Here's what appears to define what folders are returned by this API and what are not:
If I create a folder in office365 directly on outlook webmail, it shows up in this query.
If I create a folder in Mac Mail, it does not.
Mac Mail accesses the service using EWS, so I would expect a folder created by it would be like any other folder.
So there is something about folders created on Mac Mail that prevents them from being returned by this API.
Folders created in Mac Mail DO show up in web mail and vice versa.
Folders created on an iPhone DO show up, so in my limited testing it looks like Mac Mail may be the only app suffering from this problem. The problem I have is most of my folders were created in Mac Mail and I have no easy way of rebuilding them.
I'm thinking this is just a BUG in the API. At any rate, this answers my original question and should help anyone out there trying to use the new API.
If I find a workaround I'll post it here.
I am creating an application in which I need to delete mail using IMAP in gmail. But when I set the flag to delete the message moves to spam folder instead of trash or directly deletion. Is there any way to move message to trash?
UPDATE
Now my messages are moving from inbox to important folder. I'm sending message to my self( in web browser) and it's marked as important by default.
There is a Google support site that says "Do NOT save deleted messages to your [Gmail]/Trash folder because this will delete a message in all folders." - so you might want to do exactly that :)
Adding onto flob's answer
the following folder paths works too
it seems like it's depending on when the user sign up for gmail
"[Gmail]/Trash"
"[Google Mail]/Bin"
"[Gmail]/Bin"
I would like to setup fetchmail or getmail to pull email from Gmail. I would prefer it to be IMAP but I can live with POP as well. The issue I'm running into is that all these seem to want you to specify the exact list of folders you want checked (this is cleaner in IMAP than POP).
This is a hassle since I frequently change my list of folders and when I do, I don't want to have to change my configuration file to add/remove folders. When something changes, I automatically want a mbox or a maildir directory to 'show up' with the contents of my new folder. I would also prefer the mbox to have the same name as the folder on the server
The closest thing I could find was the -r option in fetchmail but that doesn't seem to do this either. I'm sure I must be missing something since every email client is able to do this and I'm hoping that that functionality lives inside the MRA and not in the MUA.
Update: I'd like to move this thread to Serverfault and I'm ok with voting to close this and migrate. Unfortunately, I dont have the rep to do it myself yet
With getmail you can use the following line in your configuration to get all your mail :
mailboxes = ("[Google Mail]/All Mail",)
With IMAP you can list the folders on the server, that way email clients can do whatever they need. In getmail it depends on how the email retrievers are written. If this configuration does not work, you can check the IMAP retriever code and write a specific one that suits your needs ;-)
my 2 cents
PS: I have no getmail installation to check if that do the trick ...
You could look into imapsync. It is designed to recursively sync up IMAP accounts. You will need an IMAP account for the destination. I have not tested it with gmail but if gmail is a well behaved IMAP server it should work.