Re: [dmarc-ietf] DMARC and Gateways?
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 wrote: > 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 > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC
On Tue, Sep 15, 2020 at 11:55 AM John Levine wrote: > In article bnk2_ckmn...@mail.gmail.com>, > Joseph Brennan wrote: > >"Domain administrators must not apply dmarc authentication to domains > >from which end users send mail that may be re-sent via lists or > >automatic forwarding." -- done. Then dmarc will be simple and > >reliable, and bank statements and similar messages are protected as > >intended. Building in a standard workaround significantly weakens the > >whole concept, doesn't it? > > Unfortunately, we have ample evidence that domain operators will > ignore that advice. > > According to someone who was in the room when Yahoo flipped the > switch, the person in charge said words to the effect that I know this > will screw up everyone's mailing lists and I don't care. > > The irony is, the result being to diminish the effectiveness of dmarc for everybody. Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC
In article , Joseph Brennan wrote: >"Domain administrators must not apply dmarc authentication to domains >from which end users send mail that may be re-sent via lists or >automatic forwarding." -- done. Then dmarc will be simple and >reliable, and bank statements and similar messages are protected as >intended. Building in a standard workaround significantly weakens the >whole concept, doesn't it? Unfortunately, we have ample evidence that domain operators will ignore that advice. According to someone who was in the room when Yahoo flipped the switch, the person in charge said words to the effect that I know this will screw up everyone's mailing lists and I don't care. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC
It must be unusual for an authentication protocol to specify in the RFC how to work around its own authentication mechanism. "Domain administrators must not apply dmarc authentication to domains from which end users send mail that may be re-sent via lists or automatic forwarding." -- done. Then dmarc will be simple and reliable, and bank statements and similar messages are protected as intended. Building in a standard workaround significantly weakens the whole concept, doesn't it? -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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
[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
