18

Usually an email has a domain name on the right side of the @, so you can identify an organization or a company. This domain is in fact nothing other than a "name" or an "alias" for an IP address, resolved by the name server.

I think this could be used for example for the Internet of Things, because there are many more possibilities compared to POST and GET like "many to one" or "one to many".

Is there a way to send and receive emails directly to and from an IP address, as user@xxx.xxx.xx.xxx for example?

  • 6
    Aside: If you think HTTP is too restrictive for IoT, take a look at MQTT or XMPP. – Roger Lipscombe Apr 4 '18 at 10:16
  • 3
    A domain is more than 'a name for an IP address'. A domain can publish a lot more information regarding its mail service (via its DNS entries), which may include several IP addresses for several mail servers (ie for load balancing or fallback purposes). – jjmontes Apr 4 '18 at 14:07
  • 4
    Email isn't one to many either, it's one to one, and then the server may spread the message to many. You could do a http post to a server, and then have many clients read off that server in the exact same model email uses. – djsmiley2k Apr 4 '18 at 15:59
  • 2
    As someone who periodically has to do network archaeology, please don't hard-code IPs. DNS is not difficulr, and DNS servers like dnsmasq are lightweight while allowing host overrides. Internet IPs will change over time. – Criggie Apr 4 '18 at 20:03
  • 1
    The domain is not an alias for an IP address. Specifically email has MX records where the domain name maps to one or multiple tuples containing both a priority and an hostname (where the email will be delivered). You are mixing two different concepts: naming (who to send it too) and adressing (where to send it). – Patrick Mevzek Apr 5 '18 at 2:39
18

For emails, a domain is not merely an alias or human readable form for an IP address: mail exchanger MX records exists to specify mail servers responsible for accepting email messages on behalf of a recipient's domain. There could be several servers accepting mail for the domain, and they are not necessarily on the same IP that's in the A record for the domain. A mail system can have several servers: incoming servers might be separated from outgoing servers and mail storage servers etc. The A record is only used when there's no MX records specified for the hostname.

However, there's no (other) limit in email address format that you could not send emails directly to <user@hostname.example.com> or even <user@[198.51.100.10]> (IP with the square brackets). If there was a mailserver that accepts email using the plain hostname or even IP address, it would do. But what you are suggesting doesn't work globally in practice:

  • Most email systems have several domains and need to handle email separately for them all. The username itself may not have been bound to any actual mailbox as <user@example.com> might be a different person than <user@example.net>
  • While this was common couple of decades ago, fighting spam has made things more complicated and accepting email has strict limits.
  • The usage of SMTP port 25 is very limited on consumer grade internet connections due to abuse (spambots). There isn't really that much use of SMTP for IoT devices.
  • 2
    But if there is no MX dns record for a domain (or an IP) mail is delivered (or attempted to be delivered to) the domain part of the email address (hostname or IP address). And the receiving server has to be configured to handle mail for that hostname/IP address. – ivanivan Apr 4 '18 at 13:54
  • 1
    It can handle mail for the hostname. Not every server in the world handle mail at all. Most Unix/Linux based servers do have SMTP server to handle internal mail (from cron etc.), but they can function well without, too. – Esa Jokinen Apr 4 '18 at 14:28
  • 1
    Esa - if you point your MX record to my postfix servers, a SMTP connection will be made BUT my servers aren't configured to handle mail for your domain in any way shape or form, so you get a bounce. BUT my servers are set up for multiple specific domains and users, all coming from a mysql server. It all depends on 1) Is a mail server actually running at the IP you are sending mail to and 2) Is said mail server configured to accept mail destined for that IP or just a specific domain/domains, or any domain at all (only matching the user part of the address) – ivanivan Apr 6 '18 at 13:14
14

Many SMTP servers (e.g. sendmail) handle user@[aaa.bbb.ccc.ddd] email addresses BUT

  1. Some SMTP server do not handle/recognize it
    They may refuse to accept such sender address or be unable to send to such address.
  2. Such addresses may cause problems with some anti-spam software

RFC-5322 : 3.4.1. Addr-Spec Specification


Wikipedia: Email address - domain part

In addition, the domain may be an IP address literal, surrounded by square brackets [], such as jsmith@[192.168.2.1] or jsmith@[IPv6:2001:db8::1], although this is rarely seen except in email spam.

  • 9
    Notice that email addresses like user@[aaa.bbb.ccc.ddd] are correct according to the specification, and the handling is properly defined, so servers that don't handle it are technically "broken" – Ferrybig Apr 4 '18 at 9:07
  • 4
    @Ferrybig: True, since rejecting is technically handling, too. – Esa Jokinen Apr 4 '18 at 13:19
  • Note that "email was sent to specific IP address rather than a host" ranks pretty high in the category of "probably spam" red flags and a lot of AVAS software may decide to silently discard it. – Shadur Apr 5 '18 at 6:54
4

It should work if all involved parties use really modern software.

While SMTP works well layered on TCP,it is, at least in its original form, not in itself a protocol BASED on TCP/IP. If you look at the original RFC 821, a "TCP transport" is defined.... in an appendix.

RFC 2821 (from 1989) considers using numerical addresses "discouraged".

Even far more modern versions of the specs uphold that philosophy to some degree, from RFC5321: "SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. While this document specifically discusses transport over TCP, other transports are possible. Appendices to RFC 821 [1] describe some of them."

However, this RFC - from 2008, which actually makes it very NEW, does sanction the use of "address literals" as "allowed" ("To bypass this barrier, a special literal form of the address is allowed as an alternative to a domain name.") in Section 4.1.3 but still discourages it as a "SHOULD NOT" in 2.1.4.

SMTP, and much of the software built around it, uses hosts, not ip addresses, as its "native currency" - if an "address literal" is usable as a "host", so be it. And so did the (mostly outmoded) non-SMTP protocols (eg UUCP mail) that were used in the email ecosystem of old together with SMTP-based systems.

Relying on every involved system being in full compliance with a 2008 standard might be more risky than it seems.

  • 2
    RFC 5321 #2.1.4 doesn't sanction using address literals: it says SHOULD NOT (and then links to the wrong section). And RFC 2821 isn't quite that old - it was 2001. – Rup Apr 5 '18 at 23:34
  • 1
    I would say this proves my between the lines point :) .. integrated a clarification about that "micro-sanction", thx – rackandboneman Apr 6 '18 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.