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: [email protected] Sent: 9/15/20 9:01 AM To: "[email protected]" <[email protected]> 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 <[email protected]> On Behalf Of Douglas E. Foster Sent: Tuesday 15 September 2020 11:59 To: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
