Yes, I understood the section to be referring to those types of gateways. I
just don't understand where the problem occurs. There may be other gateways
in the future, so I am reluctant to say it ceases to be important.
I will try to phrase the question better:
It seems that there are three elements of a gatewayed address: The remote
technology destination address, the gateway / boundary device identifier, and
the TCP domain that is used for incoming traffic.
One possibility is that the TCP domain is dedicated to the gateway function.
Mail-to-SMS gateways work this way. They are not a perfect example because I
don't think SMS can send to TCP. But if they did have outbound capability,
the TCP Domain that is dedicated to the gateway function would be able to
comply with DMARC by applying DKIM signatures and publishing an SPF address as
well. Just as importantly, the domain is not shared so it would have the
option of not publishing a DMARC policy at all.
Another possibility is that the gateway ID is a dedicated subdomain of the TCP
domain. If the parent domain publishes a DMARC policy that the gateway cannot
implement, then the subdomain could publish a p=none policy.
The third possibility is that the gateway ID is in the local-part of the TCP
address, so gateway mail is obligated to meet the DMARC policy of the TCP
domain. But even here I have trouble understanding where the problem occurs.
Email to the gateway must route through the TCP domain's MX record, so I would
expect that return traffic would route back through the same path, and the
parent domain could ensure DMARC compliance when outbound mail is released to
the Internet. But if the gateway bypasses the TCP domain and submits using a
gateway associated with the destination email address, then that system should
know that the message is coming from the other technology and DMARC is not
applicable.
The only scenarios where I can generate a DMARC problem are:
- a message is sent from a gateway directly to the destination domain,
bypassing the From domain, and then the message is auto-forwarded to a
different administrative domain. The auto-forward destination will see a
DMARC failure.
- routing is asymmetric, where incoming messages flow through a specific TCP
domain but outbound messages are sent directly from a public gateway to any
address on the Internet. The destination domain will see a DMARC failure
because the public gateway is impersonating the SMTP-equivalent address of
every user on the other technology.
Perhaps asymmetric routing was normative for some of those older technologies.
I just don't know.
DF
From: ken=40wemonitoremail@dmarc.ietf.org
Sent: 9/15/20 9:01 AM
To: "dmarc@ietf.org"
Subject: Re: [dmarc-ietf] DMARC and Gateways?
If you are referring to section 3.2.4. then I'm pretty sure that's referring to
gateways in the protocol sense (see RFC 5598, section 5.4.) which convert
internet mail into a different messaging protocol, such as SMS/MMS or
(historically) UUCP. The interoperability concerns are still valid though there
is much less of this in wild than there was 10 years ago and (for sending) you
can normally put a compliant MTA in front of them.
Ken.
From: dmarc On Behalf Of Douglas E. Foster
Sent: Tuesday 15 September 2020 11:59
To: dmarc@ietf.org
Subject: [dmarc-ietf] DMARC and Gateways?
I was surprised to see email technology gateways included in RFC 7960.
I would expect that a public gateway would use a from address within the
gateway domain name, so that it can accept replies. A gateway dedicated to a
single organization would release messages into that organization on a trusted
path, and anything forwarded out of that organization would be signed at the
outbound mail gateway.
Can anyone who was involved with RFC 7960 comment on whether the gateway
problem still exists?
DF
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
