Platforms like upwork have a feature where when you get a message through those platforms, you also get an email.
Instead of logging Upwork to reply, the user can simply reply to the incoming email, and the message is then automatically sent by upworks backend to the original person who sent the message.
How exactly is this done in a way that Upwork knows the inbox to send the message to, and is able to receive a message via email.
It seems Upwork handles incoming emails by detecting any project ID in the email message - it can be an ID in the subject or in the email body and etc. So, the email can be recognized easily and processed. Also additional information can be checked on the incoming email - the sender (whom the original emails was sent out), the recipient and etc. Actually, it is up to your needs how algorithm should be working.
Related
I tried to send an email through sendgrid. I have a custom domain myself#contoso.com. If i try to send an email to user1#gmail.com with the from address as myself#contoso.com,then,the email is delivered to gmail with "via". When i try sending email to myself#contoso.com with the from address being myself#contoso.com the activity says the email is delivered however, in outlook client i have not received the email. What is it that I can try or do?
I have tried whitelisting contoso.com but it did not work
This is not an answer, as it doesn't help work out why the emails that are "Delivered" have not been received, but this is SendGrid's note on why Email messages with the “Delivered” status are not received:
Twilio SendGrid posts the Delivered event after the destination server accepts the message with a 250 OK response. Once an email is accepted by the destination server, we are unable to see what happens to the message. The receiving server could send it to the inbox, queue it for later delivery, put it into the spam folder, etc.
Often times, a recipient domain will initially accept a message for delivery, and then apply additional filtering afterwards. In this situation, we would have posted the Delivered event, but not have any insight into the additional filtering. Any additional Twilio SendGrid events for your email message would be triggered by recipient engagement (i.e. open/click events, unsubscribes, etc.).
Also note that at the time of writing, that answer had 26 downvotes (and zero upvotes) on the SendGrid website, probably indicating that many other users have experienced this problem.
I had several issue solving this problem. The most important part is to set "Sender Authentication" from sendgrid to your domain dns. There is a instruction here. I'm using godaddy, so the link to set dns is https://dcc.godaddy.com/manage//dns .
Today I started to learn about webhooks and I was wondering if it is possible to know exactly what message is related to a received webhook.
For example, I have a website where customers can register and, after a successful registration, I'm sending them a confirmation via email. Is it possible to know that the customer clicked on that specific email message? (Considering that the customer can receive other types of email messages like password recovery, newsletters, etc). I know I can use the subject (something like if subject == 'Welcome to My Site' then do-email-post-registration-clicked-routine) but if the subject changes, or if they change it (when we reply to a message, usually the email client prepends "Re:" to the subject, I won't be able to track it.
Thanks in advance!
Yes. You can use custom arguments to track individual emails. Custom arguments get sent with event webhooks.
More documentation can be found here: https://sendgrid.com/docs/API_Reference/SMTP_API/unique_arguments.html
Just for knowledge purposes, I want to know if it is possible to know if email spoofing has been done successful or not . Suppose if I am sending an email from one's account, What if receiver doesn't exist? Means will i get any error as a spoofer that receiver doesn't exist and you cant send email . Thanks
There is no way to know for certain, but you can make an educated guess.
First, when sending an email to a non-existent recipient and the recipient's server is configured to report this to the sender (pretty much the default behaviour), this reporting can happen either:
1) During the email transmission. The SMTP conversation with the recipient's server may very well fail at RCPT TO: (i.e. when the recipient is specified) or at the end of the DATA or BDAT commands (i.e. when the email just have been transmitted and the server either acknowledges this or rejects the email). If you receive an 5xx-type response at either stages, or, well, anytime earlier in the conversation, you can be sure the recipient did not get the message. Validation during email transmission is common.
2) After the email transmission. Servers that don't do recipient validation on SMTP level will often accept and queue emails during the transmission, then generate a bounce report (also called a Delivery Status Notification/DSN or Non-Delivery Report/NDR) later and attempt to return it to the original message sender. As you have no access to the mailbox of the original message sender when spoofing, you will have no idea if such bounce report is generated. This method of validation is still fairly common.
Second, you can embed a tracking image in your HTML email to see if the email was opened. This works by placing a HTML <IMG> element in the email that points to e.g. http://example.org/tracking-1x1.gif?uuid=<id>. The idea is that you track whether that image was downloaded. Be aware that virtually all modern email clients will disable downloading images from unknown sources and some action is required from the recipient to enable downloading images.
Third, you can spoof the MIME sender only. Emails have two distinct set of addressee information: the envelope addressees and the MIME addressees. Emails are delivered based on what's written on the envelope, but email clients render the MIME information instead (what's inside the envelope). In other words, during the SMTP transmission you may specify a different sender address (MAIL FROM: command) from that in the email (From: header). The fun part is that bounce reports are sent to the envelope sender address, a.k.a. the Return-Path, so if you have access to the envelope sender mailbox, you can receive a bounce report no matter what stage it was rejected. Note that you will reveal yourself, either through the mail server logs or through the email header, where the Return-Path header will contain the envelope sender address.
Please use the above information for "knowledge purposes" only. Be aware that email spoofing is likely a crime in just about any country.
Mandrill has inbound email processing, in which you can setup a catch-all address for which incoming e-mail will be posted to a specified URL.
For example, e-mails to *#sub.domain.com could get posted to http://mydomain.com/process.
Is there a service that will work this way but that allows to "re-route" the e-mails? Say if a post to the URL above returns a specific code, say 403, the e-mail will be swallowed, but when a 200 code is returned, the e-mail gets sent to a specific address, without modification, just as if it was originally sent to that address.
I guess I could code a script that would just re-send the e-mail, but I don't want to run into deliverability issues.
I'm not sure I'm explaining this clearly, so here's a specific example:
E-mail to newsletters#sub.domain.com is received by a Mandrill-like service (the receiver)
That service posts the e-mail to http://mydomain.com/process (let's call this the processor)
The processor either:
Returns a 403, in which case nothing else happens
Returns a 200, and a destination address, and then the receiver delivers that e-mail to the new destination
EDIT: I realize I could just use Mandrill to re-send the e-mail, but wouldn't I run into problems given I won't be the original sender? For example, if I receive an e-mail from support#microsoft.com and then I re-send that e-mail to another address, could I be flagged as a spammer or have other issues with deliverability? So this might not be possible at all?
It seems it is indeed impossible to do what I want, otherwise anybody could spam the world with no problems, however, Mandrill just added this feature, which might come in handy:
http://help.mandrill.com/entries/23374656-Can-I-send-emails-on-behalf-of-my-clients-
This is just an experiment, but I'm going to try and resend mails to my own server instead of forwarding to the original receiver, so then an e-mail client can pull the messages from there.
Any one know how to implement auto send message using MFMessageComposer....i mean No need of displaying The message Composer..we Have to sent the pre-defined message to a given Number..Or any other way without using MFMessageComposer..???
You can't auto-send messages with MFMessageComposer. It always displays the message to the user before sending (and rightly so).
An alternative would be to call a webservice which dispatches an email to you. Or put enough SMTP code in your app to get emails sending. You'll need your own email system for this though as you'll not be able to get the users email settings.