Subject: [dmarc-ietf] DMARC and Gateways?

From: "Douglas E. Foster" <[email-masked]>
Date: Tue, 15 Sep 2020 06:59:26 -0400

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

---

From: Ken O'Driscoll <[email-masked]>
Date: Tue, 15 Sep 2020 13:00:04 +0000

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-masked]> On Behalf Of Douglas E. Foster
Sent: Tuesday 15 September 2020 11:59
To: [email-masked]
Subject: [dmarc-ietf] DMARC and Gateways?

DF

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 15 Sep 2020 13:06:25 -0700

The lack of universal DMARC verification and insufficient flexibility in
the application of enforcement and local policy overrides in the "filter
spam as a service" market (as well as the X.400, SMS, UUCP, Bitnet sort of
protocol gateways) were the problems that we were addressing within this
item in 7960.

--Kurt

On Tue, Sep 15, 2020 at 3:59 AM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> 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.
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 18 Sep 2020 08:35:13 -0400

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=[email-masked]
Sent: 9/15/20 9:01 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [dmarc-ietf] DMARC and Gateways?

Ken.

----------------------------------------

DF

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 18 Sep 2020 08:15:36 -0700

A scenario that you did not list, but which used to be common was a mail
transit path that went both in and out of a foreign protocol. Consider the
example of a message that starts with SMTP --> X.400 (with irreversible
changes) --> SMTP --> recipient. If the inbound and outbound gateways are
not the same, then there is no way for the outbound gateway to simulate the
inbound one.

--Kurt