How to recognize phishing email messages, links, or phone calls


How to recognize phishing email messages, links, or phone calls

Phishing email messages, websites, and phone calls are designed to steal money. Cybercriminals can do this by installing malicious software on your computer or stealing personal information off of your computer.

Cybercriminals also use social engineering to convince you to install malicious software or hand over your personal information under false pretenses. They might email you, call you on the phone, or convince you to download something off of a website.

What does a phishing email message look like?

Here is an example of what a phishing scam in an email message might look like.

What is phishing

  • Spelling and bad grammar. Cybercriminals are not known for their grammar and spelling. Professional companies or organizations usually have a staff of copy editors that will not allow a mass email like this to go out to its users. If you notice mistakes in an email, it might be a scam. For more information, see Email and web scams: How to help protect yourself.
  • Beware of links in email. If you see a link in a suspicious email message, don’t click on it. Rest your mouse (but don’t click) on the link to see if the address matches the link that was typed in the message. In the example below the link reveals the real web address, as shown in the box with the yellow background. The string of cryptic numbers looks nothing like the company’s web address.

    Phishing scams masked web address

    Links might also lead you to .exe files. These kinds of file are known to spread malicious software.

  • Threats. Have you ever received a threat that your account would be closed if you didn’t respond to an email message? The email message shown above is an example of the same trick. Cybercriminals often use threats that your security has been compromised. For more information, see Watch out for fake alerts.
  • Spoofing popular websites or companies. Scam artists use graphics in email that appear to be connected to legitimate websites but actually take you to phony scam sites or legitimate-looking pop-up windows. For more information, see Avoid scams that use the Microsoft name fraudulently.

    Cybercriminals also use web addresses that resemble the names of well-known companies but are slightly altered. For more information, see Protect yourself from cybersquatting and fake web addresses.

Beware of phishing phone calls

Cybercriminals might call you on the phone and offer to help solve your computer problems or sell you a software license. Neither Microsoft nor our partners make unsolicited phone calls (also known as cold calls) to charge you for computer security or software fixes.

Once they’ve gained your trust, cybercriminals might ask for your user name and password or ask you to go to a website to install software that will let them access your computer to fix it. Once you do this, your computer and your personal information is vulnerable.

Treat all unsolicited phone calls with skepticism. Do not provide any personal information.

For more information, see Avoid tech support phone scams.

Report phishing scams

If you receive a fake phone call, take down the caller’s information and report it to your local authorities.

Whenever you receive a phone call or see a pop-up window on your PC and feel uncertain whether it is from someone at Microsoft, don’t take the risk. Reach out directly to one of our technical support experts dedicated to helping you at the Microsoft Answer Desk. Or you can simply call us at 1-800-426-9400 or one of our customer service phone numbers for people located around the world.

You can use Microsoft tools to report a suspected scam on the web or in email.

  • Internet Explorer. While you are on a suspicious site, click the gear icon and then point to Safety. Then click Report Unsafe Website and use the web page that is displayed to report the website.
  • (formerly Hotmail). If you receive a suspicious email message that asks for personal information, click the check box next to the message in your Outlook inbox. Click the arrow next to Junk and then point to Phishing scam.
  • Microsoft Office Outlook 2010 and 2013. Right-click the suspicious message, point to Junk, and then click Report Junk.

WebSockets vs REST: Understanding the Difference


Sockets are a paradigm for handling networking, and the concept has been around for decades. Sockets were once a way to standardize networking input and output, much like an API does, so that regardless of the particulars of the hardware, applications could program to “sockets” and it would work with many different hardware implementations.


WebSockets and REST Understanding the Differences


The idea behind a socket, is that it is a “port” through which data goes in and out of. Much like a real trading port for data, the socket itself is like the dock, it’s where exchanges are happening from the application standpoint. The socket itself is abstract and low level, and staying with the metaphor, many different ships, trains, and equipment can use it. We can call all of these Protocols.

