I released a small project this morning, Disposamail, which I created between last night and this morning. Disposamail is a web application that allows you to grab a temporary email address and use that address while you’re still on the Disposamail website. Once you leave the website, the address is released, the mail server stops accepting mail for the address, and any emails that were received are lost forever.

Disposamail is written in Node.js and uses several third-party modules that provide a lot of the functionality:

  • Haraka – Haraka is an SMTP server with an extensive plugin architecture which ultimately made this entire project possible.
  • socket.io – socket.io makes sending data between the server and the client easy, using the best method possible.
  • MailParser – Used for parsing raw emails into its various parts.
  • Phonetic – Generates phonetic names for easy to remember email addresses.
  • forever – Making it easy to keep a Node.js script running in the event something bad happens.

The best part of this project, though, is that I’ve released the code under the AGPL. You can checkout the code on GitLab.

Update: Disposamail can now handle attachments!

Verizon Email API Vulnerability

A critical vulnerability has been found in Verizon’s email API which basically allows any user to access any other user’s email, given they know how to properly send the requests to Verizon’s server. Randy Westergren noticed this vulnerability when he was proxying requests from his device (presumably to see what some apps were sending to their motherships) and found his Verizon user id within the request headers. By changing his user id to the user id of another user, the server responded with that user’s information.

This is why you should always sanitize user inputs, and by “sanitize” I don’t necessarily mean preventing things such as SQL injection (though you should do that as well), I mean that you should check any and all input to make sure that the user can actually do the action requested, even if that input came via your own app and wasn’t technically “user input”. Had Verizon properly checked the username against the user’s session, or better yet not even sending the username and just use the user id that is in the user’s session (assuming they’re using some kind of session functionality), then this would have not been an issue. At least they took care of fixing it quickly once the issue was reported to them, which was two days according to the article.

One last thing is that you really shouldn’t be using your ISP-provided email in the first place as you’ll most likely lose this email address when you switch to a new provider. Please, just use something like Gmail instead. Switching to a new ISP shouldn’t be like moving in regards to updating your information literally everywhere.

Email Tracking

In both my personal and professional life I’ve had people ask me how to be able to determine the status of an email, or to use a service that can determine the status of an email. While being able to check what the status of an email is, such as if the email was delivered to the user’s inbox, if the user has read the email, or if a user has clicked a link within the email, all of the methods of doing so produce so many false positives and negatives that it’s really not worth going through the effort to implement such a system. The following are the general methods for checking the status of message as well as their downfalls.


Checking to see if an email was delivered to the mail server is easy, it’s a simple as checking your SMTP logs to see if the mail was delivered to the receiving mail server. It’s not really much harder than that.

The problem with this, however, is that servers may “accept” the mail only to put it in a user’s spam folder, or worse yet drop the email without notification. Dropping email after can happen without notification if the mail server doesn’t check it for spam, etc., until after closing the connection with the sending mail server, and the reason why you won’t get a notification back is to reduce backscatter. As for the spam folder, you can’t really do anything about that other than ensuring your SPF and DKIM records are set appropriately, signing your emails with said DKIM keys, and ensuring that the content of your emails don’t look “spammy”.

The only good notification you may get is a bounce message if the user’s mailbox doesn’t exist, if it’s full, etc., however you’ll normally only get those within the same connection the email is being sent with. If you do happen to get them after closing the connection you should probably contact their administrator as they’re contributing to the backscatter problem.

Read, Click, etc.

You may also want to check if a user has read your email or not, which could be useful in some circumstances. The following are the methods to do so and their downfalls.

Read Receipts

One way to accomplish this is via read receipts. Basically, a read receipt is an email sent via the users mail application when they open an email which is sent back to the sender. The senders email application then links this back to the original email to display a notification to the user indicating that the mail has been read.

While this sounds great, the problem is that this method does not always work. Read receipts can be turned off in the majority of circumstances, and additionally most systems default this setting to off (i.e., it had to be explicitly enabled), or do not even have the capability to do this at all. For instance, Google’s FAQ about read receipts indicates that read receipts are only available on Google Apps accounts if an administrator enables it, and is not available on personal accounts. Additionally, Google’s FAQ states the following:

Do not rely on read receipts for certifying mail delivery. Although read receipts generally work across email systems, you may sometimes get a receipt for an unread message or not get a receipt even though the recipient has read the message.

Remote Images

The next trick is to use a remote image within the email to signal to a server that the email has been read. When the email is opened, the users browser or mail application will load the remote image allowing a server to tell if the email has been read.

The flaw with this method is that most mail applications will not display remote images, and most webmail systems will not display remote images either. Google’s FAQ for Gmail indicates that images may be shown, however that’s only after Google determines them to not be malicious. What this implies is that, while images may be displayed, Google checks the images before ever showing it to the user, and therefore it’s possible the server gets a notification that the user has opened the email when in reality the user never actually opened it.


I’m not even going to go here as including JavaScript within emails is a good way to get yourself blacklisted, and it’s not going to work anyway because most providers will strip any scripts out of the email before displaying it to the user. See the Super User question about this.


You could use links that contain a unique identifier in them, and then when he user clicks on the link, the server would be able to see that unique id and mark the email as read. This is about the only method that may actually work and make sense, however it has some of the same problems as remote images. The mail server could check the links to see if it’s linking to malware or something malicious, and your mail server may treat that as the user clicking on the link if that’s not accounted for.

The problem with this, however, is that if the user got this far, they’re probably on your site doing whatever it is you emailed them about, which you should be able to track already, so it’s kind of pointless short of email marketing campaigns that link to somewhere you do not control.


Email “status” tracking is inaccurate with false positives and negatives all throughout the process. If you understand these limitations and still want to track your users, then by all means go right ahead, just don’t get mad when your numbers are a little off from what you thought they would be. Lastly, if you’re running a third-party mailing service please make sure your users understand this as well.