Posts Tagged ‘Email Addresses’

IP address vs domain in an email address

Some of your contact email addresses may contain an IP address, for example, john.smith@[123.123.123.123] rather than a domain name, such as john.smith@example.com. Can you use these email addresses for mailing purposes?

The short answer is technically yes, but really no.

The Simple Mail Transfer Protocol (SMTP) does allow an IP address to be used instead of a domain name under special circumstances when encapsulated in brackets, such as our previous example of john.smith@[123.123.123.123], However, here are some common reasons why doing so may end up with the email message being bounced back and/or not making it to the intended recipient.

  • By default, it is not uncommon for many mail servers to not accept email addresses without a ‘fully qualified domain name’ (FQDN).
  • For a mail server that hosts more than one domain, the FQDN in the email address is necessary to identify which domain group the email user belongs to.
  • Email addresses with IP addresses often get flagged as spam.

When is an IP address allowed?

Email messages are transmitted using the Simple Mail Transfer Protocol (SMTP), which is defined by the Request for Comments (RFC) 5321, 5322 and various extensions. In the email address specification section of RFC 4532, we see where the specification mentions the use of a domain-literal form, i.e. a domain’s literal IP address.

RFC 5322 – 3.4.1

The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a hostname or a mail exchanger name) as described in [RFC1034], [RFC1035], and [RFC1123]. In the domain- literal form, the domain is interpreted as the literal Internet address of the particular host.

In other words, RFC 5322 says that either a domain name form or a domain literal form may be used to describe the domain portion of an email address. Where the domain name form is what we are typically used to seeing (ex: john.smith@example.com), and the domain literal form being an IP address (ex: john.smith@[123.123.123.132]). It goes on to say that, “In both cases, how addressing is used and how messages are transported to a particular host is covered in separate documents, such as [RFC5321].” So, we must dig further to learn more about when an IP address may be acceptable to use.

In RFC 5321 we find the Host and Domain Names listed under sections 2.3.4 and 2.3.5 respectively. Here we see the RFC strongly recommending against the use of an address literal, also known as a domain literal or IP address.

RFC 5321 – 2.3.4

Hosts are known by names…they SHOULD NOT be identified by numerical addresses, i.e., by address literals as described in Section 4.1.2.

And then we finally get a glimpse as to when an IP address would be allowed.

RFC 5321 – 2.3.5

Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP…There are two exceptions to the

rule requiring FQDNs:

o The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4. o The reserved mailbox name “postmaster” may be used in a RCPT command without domain qualification (see Section 4.1.1.3) and MUST be accepted if so used.

Two situations where IP is allowed

We find that a domain name may be replaced with an IP address if the host has no name, as described below in sections 4.1.3, or if the email address is for the host postmaster (for example: postmaster@[123.123.123.123]). Now we’re finally getting somewhere. So according to the RCF below (emphasis mine), an IP address is allowed in email address when a domain name is not available in DNS, otherwise it must be an email addressed to the host postmaster.

RFC 5321 – 4.1.3

Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier, a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2], which indicates an (IPv4) Internet Address in sequence-of-octets form. For IPv6 and other forms of addressing that might eventually be standardized, the form consists of a standardized “tag” that identifies the address syntax, a colon, and the address itself, in a format specified as part of the relevant standards (i.e., RFC 4291 [8] for IPv6).

IP addresses often associated with spammers

The RFC states that an address literal (IP address) is allowed as an alternative to a domain name when the recipient host is not known in DNS, but why wouldn’t a domain name be available? There are plenty of reasons for why a mail server might not be listed in DNS, but a mail administrator who is in charge of keeping out spam is not likely willing to take the risk. Many mail servers require reverse pointer (PTR) DNS records from the submitter. A PTR record allows the receiving mail server to perform a reverse lookup on the IP address that is sending the email message. The PTR record should resolve to a FQDN. If a PTR record does not exist or if the FQDN it resolves to does not match the one in the email address, then it is likely a spoofed email message and the recipient mail server will reject it. This is just one common method used by mail severs to try and fight spam.

A mail server without a FQDN will not have a PTR record, so if it were to try and send out mail then it is likely its messages would be rejected by most recipient mail severs. If chances are that your mail server will not accept email from a mail server without a FQDN then you likely wouldn’t want to send email to one, as you wouldn’t be able to get a reply. More likely, when a FQDN is not available it means there is no mail server that accepts email and that the IP address is just being used as a burner to blast out spam. This is why so many address literal form email addresses appear in various blacklists and why they are associated with spammers.