On the Internet there are hundreds of protocols, but a few stand out as the most common, like HTTP, FTP, SMTP, POP3, etc. and lower level transport protocols like TCP and UDP. In essence, Protocols determine how to interpret the data going to and from the socket and the machines that are communicating with each other.

What are WebSockets?

WebSockets are really just an extension of the socket idea. While HTTP was invented for the World Wide Web, and has been used by browsers since then, it had limitations. It was a particular protocol that worked in a particular way, and wasn’t well suited for every need. In particular was how HTTP handled connections. Whenever you made a request, say to download html, or an image, a port/socket was opened, data was transferred, and then it was closed.

The opening and closing creates overhead, and for certain applications, especially those that want rapid responses or real time interactions or display streams of data, this just doesn’t work.

diagram of Websockets vs REST

The other limitation with HTTP was that it was a “pull” paradigm. The browser would request or pull information from servers, but the server couldn’t push data to the browser when it wanted to. This means that browsers would have to poll the server for new information by repeating requests every so many seconds or minutes to see if there was anything new. In the late 2000’s, a movement to add Sockets to browsers was mounting.

In 2011, the WebSocket was standardized, and this allowed people to use the WebSocket protocol, which was very flexible, for transferring data to and from servers from the browser, as well as Peer-to-Peer (P2P), or direct communication between browsers. Unlike HTTP, the socket that is connected to the server stays “open” for communication. That means data can be “pushed” to the browser in realtime on demand.

What is REST?

In REST, or REpresentational State Transfer, is another abstraction for creating API’s for applications in a standardized way. With typical, and now traditional, web applications, creating REST endpoints using HTTP is how the vast majority of applications are architected. Whether it’s Ruby, Java, Go, NodesJS or any of the multitude of technologies available, they are fundamentally similar in that they receive to Requests for information, and then Responding to the request.

REST organizes these Requests in predictable ways, using HTTP operation types, or verbs, to construct appropriate responses. Requests originate from the client, and the common HTTP verbs include GET, POST, PUT, DELETE but there are several others. They correspond to expected operations, retrieving data, submitting data, updating data, and deleting data.

REST is by far the most standardized way of structuring the API for Requests. But since it involves using HTTP is also has the overhead associated with that protocol. For most applications, information only needs to be transferred when a user takes an action. For instance, when browsing a news site, once the browser has requested the article, the user is busy reading it, and not taking actions. Having the port-socket close during this time is actually saving resources. With less frequent interaction, HTTP works very well, and it is why it is used.

For more real time interaction, or real time transfer or streaming of data, HTTP and REST aren’t the best suited protocol and abstraction combination. This is where Sockets and WebSockets shine.

WebSockets vs REST: A Comparison of Performance

The overhead of opening and closing connections is very real. The performance of being able to send and receive data and the number of concurrent devices that can do so is a significant consideration. The use of polling versus pushing is also a very real burden on servers.

REST Performance

Metaphorically, we could think of this as an army with a chain of command. Let’s make the server the General, and all the browsers the soldiers on the ground waiting for orders. Using HTTP/REST, if every soldier has to ask the General if there are any new orders, it burdens the General tremendously, particularly when there isn’t anything new. That means the General is saying “no, nothing new” most of the time.

If your servers are the General, their resources are being wasted mostly saying that there is nothing new. Furthermore, because the General can only answer so many soldiers at a time, it takes a long time to say “nothing new” to every soldier even once, there is a time delay where the last soldiers in line hear the “nothing new” far later than the first soldier who asked.

servers resources being wasted mostly saying that there is nothing new

WebSockets Performance

Using the same metaphor, sockets being connected are like each soldier having a radio, and when the General has a new order, he can send that order into the radio and all the soldiers can receive it at the same time. It could be all the soldiers hear the same order, and, of course we can have different bands on the radio, and the General can speak order to particular groups listening on different bands.

