Originally the Internet was a tool for scientists doing research, and computing resource sharing in open trusty environment. Unfortunately that is a thing from the past.
These days a few people who are determined to spew unsolicited junk to as many people as possible are finding ways to get systems, not their own, to do the actual work of distributing the messages:
That is, following things (may) happen:
In all cases, if your system has the dubious honour of being a globally reachable open relay (which was all right before about 1995-1997!), your system resources are in danger of becoming abused.
If your host is a relay (B in the picture), you may either get your own host into several possible different relay-blocking lists, and/or you may drag your ISP's major email relay into those lists too!
Be not surprised, if in the latter case both your ISP, and ISP's other customers are getting somewhat mad at you when your open relay is causing trouble to them...
You will in essence have following possibilities:
You may have sensible reasons for having a fully reachable SMTP-protocol server in your network -- e.g. remote workers who need to reach the smtp-port for some purpose (usually no such reason is valid for very long.) However: In most cases your own people don't need to reach your own SMTP server with SMTP protocol when they are not within your own network! (But if you insist needing it, you hopefully also know how to run secure shop ?)
To have the email to work, when the limited access to the SMTP protocol servers in your network is enforced, you will need proper entries in the Distributed Domain Name Service (DNS) system. In this style:
TARGET.DOM. IN MX 10 TARGET.DOM. TARGET.DOM. IN MX 20 FIREWALL-OF.TARGET.DOM. TARGET.DOM. IN MX 30 RELAY.ISP.DOM. TARGET.DOM. IN A 126.96.36.199 FIREWALL-OF.TARGET.DOM. IN A 188.8.131.52
The overall idea is that when email source is using DNS data for routing, lowest of the priority values (10/20/30 at above sample) is attempted first, and progressing upwards.
If the message has arrived for
RELAY.ISP.DOM, it does
notice that it is in the MX list, and it will drop off all possible
entries which have same, or (numerically) higher priority value, as
it in itself has.
After such MX list purging, the host
RELAY.ISP.DOM will again
attempt delivery to the lowest priority system (
and if it now can reach it, the message gets delivered, otherwise next
FIREWALL-OF.TARGET.DOM) is chosen for delivery.
If none of the MX defined hosts are reachable, message is queued and retried latter (from minutes to hours latter).
In implementing anti-relay measures many systems stumble at various snafus.
RELAY.ISP.DOMsystems above) system must be able to relay (correctly) to all domains they are backup MXes for.
Many systems have static tables listing domains they are allowed to do inbound MX relaying for. Very often those datasets are incomplete...
... that is, with above MX example, if
does not have explicit mention of
TARGET.DOM as destination
domain it will allow relaying for, it may reject the domain it has been given
at the DNS datasets for relaying.
There exist also software which does this relaying control by checking that the destination domain has MX records, and that relaying machine is one of the servers listed at them.
However, in order to avoid abuse, those MX analysing systems may also have additional checks that they will do relay only if lowest precedence MX entry has their A record(s) at networks for which the server will do relaying. (E.g. an ISP system may check, that MX destinations really are at their customer networks.)