Address literal form disabled by default

It is common for many mail servers to disable the acceptance of address literal form by default or not support them at all. After all, even though the RFC does allow the use of IPs under special conditions, it does strongly recommend against using them. That coupled with the high abuse of address literal form by spammers and malicious users it makes sense for most mail servers to not allow them. If the mail server does not have the acceptance of address literals enabled, then it will likely reply with a permanent reject (aka a hard bounce). In other cases, the recipient mail server may reply with a temporary reject (aka a soft bounce) and instructions for the sender to use a FQDN instead and try again.

Domain groups

Mail servers are designed to host multiple domains. If one of these is reached by its IP address via address literal form, then it would be unable to route the email message to the end recipient because it needs to FQDN to know which domain group the message belongs to. For example, say you have three different email addresses.

sales@exampleone.com
sales@exampletwo.com
sales@examplethree.com

In our example, these email addresses are for three different businesses where ExampleOne is a large global leader in its marketspace, ExampleTwo is a longtime rival of ExampleOne and ExampleThree is fledgling competitor. ExampleOne and ExampleTwo are too big to adequately manage all their email traffic on their own, so they outsource to an Email Service Provider (ESP). ExampleThree is too small and lacks the resources to host their own mail, so they too outsource to an ESP. As it turns out, the ESP is so popular (cough, Gmail… cough, Office365) that all three businesses end up using the same ESP and the ESP is using the IP address 123.123.123.123.

Now, let’s say that we wanted to write the email addresses in domain literal form and use their IP address instead of the domain. If we were to do this then all three email addresses would end up looking the same.

sales@[123.123.123.123]

If we were to try and send a message to sales@[123.123.123.123] then the ESP’s mail server(s) wouldn’t know who it belongs to and it would be unable to deliver the message. Even in an example where a company hosts their own mail server and has only one domain, chances are that the mail server will still require the domain. Likely because it is configured that way, or it is simply a part of the way it works.

IPs are accepted but discouraged

In conclusion, while an IP address is technically allowed, it is not widely accepted and is in fact highly discouraged. However, because it is technically required to be accepted for mail server, we find that many servers may behave differently when they encounter them. The DOTS Email Validation service will attempt to verify these types of email addresses.

If the IP address is bogus and does not resolve, then the Email Validation service will fail the email address. If the IP does resolve and communication can be established with the recipient mail servers then it may respond with a temporary reject code (soft bounce), a permanent reject code (hard bounce) or it might accept the email. If the mail server does accept the email, there is a possibility that it will be delivered to a catchall mailbox. Overall, regardless of how an EV service responds to an email address with an IP instead of a domain, you should give some thought on whether you want to keep these addresses in your mailing lists or not.

If you would like to see how a validation service works, please sign up for a free Email Validation API trial key and test up to 500 email addresses.

 

Oh No, You’ve Been (Email) Blacklisted! Now What?

Blacklisting is the email equivalent of being put on Santa’s naughty list. Except the consequences can be much worse than not getting presents: it can keep your business’ emails from getting through to clients, prospects and others. This article will show you how to tell if you’ve been blacklisted, and what you can do about it.

Why good people get on email blacklists

So how did you get on a blacklist in the first place? If it is because you are an incorrigible spammer, well then. But most people reading this article are actually innocent victims of other people’s actions, or make common rookie mistakes. Here are some of the most common reasons you might end up on a blacklist:

Your IP or server was blacklisted. This can happen if spam or excessive activity is detected from your email server. This can particularly be an issue for small businesses using shared hosting, where multiple clients share the same email server and anyone’s behavior could potentially affect your ability to send.

Someone hacked your account. If someone surreptitiously gains access to your account, whether through malware or fakery, they may use your account to send unsolicited email to others. Worse, if the hackers can access your contact list, they may spam your contacts to give their messages the seeming legitimacy of coming from you.

You emailed a spam trap. This is often an issue for people who rent third-party lists, or aren’t as cautious as they should be about acquiring email leads. Spam traps or “honeypots” are email addresses set up for the express purpose of attracting spam messages – they belong to no one, and would have no reason to receive mail otherwise. Send mail to these addresses, and you will be blacklisted. (Note that our DOTS Email Validation product checks your email lists for known traps like these, and is highly recommended for validating and cleaning your email leads.)

