I'm emailing to user with URI(s) in the message body. When the user will click that URI link, the app will answer the calls depending on the params on the URI.
However, all these should happen depending on which eMail account this URI is clicked from.
Eg. the system sent the email to thisUser#xyz.com. Then, the owner of thisUser#xyz.com forwarded the message to, say thatUser#xyz.com.
The system should be able to be aware that the URI sent to thisUser#xyz.comis being clicked by thatUser#xyz.com. Is there a way to make such distinction? How?
I can make the user verify his credentials-- enter his username&passwd but this is not what i'm looking for.
No, this is not possible, as the only information sent to the server is the URI, which is always the same.
Email clients do not send additional information about the recipient of an email to a server when the user clicks on a link in the email. Doing so would be a bad idea, because of privacy concerns, as it could be exploited for, e.g., farming email addresses using chain emails.
Related
I have a web application that will be used by committee chairs to communicate with committee members over email. All these users will have e-mail accounts external to the web application and domain the web application is hosted on. Any replies from members need to be directed to the e-mail of the committee chair user, not an account on the domain of the web application. The only two methods of accomplishing this that I've come up with are
In the from of the e-mail, use the e-mail of the sending user. E-mail applications for many of the committee members block this as spam.
Use an account such as no-reply#applicationdomain.com, and then include instructions in the e-mail of the correct address that replies should be sent to. Users often get confused and don't send replies to the correct address.
Are there any alternatives I am missing?
Traditionally, this was the purpose of the Sender email header. If you want an email to be From the user, but sent by you, you would just set the Sender header to an email address on your domain but have From be the user. Also, the SMTP envelope sender should also be on your domain. Then, you would be properly declaring that you're the sender of the message for anti-spam purposes, you'll receive any bounce messages, but email clients will know that the email is reportedly from the "real" user, and will direct replies accordingly. Generally, email clients would report both Sender and From, saying something like "From my-server#website.example.net on behalf of real-user#example.com", though obviously the details depend on the email client being used.
Refer to What's the difference between Sender, From and Return-Path? and OpenSPF Web Generated Email Best Practices for more information.
However, now DMARC has come along. It has made the decision that verification should be based only on the From header. The theory is that there's no way for an end-user to know whether a particular Sender is in fact authorized to send mail "on behalf of" the user listed in the From header. While it probably isn't the decision I would have made due to how it ignores the traditional Sender, it's something that needs to be dealt with now, as if the domain of the user listed in the From has a DMARC record that is set to q=reject, then nobody else, including your web form that's trying to send mail with the complete approval of the user, can send mail that's From that domain. More and more domains are turning on DMARC, and as they do so your form won't be able to send email From them, regardless of what other headers are set.
The only other alternative, then, is to have email be From your application entirely, but set the Reply-To header to where the email program should send replies to. Also, the SMTP envelope sender should be your application, and ideally be set to an address that can handle bounce messages or other errors. You shouldn't need to include any instructions, as the Reply-To header is very well supported among email clients as indicating where replies should be directed.
Refer to the DMARC FAQ entry "Why are messages I send on behalf of visitors to my website being blocked?".
When sending an email, is there a way to find out:
User has received the email (displayed in user's inbox).
User has read (and at what time) the email.
If it's not possible, what prevents it from finding out? What is the route an email message follows from sender to receiver.
When you send an email, the email is transferred through a series of servers using SMTP (Simple Mail Transfer Protocol). Once the email reaches it's destination it is stored into the recipients directory. To retrieve and read the email, the recipient uses and email client like Outlook to that connects to the server via IMAP/POP3 which tells them how many new emails they have and delivers each message to the client. In order to get this information, the user must provide their credentials.
So, in order to get this information you would need to know the imap/pop3 server(s) for the recipient's domain, as well as the recipient's login credentials (which would give you full access to the recipients email account). Basically, this is not possible.
This article gives a nice simple overview of how email gets sent over the internet.
You can, and you do not need the credentials as mentioned in the selected answer.
Lets imagine you are using apache and php + mysql.
You send person x an email,
In the email you have an embedded image (your logo) which resides on your server.
the url of the logo in the email, points to a file on your server:
example.com/logo.png?userRelatedId which is a php file.
with an htaccess (apache) you can state that logo.png gets executed with php and in fact forwards a real image and correct mimetype but before that identifies userRelatedId, and saves in your database with the time the file was accessed,
Meaning the email was read by person x and the time which the logo was accessed (email was looked at).
I'm working on the C# project whom allows the sender to send mail and:
Verify the receiver has read email or not?
Verify the receiver's email is located in Inbox or Spam...
Verify the receiver's email ip
Verify the receiver clicked the link on sender's email
I do not know how to start to deal with these problems :(
Thanks and appreciate you helps!!!
Short answer:
you can't do 1, 2 and 3 reliably/at all without deploying code/software on the receiver's side.
you can do 4 with link redirection.
On the basis that you don't have access to the recipient's computer, here are the long answer versions of patrix' short answer:
Verify the receiver has read email or not?
Unfortunately email has never been designed to let you know when an email has been received, and very few (and certainly no standard mail clients I know of) will report if an mail has been received correctly*, let alone opened. However, you can track emails sometimes by embedding an HTML image tag, and tracking when that image is downloaded from the server. There are a lot of caveats, such as it only working for HTML emails, and only if images are enabled, but that's one of the only 'reliable' methods for tracking email opens, and the most common method used by Mailing List providers (who need to think about this stuff a lot)
[* There is a feature known as 'read receipts' (technically Message Disposition Notifications or MDN) that many clients implement, but I believe few people ever use, which sends an email in response to reading an email. An email can request a read receipt by setting the appropriate header, but it is optional for the recipient to respond.]
Verify the receiver's email is located in Inbox or Spam...
Next to impossible; in the first instance, the concept of a 'spam' folder does not exist universally across all mail clients, and has never been a part of any email specification [to my knowledge]. In the second instance, as I mentioned, very few (if any) email clients report on the state of an email, let alone the folder it has been put into.
Verify the receiver's email ip
Again, not reliably, but you will make some headway in this if you implement image-based tracking as I mentioned in point #1
Verify the receiver clicked the link on sender's email
This is known as 'Clickthrough Tracking'.
This can be done, fairly 'easily'. Instead of providing a link directly to a location, you link to a tracking URL first. E.g. instead of linking to http://www.example.com, you should link to http://mydomain.com/TRACKINGID, which then redirects to http://www.example.com *. Then, on the server side, you can log when http://mydomain.com/TRACKINGID is visited. You can then put a unique tracking ID into every email for every recipient, e.g.
Recipient A receives a link to http://mydomain.com/TRACKIDA, and Recipient B receives a link to http://mydomain.com/TRACKIDB. both /TRACKIDA and /TRACKIDB redirect to example.com but, assuming you're logging HTTP requests, you can see who visited their link, where they visited from, when they visited the link, and how many times they visited.
This is the way all mailing list providers track clickthroughs, and roughly what you will need to do
[* Note that you will obviously require the relevant software to do this, e.g. with a 'simple' PHP page, or by using Apache mod_rewrite - whatever floats your boat, really]
I use an email registration and confirmation in my project (yes, I know about OpenID. In my counry, a main email service lacks it).
Sometimes users misspell their email addresses. I know about this due to "message could not be delivered" letters in a mailbox. A misspelled address is absolutely correct, because I check it with a regular expression - say, jon.doe#example.com intstead of john.doe#example.com. And I do not want to duplicate a email field in a registration form (who likes it?).
Request processing routine cannot wait for email delivery - it could take an unpredictable time. So, my script will return to user a confirmation message "An email was sent". And the user will wait for it forever (of cause, not - he/she will turn to an alternative project with a more perfect registration system).
Does someone knows how it can be improved (in any programming language)?
If you cannot wait for a response back from a confirmation e-mail, I would display a yes/no message box confirming their e-mail (i.e Send e-mail to jon.doe#example.com?) before sending the e-mail. While your at it, you can check to see if the e-mail is a duplicate as well.
If no duplicate found and they click "Yes" then send the e-mail. If not, ask them to re-enter the e-mail address.
With this approach you have gone above and beyond validating correct e-mail addresses since there are no services that will explicitly check for correct/valid addresses.
Unfortunately, there's no canonical way to spell anything in an e-mail address and no way to check programmatically whether it's spelled correctly or not. The only tool that can confirm the correctness of a valid e-mail address is Eyeball 1.0, which runs client side.
You can try the SMTP VRFY on the server but most won't reply with anything valuable. Most will simply say "go ahead and try it" because returning something useful would be invaluable to spammers.
You can always check the domain name with a DNS lookup but the only way to check an email address is to send a message.
Try to have the user type his email twice with an email confirmation field (as for the password).
EDIT : Anthony's idea is good too.
For user parts of email the only thing I can think of is using:
MX lookups (if mail provider doesn't block them... since that can be abused to filter email lists)
Requiring user to enter email twice to ensure he doesn't misspell user portion of email
As for domain part of email, take a look at this:
AngularJs directive to offer suggestions for misspelled emails?
It helped me to reduce bounce for misspellings like gmai.com and gmail.con.
I'm building a system that allows people to submit text and photos via email in addition to standard access on the website. I'm trying to weight the security advantages of two strategies in particular for verifying submissions from a user. Here they are as follows:
To based auth: Create a secret email address per user and present this to the user for submission. This strategy has the advantage that people can send from multiple devices that might be setup with different mail accounts
From based auth: Only accept emails from addresses that are registered in the user database. The idea being that it is impractical/difficult to impersonate registered users based on the sending address.
Can you think of other possible solutions? Which strategy of the ones proposed makes the most sense to you?
I would suggest that you not use From based authentication, at least not without some additional credentials (a passphrase, etc)
It's way too easy to forge, and certainly not difficult if you know someone's email address.
If you echo the email back to the user for confirmation, you can make things a little more difficult, but realize that your service can end up being used as a sort of spamming relay. (I could send 100 upload requests to you, with a forged FROM address, and you'd go ahead and spam the real person with 100 confirmation requests)
The better option is to check the registered email address but add the need for a code within the email subject known to the user. This way if they forge the email from address, they would still need a key to authenticate the incoming email.
I would go with "from" + confirmation, to avoid forging.
I.e. receive the email, but send a response with auth token in the subject line (or in the body) back to the "from" address. The user either will need reply, or click a link to confirm the submission.
And you post the content only after confirmation.