The efficiency here is on both sides.

The General no longer needs to be burdened with unnecessary work, so you need fewer servers to service your clients. The clients also don’t need to waste networking and resources for polling and making requests. Far more efficient on both sides.

This great article outlines some informative benchmarks regarding the differences in performance between REST/HTTP and WebSockets: REST vs WebSocket Comparison and Benchmarks.

Use WebSockets over REST?

At PubNub we have taken WebSockets to extreme scale and reliability, being able to service millions of devices across the globe and billions of messages each day being sent across the wire. There are a number of WebSocket frameworks and Socket.IO is likely the most popular and widely known.

It’s a great way to become familiar with Socket style programming and how the paradigm works. However, actually using it in production has a bigger story. Using PubNub instead is by far more cost effective on so many different levels.

When using Socket.IO, just like any other server, you have to dedicate time and resources to setting it up, configuring, monitoring, managing, and scaling. All of these take time, people and machines, all of which cost money. Throw in learning from mistakes and anomalies when things go awry, which they always will. Every time there is a lesson learned, the value is the lesson, but the cost is downtime for the application relying everything working, and likely losing customers. When you add it all up, it will be expensive, much more expensive than using an already globally-scaled fault-tolerant PubNub with a 99.999% SLA!

How to determine if a port is open on a Windows server?


Assuming that it’s a TCP (rather than UDP) port that you’re trying to use:

  1. On the server itself, use netstat -an to check to see which ports are listening
  2. From outside, just telnet host port (or telnet host:port on Unix systems) to see if the connection is refused, accepted, or timeouts

On that latter test, then in general:

  • connection refused means that nothing is running on that port
  • accepted means that something is running on that port
  • timeout means that a firewall is blocking access

I need to flush dns again and again to make the sites load

[Originally Posted From] : I need to flush dns again and again to make the sites load

UPDATE JUNE 4, 2015:-

My ISP provides a Wi-Max (wireless) device which receives the signals and sends it through LAN cable to my laptop. I’ve been using this device since last 5 years. Today, for a certain reason, my ISP’s custom care center replaced the device with a new device. Now, I’m no more facing this issue. So, I think that the problem is in the modem, not in Windows 8.1. I hope that my update will help others.

I’m facing a problem where when I visit a site Google Chrome says to me:-

“This web page is not available”

This happens for many sites. I’ve searched on Google and have found a fix. If I run the following command of flushing dns caching

ipconfig /flushdns

then I can load the site. But after few seconds or minutes Google Chrome again gives the same (error?) message. “This web page is not available”. I need to run the command again and again and it has now become very irritating. Anyone knows the solution of my problem?

OS: Windows 8.1 Browser: Google Chrome (Version 34.0.1847.131 m)

shareimprove this question


Error message when you run the ipconfig /flushdns command on a Windows XP-based computer: “Could not flush the DNS Resolver Cache: Function failed during execution.”



When you run the ipconfig /flushdns command to clear the Domain Name System (DNS) cache on a Microsoft Windows XP-based computer, you receive an error message that resembles the following:

Could not flush the DNS Resolver Cache: Function failed during execution.

When you try to repair the network connection, you receive an error message that resembles the following:

Windows could not finish repairing the problem because the following action could not be completed:
Clearing the DNS Cache

For assistance, contact the person who manages your network.


This problem occurs if the DNS Client service is not running on the computer.


To resolve this problem, follow these steps:

  1. Click Start, click Run, type services.msc, and then click OK.
  2. In the list of services, click DNS Client.
  3. Make sure that the Status column displays Started and that the Startup Type column displays Automatic.
  4. If the service is not set to Started or if the startup type for the DNS Client service is not set to Automatic, follow these steps:
    1. Right-click DNS Client, and then click Properties.
    2. In the DNS Client Properties dialog box, click the General tab, and then click Automatic in the Startup type list.
    3. Click Start, click Apply, and then click OK.