22

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 [email protected] for example?

Improve this question
7
  • 7
    Aside: If you think HTTP is too restrictive for IoT, take a look at MQTT or XMPP.
    – Roger Lipscombe
    Apr 4, 2018 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, 2018 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.
    – djsmiley2kStaysInside
    Apr 4, 2018 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, 2018 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, 2018 at 2:39

4 Answers 4

Reset to default
21

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 <[email protected]> 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 <[email protected]> might be a different person than <[email protected]>
  • 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.
Improve this answer
3
  • 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, 2018 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, 2018 at 14:28
  • 2
    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, 2018 at 13:14
15

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. …

Improve this answer
3
  • 12
    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, 2018 at 9:07
  • 4
    @Ferrybig: True, since rejecting is technically handling, too.
    – Esa Jokinen
    Apr 4, 2018 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-don't-feed-the-AI
    Apr 5, 2018 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.

Improve this answer
2
  • 3
    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, 2018 at 23:34
  • 2
    I would say this proves my between the lines point :) .. integrated a clarification about that "micro-sanction", thx
    – rackandboneman
    Apr 6, 2018 at 10:57
0

I'm running a scenario where the local thing (NVR) used to send emails to Google when events occurred, but it doesn't support TLS1.2 and I was told when I bought it that if I tried patching it, it would brick. So...it can send emails, but no longer to Google. But it can send it to an email server on a local server (Raspberry Pi running Postfix) using IP as I don't want to set up a domain for this. Therefore don't need MX record or anything wonderful - it can be the dodgiest most insecure email server possible...as long as it can forward TLS1.2 as I'm not exposing it to the outside world other to send emails to my gmail account.

Improve this answer

You must log in to answer this question.