Revealing Email Headers

When a fraudulent phishing e-mail or scam, arrives in your mailbox, there is no danger to you unless you reply to the message. The ACCC’s SCAMwatch website provides information on common scams. The website has tips on how to protect yourself from scams and report them to the relevant agencies.

We encourage all customers to forward any and all spam to ACMA. In order for ACMA to do anything about the spam you have received, you must include the full email headers in the email that you forward.

Full e-mail headers are needed to investigate any phishing attempt so that the source of a message can be revealed. To retrieve the full headers from a message, you will need to locate it within your e-mail client. Instructions for locating and copying e-mail headers in different e-mail clients can be found at: www.spamcop.net.

Below is a quick set of instructions in how to reveal email headers in Outlook 2003 and Outlook 2007

1. Open the offending email.
2. Click on the word View in the menu bar.
3. Select the option Options.
4. The Message Options dialog will apear.
5. Right-click on the text in the Internet Headerssection.
6. A submenu will appear.
7. Choose the option Select All.
8. The text will appear in inverse video, indicating that it is selected.
9. Right-click on the selected text.
10. A submenu will appear.
11. Choose the option Copy.
12. Click on the Close button.
13. The Message Options will disappear and you
    will return to the offending email. Now you have the message in your buffer.

A Sample phishing mail

Below is a more detailed look at email headers, it is not for the faint hearted.

Return-Path: <(Aktiviere JavaScript, um die Email-Adresse zu sehen)>
Envelope-To: (Aktiviere JavaScript, um die Email-Adresse zu sehen)
Received: from [84.120.132.215]
 (helo=84-120-132-215.onocable.ono.com)
 by example.com with smtp (NetMail-SMTP 1.16);
 Sun, 10 Oct 2004 03:40:32 +0200 (CEST)
Date: Sun, 10 Oct 2004 05:39:35 +0300
From: CitiBank <(Aktiviere JavaScript, um die Email-Adresse zu sehen)>
MIME-Version: 1.0
To: (Aktiviere JavaScript, um die Email-Adresse zu sehen)
Subject: CITIBANK REMINDER: UPDATE YOUR DATA

The sample above shows a very typical mail header. In this case it is even a so-called phishing e-mail, offering a link to a faked website which looks like the one of a bank, but then captures (fishes) your log-in data to use it for fraud. We have changed the recipient’s address to (Aktiviere JavaScript, um die Email-Adresse zu sehen) for privacy reasons. Let’s look at the header lines one by one.

Return-Path: This line is not created by the sender but inserted by the receiving e-mail server using the address behind MAIL FROM in the SMTP dialogue. It is not verified. In most cases (but not all) it is the same as in the From: header line which your e-mail client displays as the sender’s address. Since there is only one MAIL FROM during the SMTP dialogue, there should be only one Return-Path line. An empty address like <> is allowed if the mail is from a Mailer-Daemon or a similar automated sender which cannot receive answers.

Envelope-To: For routing the received e-mail to the intended recipient(s), many e-mail systems insert this line using the address(es) from RCPT TO in the SMTP dialogue. While this is not really necessary for mails where all recipients are behind To: or Cc:, it allows the correct routing even for a Bcc: addressed e-mail. Unfortunately, the syntax is not standardized. “X-Envelope-To:”, “Delivered-To:” or “X-Pop3-Rcpt:” are some alternative forms. Angle brackets around each address are optional.

Received: While our example shows only one Received line, two or more of them are typical for most e-mails. Each mail server the e-mail passes on its way from the sender to the recipient inserts its own. The topmost is the newest, created by the server nearest to you, and you should rely on this one only, since all following lines may be faked. If there is only one Received line in the header, the sender did not deliver it via the SMTP smarthost of his local provider, but sent it directly to your server or your provider, which is very typical for spam and viruses. The format of Received lines is not always exactly the same, but in most cases it consists of this information:

• IP address: If the topmost Received line is created by your local mail server or your provider, the true IP address of the sender is shown here (which is 84.120.132.215 in our sample above).


