Our document needs a section on server controls.
Impersonation requires a server that allows impersonation messages to be
created. This means that impersonation usually comes from attacker-owned
servers. Legitimate infrastructure services should, and usually do,
implement controls which prevent impersonation.
Impersonation prevention begins with enrollment controls that prevent
service accounts from being created using false identities. I do not
perceive this as a significant problem, but the NIST documents on digital
identity are a very good resource and could be referenced.
After enrollment, infrastructure services should, and usually do, require
authentication for message creation. The specifics vary with the service:
- Email Service Providers send messages after authenticated login using
a submission port or API call.
- Email Domain Hosting Services authenticate both domain administrators
and domain members so that messages can only be generated for the
registered domain. Impersonation messages may be forwarded, depending on
the quality of inbound and outbound filtering, but standard controls
prevent impersonation messages from being originated.
- Mailbox providers require authenticated login to originate messages.
Impersonation messages may be forwarded, but the provider's inbound and
outbound filtering will seek to prevent that from occurring.
- "Bare metal" and other infrastructure services should prevent
origination of impersonation messages by blocking outbound port 25, so that
all outbound mail must be routed to a mail store server submission port or
an ESP vendor's API. Responsibility for impersonation prevention then
falls on the mail store server or ESP.
- Outbound email filtering services provide an external control on
messages originating from sender-owned infrastructure. These services
authenticate their client submissions and then screen those messages to
prevent a variety of threats, including malicious impersonation. Because
email filtering services often provide both inbound and outbound filtering
to their clients, they are well positioned to prevent impersonation through
forwarding.
- Forwarders become trusted to the degree that they are able to prevent
malicious impersonation and malicious content from being forwarded.
Recently, I have been dealing with a Bare Metal hosting service that did
not understand the need to block port 25, and as a result has been
repeatedly used by attackers to send impersonation email. This recent
experience is the motivation for requesting a section on server controls.
These principles also provide insight into the evaluation process.
A malicious message always requires a poorly-controlled or
attacker-controlled server. When an impersonation attack is discovered,
the root cause analysis should always end on a server organization. If
the server organization only sends unwanted messages, the organization can
be blocked based on host name or IP address range. If the server
organization is a poorly-controlled infrastructure service which sends both
wanted and unwanted messages, the defense becomes more difficult. Until
the problem is corrected, every message may need to be sent to quarantine,
so that wanted and unwanted messages can be separated.
Conversely, once a server organization is trusted to have implemented these
controls, its messages can be judged to be free of impersonation even when
DMARC Pass is not present for some reason.
Doug Foster
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
