Posts Tagged ‘IP Address’

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.

 

IP Address Validation: What Can I Learn From an IP Address?

What is DOTS IP Address Validation? First, it helps to understand what an IP address is.

IP addresses are like a mailing address, but for devices on the internet. It is a 32-bit number that uniquely identifies a device and their network. An IP address is typically written in decimal digits, formatted as four 8-bit fields separated by periods. Each 8-bit field represents a byte of the IP address. This form of representing the bytes of an IP address is often referred to as the dotted-decimal format. The bytes of the IP address are further classified into two parts: the network part and the host part.

So what is IP Address Validation and what does it do?  It is a real-time API service that analyzes IP addresses to determine their quality while returning key details like location and device type. These details can be used in a number of different ways, from helping fight fraud to geo-targeting your marketing message for better campaign performance.

The service is simple to integrate and only requires two inputs: an IP address and the license key. From there, our algorithms take over and compile its findings into the following output fields.

Output fields from IP Address Validation

Certainty

This is an overall score given to the body of the outputs with respect to the accuracy of the results provided. This number may vary based on several underlying factors, including data source. The score can range from 0 to 100, and with typical results in the high 90’s.

City

The city location of the IP address.

Region

The state, province or region (depending on the country) location of the IP address.

Country

The country location of the IP address. With this information, our customers can flag countries that have unique compliance or regulatory rules, like the EU’s General Data Protection Regulation (GDPR) as an example. Other customers have used this in their call centers to ensure the customer service representatives assigned to the customer can speak the native language(s) of the country flagged.

CountryISO2/ CountryISO3

Two and three letter abbreviations CountryISO2 and CountryISO3 respectively, which can easily be programmed against, among other things.

Country, along with the other location data points, can be used to identify where your traffic is coming from and how to serve up information to people in different countries or areas. It can also be used to exclude countries or areas as well: for instance, if there is a particular country that does not make sense to do business with based on your business model or product type, you could exclude those IP addresses from participation on parts of your web site, or even exclude them from submitting forms and serve up different content.

PostalCode

The US postal code of the IP address (US only).

StateFIPS

The state Federal Information Processing Standards code for the IP address. This code is used to uniquely identify states (US only).

CountyFIPS

The County Federal Information Processing Standards code for the location of the IP address. This code is used to uniquely identify counties throughout the US (US only).

Designated Market Area (DMA)

This is also a US only data point. It represents a media market or broadcast (television or radio) market, also known as a media region where people in that area will get the same broadcasts. Think advertising and getting your message across to a group of people in the same market. This data point also works well for customizing internet advertising and offerings.

MetroCode

This is tied directly to the Designated Market Area (DMA) and the code for the market DMA (US only).

Latitude/Longitude

The latitude and longitude coordinates for the IP address. Among other things, you can plot these coordinates on a map, or find distances between IP addresses, as well as, the distance between you and the IP address. Or even better, the distance between your warehouse and the IP address. These come back as separate fields in the output for easy processing.

IsProxy/ProxyType

IsProxy is a true or false flag that indicates if the IP is a known proxy. ProxyType describes the type of proxy it is. These will also come back in the validation response in separate fields. Proxy servers are like middlemen that all your web traffic runs through, essentially hiding your actual IP address and potentially filtering content coming and going through the proxy. You may want to handle varying proxies in different ways, such as not processing any records coming from an anonymous proxy or deliver different content to users behind a satellite proxy. These are the types of proxies we flag for:

NONE

These are users that are not found to be behind a proxy.

PUBLIC

A proxy server that is openly available and accessible by any internet user.

PRIVATE

A dedicated server that is used exclusively by one client at a time.

ANONYMOUS

A proxy server that does not reveal the users real IP address.

SATELLITE

Proxy is provided by a satellite connection. Typically used to provide an internet connection to rural areas.

PossibleMobileDevice

As you may have guessed from the name of this field, it indicates if the IP address is believed to be coming from a mobile device. Again, this can be used to deliver content differently. It can also help with analysis of your user base to gain better a understanding of how your web site is being accessed or what group of users tend to respond better to your offering.

ISP

The Internet Service Provider (ISP) that assigns the IP address.

NetblockOwner

The network owner to which the IP address is allocated. These usually fall into a range of IP addresses that are typically owned by an ISP or data center.

HostNames

The hostname associated with the IP address. Hostnames are labels assigned to devices on a network so they can be distinguished from each other. If more than one hostname is found then the names will be returned in a comma delimited list.

IPNotes/IPNoteCodes

IPNotes and IPNoteCodes reveal any notes about the IP that the system was able to determine and the associated code for ease of processing. Currently, we have two notes, but more can be added in the future as the operation expands:

PotentiallyMaliciousIP

This is assigned IPNoteCode 1 and indicates that the IP address has a high probability of being bad/malicious.

MaliciousIP

This is assigned IPNoteCode 2 and indicates that the IP address is almost certainly bad/malicious.

A quick note on malicious IP addresses

The two codes noted above deal with identifying malicious IP addresses. Due to how often an IP address can be reassigned, an IP address that was once detected as malicious may stop being malicious later and vice-versa. How you handle IP addresses that get flagged with either of these codes is important. Some organization may ban them altogether. As part of your data hygiene strategy, we recommend re-validating IP addresses periodically rather than making a permanent designation.

More to IP Address Validation

For this blog, I pulled some of the main outputs from the table in our IP Address Validation developer guide and expanded on how they could be helpful in your business. By no means does this cover all the instances that IP Address Validation can be used, but it should give you a pretty good idea of its capabilities. By appending the related IP address data our service provides, you can develop strategic insights, flag potential fraud and create effective business logic that creates efficiencies and improves performance.

We are happy to share some of the best practices we have seen using IP Address Validation, just give us a shout.