I have been trying to find the way to read the inbound and outbound emails prior reaching the recipients and if the email contains sensitive data, I would modify or rather stop delivering or quarantine that email.
Also, is there any admin setting to schedule send all the email send from org(basically delay sending the emails). I'm aware that this functionality is available in user's mailbox, want to now if any admin setting is available which can be enabled by default for all emails.
I have integrated messages.get and webhook's to fetch all the emails, but those are all either emails which are already delivered. Is there any api or way to detect sensitive emails in real time before getting delivered?
Related
I have very limited knowledge about SMTP and IMAP/POP. SMTP --> sending message, IMAP--> Mainly for receiving messages.
I have a woocommerce website and i already did setup my email system to use SMTP relay using zoho. I believe zoho also provide mailbox services since I am able to communicate with my customer(both two and fro) using its email service. They have their app and i can receive and send mail from that app. Obviously, I have set up all the records including MX to send/receive the email to my zoho inbox.
No i want to move my email services to postmark or like sendinblue. All i can see the setting related to sending the mail but how/where will I receive the mail when user reply on that??
On the postmark website it says:
Since Postmark is not a mailbox provider there's not the ability to generate mailboxes for receiving email using IMAP or POP3.
Question 1) Does the SMTP relay server is actually a different physical machine from IMAP server for sending/receiving messages. I guess both are different but why are these companies not providing solutions like zoho. Pardon me if I did not understand the use case.
Question 2) What to do in this case ???. My case is simple. I send notifications to customers regarding their orders. If they want they can reply or enquire. I receive the email on my phone and I can reply on the same mail-chain like we have on Gmail.
Question 3)
Do i need to buy some another service along with these to receive and reply back on the email ??? Like from godaddy or somewhere else.
I have a web application wherein our users create contracts and we have integrated with DocuSign through an embedded recipient experience.
My web application is fairly involved in gathering the appropriate signers, sending emails, requesting signatures, keeping up with signer statuses, etc., and so I believe that an embedded recipient experience makes the most sense for us.
However, our first client using the integration has already been using DocuSign for some time and their signers (CEOs, CFOs and the like) are accustomed to logging into DocuSign, seeing envelopes in their inbox and clicking on them to sign - which is only possible in an integration by adding them as remote recipients. Embedded recipients cannot be associated to a DocuSign user account.
I'd like to keep using embedded recipients, but my client desperately wants to see envelopes created from my application in their DocuSign user account inbox and sign them from there without first having to log into my application.
Is there any clever way to deliver such a request with an embedded recipient experience? Even an atypical workaround, like sharing documents between the embedded recipient and the user account or some other recipient type of which I'm not aware, etc.?
Unfortunately not. When creating an embedded signing session the recipient becomes what's referred to as a Captive Recipient. Captive Recipients follow a different set of rules in regards to email notifications and presence in an inbox.
For example, Captive Recipients don't receive email notifications by default -- but they can supply an email to be CC'ed onto the envelope.
Since the Captive Recipient also has a universal account number, the user is technically part of an account outside of yours or your recipients.
IE: Your recipient views his inbox linked to his userId on account XXXXXXXXX.
The Captive Recipient is part of account YYYYYYYYYY with its own unique userId, so there's nothing for it to match up to.
If your app relies on embedded signing to load DocuSign envelopes into something like an iFrame, you can still do that without using an embedded recipient, which would give you the ability to load them through your webApp as well as let your signer access them via his DocuSign inbox.
To retrieve the signing URL, you make a POST call to https://{endpoint}.docusign.net/restapi/v2/accounts/{accountId}/envelopes/{envelopeId}/views/recipient with the following call body:
{
"returnUrl": "http://localhost/returnUrl",
"authenticationMethod":"email",
"email": "{recipientEmail}",
"userName": "{recipientFullName}",
"recipientId":"{recipientId}"
}
I'll like to process incoming email on a specific email. In aws docs it says
Although you are not required to publish an MX record to receive mail through Amazon SES, if you don't publish the record, Amazon SES will receive mail for your domain only if you explicitly route it to Amazon SES.
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiving-email-mx-record.html
How do I explicitly route email to SES?
After hours of research and failed attempts of having SES receive emails without the use of a MX record (had set up an additional Route via gSuite / Google Apps), here is my best suggestion on how to go about this.
Short Version
Create a subdomain and point its MX record to SES after inserting the TXT verification record. After creating the necessary ruleset to receive and save email from any#sub.domain.com, you can now have SES receive email from any email address you own (even if it's not verified with SES) by simply forwarding its emails to the SES enabled subdomain email address.
Long Version
Unfortunately, it does still require an MX record, but check it out...
You can create a custom subdomain on your primary domain and call it anything. In my case, I called it ses.mydomain.com
Next, I added my newly created subdomain to SES via the Domains link.
Immediately upon adding it as a domain to SES, a pop-up window appears displaying the required TXT verification record and MX mail record.
Shortly after assigning these two DNS records to my subdomain, the subdomain is verified and able to receive email after setting a few quick rules via Rule Sets!
Here's the cool part - you can still have SES receive email from any email address you have access to.
How you might ask?
By just setting up a forwarder on the email address you do want to send to SES, by forwarding it to the SES-enabled subdomain email address.
Meaning - If SES is able to receive email from someone#ses.example.com, but you want it to actually receive email from someone-else#example.com, then all you need to do is forward someone-else#example.com to someone#ses.example.com!
Remember, you still need to create the necessary rules to receive emails. See this AWS Blog Post for more information.
Use one of the AWS SES's inbound endpoints:
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/regions.html#region-select
e.g. for US-EAST-1 the inbound endpoint is inbound-smtp.us-east-1.amazonaws.com. For receiving only you do not use SMTP endpoints. The procedure is pretty much the same using MX records or not: somewhere (in your DNS or in your mail handling system) you must point to a SES inbound endpoint.
For example, my MX records point to Google Apps, but using 'Hosts' and 'Routing' (inside Google Apps/Gmail options) I managed to relay only one recipient to SES. So every e-mail my domain receives goes to Gmail recipients as usual, except for one special_recipient#mydomain.com which I relayed to SES (which, in turn, goes to SNS then to SQS).
from:
https://aws.amazon.com/blogs/aws/new-receive-and-process-incoming-email-with-amazon-ses/
Now you need to route your incoming email to SES for processing. You have two options here. You can set the domain’s MX (Mail Exchange) record to point to the SES SMTP endpoint in the region where you want to process incoming email. Or, you can configure your existing mail handling system to forward mail to the endpoint.
An app that I'm developing needs to test whether, for a given email address, the user has previously sent or received email from the address on the user's gmail account. However, this should be done without the app having the credentials to the google account, and without allowing the app to get any other information other than a true/false result to such a query.
How can this be achieved?
The solution should, if at all possible, use some existing google service to minimize or even completely avoid setting up my own server app to facilitate this.
An initial idea I had for this: use a google apps script that will get an authorization by the user to access email, and then scan all emails to collect the set of unique recipients and senders. Then, those emails will be saved in such a way that some URL handler can practically instantly respond to a query about whether or not a specific email exists in this set.
It's a better architecture to have the app query Gmail directly for this information, instead of using an Apps Script web app as an intermediary. The new Gmail API's Users.messages.list() method allows you to search for messages, and the q parameter takes the same types of queries that the Gmail UI supports, such as "to:person#example.com". Additionally there is a read-only scope supported by the API, so that users can feel more comfortable with the app gaining access to their inbox.
I am using MailApp.sendEmail to send mail FROM:SEND#example.com and TO: RECEIVE#example.com
The SEND#example.com inbox automatically forwards all incoming mail to various other addresses in my organization.
The unintended consequences are that even though I only want these emails to be delivered to RECEIVE#example.com, they are automatically being forwarded to all of the email addresses that SEND#example.com forwards to as well.
This doesn't seem logical, as it is an outgoing email and if I simply send an email from the SEND#example.com inbox normally, the sent mail does not get forwarded.
Can anyone explain why this happens and/or a way around it?
I believe it happens because the copy google's servers (running the apps script) places in the sending account's mail folders is treated by gmail as a new incoming message that just happens to have the from field set to be that account itself. It then performs whatever rules it always performs on incoming messages.
You can set your rules for that gmail account to forward except in the case that the from address is your own email address. When you create the filter enter "-SEND#example.com" in the from field.