• HELO identification: The HELO command is used by the sending SMTP client to identify itself (…ono.com here, obviously an ISP in Spain). Note that HELO should display the reverse-DNS name of the IP, which surprisingly is the case in this phishing e-mail, but for many spam and virus mails it is just a fantasy name. If the IP address is not in your local LAN, a HELO name without dots is definitively faked. In the sample above, the sender apparently used a reverse DNS request to find out his local domain name in order to send a realistic HELO string.


• Mail server name and system: The line "by example.com with smtp (NetMail-SMTP 1.16)" shows the (or at least one) domain of the server receiving this e-mail, the protocol used (typically SMTP) and the server software (the NetMail SMTP module in this sample).


• Recipient (optional): The recipient’s address is sometimes given behind the keyword "for" in the Received line. This may be useful for BCC-addressed mails. If there is no Envelope-To line (or similar), then this may be the only place where the intended recipient address can be seen. However, this field is optional. Furthermore the SMTP standard only allows one address there, so this information is often suppressed for multi-addressed mails.


• Date and time: Assuming that the clocks of all systems involved are not too inaccurate, you can see when a specific server received this message. Note that the local time zones may be different. The difference to GMT/UTC is given as a signed 4-digit number. For instance, +0200 means 02 hours and 00 minutes earlier than UTC. Some systems add the name of the time zone in brackets for better readability. A few proprietary, typically American systems replace the number by the time zone name like EDT (Eastern
  Daylight Time), but this is a bad idea since it is often ambiguous: EDT is valid in the US (UTC+4) as well as in Australia (UTC+11).

Date: The date and time when this e-mail was created. It is not necessarily the time when the message was actually sent to the Internet. The format is the same as the one used in Received: lines described above. Since it depends on the client’s system clock, it may be more inaccurate than the times in the Received lines created by well-adjusted servers.

From: The alleged sender of this e-mail. If an answer is requested to a different address than the one behind From:, a Reply-To: line is added with the address where an answer should go to. Both may be completely faked. It is crystal-clear that citibank.com would never send their mails over a cable access of ono.com in Spain. For most normal mails, the From: line shows the same address as the Return-Path information in the header, but this is not required. Typical From lines are (comments added in brackets):

From: CitiBank <(Aktiviere JavaScript, um die Email-Adresse zu sehen)> (as in sample above)
From: "CitiBank" <(Aktiviere JavaScript, um die Email-Adresse zu sehen)> (quoted real name)
From: (Aktiviere JavaScript, um die Email-Adresse zu sehen) (no real name given)

The From: address in the sample above is faked, of course: The word “antifraud” and the name of the bank are simply intended to confuse the recipient.

To:, Cc: Displays the recipients except the ones sent as Bcc. Some badly implemented clients even send a Bcc line, but this does not conform to the standard since Bcc addresses should not be visible to other recipients. When sending an e-mail, the SMTP dialogue uses RCPT TO for all destination addresses, so the things behind To and Cc (just as all the other content of the message header and body) are completely irrelevant and may be even faked. The possible address formats are the same as for From (see above), multiple addresses can be separated by commas.

Subject: The subject of the e-mail. It is interesting that it is uppercase-only in this sample; this fact could add some percent to a probability value that an e-mail is unwanted spam.

Avoid Fraud and Scams

Almost everyone will be the target of a scam at some time – you may have been already. Some scams are easy to spot, while others can happen without you even knowing it. It is designed to trick you into giving away your money or your personal details. Scams succeed because they look like the real thing and are crafted to appeal to your needs and desires.

Common scam include:

• lottery and competition scams
• investment or ‘get rich quick’ scams
• money transfer requests or ‘Nigerian’ scams
• banking and online account scams
• employment scams

The people who run these scams (scammers) are imaginative and manipulative; they know how to push the right buttons to produce the response they want.

Many scams originate from outside Australia and once money is sent overseas it is virtually impossible to recover.

SCAMwatch is a website run by the Australian Competition & Consumer Commission (ACCC). The aim of SCAMwatch is to provide information to consumers and small business about how to recognise, avoid and report scams.