You sound too spammy. Even if you aren’t an actual spammer, you could possibly get blacklisted for sounding like one: for example, watch out for breathless subject lines using lots of capital letters, exclamation points and spam catch phrases – here is a good style guide from email vendor Benchmark. You can also get the wrong kind of attention with spammy behaviors such as flooding a recipient’s server with large amounts of email at once.

How can I tell if we are on an email blacklist?

There are numerous online tools such as this one, where you can enter your IP address to checked against major blacklists. Your hosting provider may also offer a blacklist checking tool. Note that there are well over 100 blacklists, and some are much more critical to your email marketing than others.

This article from server support firm rackAID profiles some of the more important ones, which generally fall into one of the following areas:

  • Reputation-based lists: Lists such as SenderScore block messages from IPs based on their accumulated scored reputations for spam-based behavior, plus an evaluation of the email itself.
  • Spam trap-based lists: These include the Spamhaus Block List (SBL), Spamcop, the Barracuda anti-spam list and the Passive Spam Block List (PSBL), all of which are at least partially triggered by sending email to spam traps.
  • Behavior-based lists: The Composite Blocking List (CBL) and the Exploits Block List (XBL) from Spamhaus block IPs based on known spammer behaviors such as dictionary attacks, open proxies or hijacked IP addresses.

Annoyingly, individual organizations may blacklist you as well as a result of perceived spam activity. Usually you will get informed about this when you try to email their domain, with instructions for how to get reinstated.

OK, so how do we get off these email blacklists?

The short form answer is “it depends.” Or, more accurately, visit the website of the offending blacklist and follow their instructions for removal.

In many cases, getting removed from a blacklist is as simple as asking. In other cases, you may need to make sure that the triggering behavior stops first. And in more rare cases, such as reputation-based blacklists, you can’t directly ask to be removed, other than by improving your reputation score over time. No matter what the process is, it will, of course, be important to take care of the problems that originally put you on these blacklists.

Getting on an email blacklist can be costly, but usually not permanent, if you are acting in good faith. In most cases, if you aren’t grossly at fault, getting life back to normal should be relatively straightforward. And remember that we can help you create an email data quality strategy for staying off of these lists in the first place – our technical team is happy to consult with you anytime.

A Brief Look at the Journey of an Email Message

How do emails actually get from point A to point B?

Most people have no idea. They don’t stop to wonder how an email message is sent and delivered when clicking the send button. If you were to ask them they might reply with,  “Of course, it’s simple. It gets sent to the cloud.”

But an answer like “the cloud” is only part of the overall journey. For most, how an email address is sent is simply techno-wizardry magic, and the details don’t really matter to most people. It only matters that the email message is delivered, and how that happens is not important to them. The purpose of this article is to show you what really happens with an email message.

How Email Works

Details matter to us, but we understand that not everyone likes or needs to get bogged down by them. If you were to search for “How Email Works” then you would find a variety of articles ranging in detail and complexity. The path of how an email message is sent is often summarized in graphics and flow diagrams, with one of the simplest ones shown below.

This diagram, which reads left-to-right, shows the journey of email messages broken into five parts. Please keep in mind that it is not complete and that it fails to cover a couple of scenarios, but overall it is a good starting point. We will add some more details and cover some common scenarios as we move along.

  1. To start, a sender sends an email message. The sender will do this using an email client, which is sometimes referred to as a Mail User Agent (MUA). This can be an application running on the sender’s desktop or mobile device.
  2. The Sender’s MUA will establish an SMTP connection with their Mail Server, and that server will, in turn, relay the message to the recipient Mail Server.
  3. The Sender’s Mail Server then queries the Recipient’s Mail Server and routes a connection to it.
  4. The Sender’s Mail Server establishes a connection with the Recipient’s Mail Server and transmits the email message.
  5. The Recipient Mail server receives and stores the email message so that the recipient MUA may retrieve it via POP or IMAP.

These five steps are about as basic as one can get in describing the journey of an email message. The main takeaway from this flow diagram and others like it is that it establishes that communication is occurring between mail servers. Mail servers communicate using the Simple Mail Transfer Protocol (SMTP). This protocol dictates how mail servers are supposed to behave and send messages to one another.

However, not all mail servers are entirely compliant. Large service providers such as Microsoft, Yahoo and Gmail will likely have their own specialized systems in place for handling internal message communication over their vast networks. Even small businesses with only a few or even just one mail server may configure their networks and mail server(s) in a way that is not fully compliant. However, when it comes to external communication between mail servers, they are not expected to stray too far off from SMTP, as this can easily cause a breakdown in communication.

The Mail Server

Mail servers host the environment for one or more domains as well as the user mailboxes for those domains. They are responsible for sending and receiving email messages, and they are often made up of multiple agents that work together in order to accomplish this:

  • Mail Transfer Agent (MTA) – Is responsible for transferring email messages, often referred to as the either the SMTP Server, Mail Exchange or Mail Relay. Commonly communicates over port 25.
  • Mail Submission Agent (MSA) – Is responsible for communicating with the MUA and handing the email messages to the MTA for delivery. Commonly communicates over port 587.
  • Mail Delivery Agent (MDA) – Is responsible for delivering email messages to the local recipient’s mailbox and is also known as the Local Delivery Agent (LDA).

These agents work together to receive and deliver email messages for their users. Collectively they are considered the Mail Server, but some MTAs will include MDAs and some of the functions of the MSA. Therefore, it is not uncommon for MTAs, in general, to be referred to as the Mail Server.

Local Mail Delivery

In the diagram above we see the path that an email message takes when it is sent to a recipient with the same domain as the sender.

This sender still sends an email message using an MUA that connects to the mail server. Standard connection ports are port 587 and port 25; however, some mail servers may specify their own particular ports and/or require an encrypted connection for security. The MUA connects with the MSA to authenticate the Sender as a user of one of the domains that are hosted on the mail server.

The MSA then receives the email message from the Sender MUA and checks that it conforms to enforced policies. It then delivers the message to the MTA for transmission. Since the recipient domain is the same as the sender, the MTA does not have to communicate with another MTA. Instead, the MDA will handle the delivery to the recipient’s mailbox, where the Recipient MUA is then able to retrieve the message.

Sending External Mail

External mail delivery works similarly to local mail delivery. The sender MUA connects to its mail server where it is authenticated by the MSA. The MSA then receives the email message and passes it on to the MTA.

This is the point where external mail transmission will traditionally differ from local mail delivery. Instead of the MDA delivering the email message, it will be the Sender MTA that will transmit the message to the recipient MTA. It typically does this by querying a Domain Name Server (DNS) for a domain’s Mail Exchange (MX) records. An MX record is used to identify a domain’s mail server. Some domains may have more than one MX record and if so, then multiple records will be returned. Each record is assigned a preference number to prioritize which mail server would be preferred for a connection.

Receiving External Mail

When an MTA receives external mail, the overall process is generally the same as local mail delivery with the exception that the MSA is omitted from the process. This is because the MSA is responsible for communicating with the MUA only. When receiving external mail, the messages are coming from another MTA, commonly on port 25.

Some mail servers and networks are protected by firewalls and anti-spam systems.

Protected Networks

This diagram is an example of what external mail from another MTA to a protected system may look like. In this case a firewall with built-in spam protection.

Firewalls can protect mail servers in various ways. Firewalls are commonly used to block unwanted IP connections and often make use of various blacklists to do so. Ones with built-in spam protection often check for known spammers, and some will inspect the contents of the email message for known malicious links, domains, attachments and various other embedded objects. Spamming techniques are becoming more sophisticated and problematic. Therefore, protection methods are also evolving and becoming more sophisticated as well.

Microsoft, for instance, has developed its own protection service called Exchange Online Protection, and describes it as such, “Microsoft Exchange Online Protection (EOP) is a cloud-based email filtering service that helps protect your organization against spam and malware, and includes features to safeguard your organization from messaging-policy violations.”

The Microsoft EOP Overview page does a good job of explaining how their system works and is comparable to what one can expect from protected mail servers. In their case, they use three distinct levels of filtering: first, a check of the sender’s reputation, followed by subsequent checks against common mail flow rules, as well as, content often found in spam. Messages that pass all three levels of checks are then delivered.

How EOP Works

Piecing it Together

Now that we have gone over some of the basics of email delivery and reception, let’s put the pieces together.