Scams that are reported to SCAMwatch will be analysed by the ACCC. Many scams originate overseas or take place over the internet, making them very difficult to track down and prosecute. If you lose money to a scam, it is unlikely that you will be able to recover your loss. The ACCC publishes this website to help consumers recognise scams because prevention is definitely a better option when it comes to scams.

Some tips for protecting yourself from phone scams

• Be suspicious of unexpected calls and text messages.
• Hang up. Or text ‘STOP’ to unwanted messages.
• Don’t give your number to just anyone.

Some tips for protecting yourself from internet scams

• Keep your protection software up-to-date
• Don’t respond in any way to unsolicited emails
• If in doubt, delete

Google SEO Starter Guide

All webmasters want high search engine rankings to list their site on top of search engines search result pages. There are hundreds of sources providing information about search engine optimization to drive more site traffic. Google just made it simpler to master these SEO techniques.

Google webmaster tools has released an official Search Engine Optimization Starter Guide that covers many areas that webmasters might consider optimizing to get better Google ranking and indexing. Here is the index of contents that should interest you.

• Create unique and accurate page titles
• Make use of the ‘description’ meta tag
• Improve the structure of your URL’s
• Make your site easier to navigate
• Offer quality content and services
• Write better anchor texts
• Use heading tags appropriately
• Optimize your use of images
• Making effective use of Robots.txt
• Be aware of ‘nofollow’ tags for links
• Promoting your website in the right ways
• Make use of free webmaster tools
• Take advantage of web analytics services

Download the Official Google SEO Started guide (.pdf) today and see what Google expects from your site structure and functionality.

Brute Force Detection (BFD) in CPanel

We’ve all been faced with the problem of weak passwords. As much as you inform users about password security, they want to use something they can easily remember. So, we end up with passwords like ‘ilovesue’ and ‘spunky′. Even with the new password strength meters in cPanel, it is important to go that extra step to make sure that your users are protected, well, from themselves.

Net Solutions uses cPHulk which enables a brute force password protection system. With cPHulk, you can set a threshold for authentication attempts on services like POP3, cPanel, WHM, FTP, etc. After a certain amount of attempts, the attacker will no longer be able to authenticate.

BFD Protection is necessary as, there are literally thousands of attempts made every day to gain access to peoples accounts. Users will never notice as cPHulk works in the background blocking access to IP addresses originating from China, Taiwan, Russia, etc.

So while BFD may be seen as an inconvenience if you get locked out, imagine the risks of allowing someone else to gain access to your account by password guessing. What would you have to lose?

Account Level Blocks

This will block access to a specific account for a period of time. If you find yourself blocked and continue to try and authenticate while you are blocked, the time will get extended.

IP Address Level Blocks

This will block your IP address. Block of this type will prevent you from having any access to the server including access to CPanel itself.

Thresholds

Account Level

• How long an account is locked out when it reaches the failure limit: 5min
• Maximum Failures by account: 15

IP Address

• Number of minutes a remote IP is locked out when it reaches the failure limit: 15min
• Maximum Failures by remote IP Address:5
• Maximum Falures by remote IP before IP is blocked for two weeks:30

I got blocked from my own server by BFD! Now what?

In most cases once you have been blocked by your server’s BFD system the easiest way to regain access is to simply create a Support Ticket with our support team. (No need to feel embarrassed. We fix issues like this all the time!)

The vast majority of cases that our support department handles involving customers who are blocked by their own servers are due to FTP clients that contain a saved password. If someone in your company, group, organization, or household changes the password to that FTP account and doesn’t notify you to update your saved password it is quite easy to end up blocked by the server. Most FTP clients automatically reconnect several times if the initial attempt fails, and once your FTP client with the bad password attempts to login several times and fails the server’s BFD system will kick in and block your IP address.

Customers in an office environment that utilize a private network connected to the internet may find their entire office blocked by their server. This happens (usually in a small/home office situation) when multiple computers are sharing a single internet connection, meaning they also share the same public facing IP address. Once a single computer on that local network gets blocked by the server all of the other local computers will find themselves blocked as well.

While this can cause some initial panic there is no need for concern. Even if you are temporarily blocked by your own server that does not mean it is down. It may be ignoring your requests for a short while but it is still working away, handling the tasks from other visitors to your web site(s).