Comparing this diagram with the five-step diagram at the beginning, we have:

  1. Sender MUA sending the email message.
  2. Mail Server, which is comprised of the MSA and MTA.
  3. DNS and Internet Cloud.
  4. Firewall/Anti-Spam protection and Mail Server, which is comprised of the MTA and MDA.
  5. Recipient MUA retrieving the email message.

Again, this is a very basic look at how email is sent and received. We have not gone into details for each step or the underlying protocols, we have barely mentioned security and encryption, and we have not gone over any of the large-scale email service provider systems. So, while the path of sending an email message can essentially be broken into five steps, the overall journey is actually much longer and more complicated. There is a lot that can go wrong, and if you are working on any kind of email marketing campaigns, you want to make sure that you use a validation system that knows its way around.

Many emails flying into a trash bin

Identifying Disposable Email Addresses: A Better Approach

Disposable email addresses – also known as burner emails, throwaway emails, temporary emails or fake emails – are commonly touted as a useful tool for keeping one’s personal or business email address private and clean of spam. Not to be confused with alias email addresses (which generally forward to a primary email address, and are therefore more likely to be read), there are different types of disposable email addresses, and they can work in a variety of ways.

In general, a user will submit a disposable email address instead of their real one, which in theory should help keep one’s own email protected from spam without their primary email and/or private data being exposed. (Note that we say “should”: there are some unscrupulous disposable email providers out there, so as with all things concerning the internet, users must be careful.)

Disposable email addresses may sound great for end users, but they can be problematic for legitimate businesses and marketers. One could easily argue that disposables are successfully doing their job when it prevents a marketer from emailing an end user, but this also means that businesses are forced to adapt their marketing strategies. One such strategy: trying to identify these disposable email addresses up front, to have a more accurate view of your email marketing assets.

A simple (but flawed) strategy: email lists

Disposable email addresses are commonly identified by static lists. There are many online communities that pool together their own lists of known disposable domains and email addresses. However, static lists are a poor long-term solution, as they can quickly become stagnant. Some communities do their best to keep their lists up to date, but there are still many potential problems with this strategy:

  • Lists often lack standardization, which can lead to implementation issues. There are many disposable services available worldwide, and some community driven lists and solutions are dedicated to just a single disposable service.
  • These lists frequently contain legitimate records for domains and addresses that are not disposable.
  • In order for a disposable to make it on to a list it first needs to be reported. By the time that happens, and the data makes it way into a solution, the list may already be partially outdated. Moreover, disposables frequently change and not all disposables are reported.
  • Using a list strategy requires constant vigilance. It’s trouble enough staying up to date on just one disposable service, but trying to stay on top of multiple others as well as new ones as they pop up is often a losing battle.

Lists of disposable email addresses are a reactionary solution at best. Worse, they only scratch the surface of the problem. Disposables are constantly changing, with new ones appearing and old ones disappearing all the time. It is impractical to rely on a simple list strategy to try and successfully identify a disposable.

A better approach: organic data aggregation

At Service Objects we like to look beyond simple lists. Instead of looking at one list to perform a simple straightforward disposable lookup, we take advantage of our wealth of data and our years of experience to not only dig deeper, but to also cast a wider net. Our email validation service doesn’t just look at lists, it looks at the whole picture as well as the nitty-gritty.

We observe various behavior patterns to better identify specific activities and ties to these activities, not just for disposables but for a variety of email types – malicious or otherwise. This allows us to assign values to these activities and even compare them against other activities. Using complex algorithms along with machine learning we can intelligently determine if a value is directly or indirectly related to a particular issue, such as being a disposable address.

As sophisticated as this solution is, note that we won’t always be able to successfully identify a disposable address. Sometimes all the variables don’t match up just right, and sometimes there just isn’t enough data. However, the service will still often be able to identify such email address as being malicious or potentially malicious, in which case you would likely want to reject the email address anyway.

The sophisticated solution

Disposable email addresses are a real headache for businesses and marketers. As with most things regarding email addresses, they are a much more complicated problem than one would normally think. A problem that requires more than a simple list as a solution. They call for a sophisticated solution.

Our DOTS Email Address Validation service keeps tabs on millions of domains. It monitors various behavior patterns and leverages multiple sets of data. As domains and data continue to grow, so does the service – becoming smarter and better. The service can adapt to the constantly changing disposables, making it better suited to identify them as they pop up. Not because it’s trying to keep up with them, but because it’s anticipating them.