I was not proposing what other people should do, nor was I proposing a standards change. I was just observing that we always have choices (with supporting software.)
In this case, if a remote correspondent cannot do acceptable TLS encryption, then the local correspondent always has the option of terminating the connection (cleanly), and communicating another way or not communicating at all. I was describing what was already in place. Our organization does not send outbound mail without encryption. If the correspondent cannot do TLS, we communicate by another method. Some MailFrom domains use encryption so reliably that you can block certain forms of impersonation simply by requiring encryption on inbound messages from those domains. No futures. No protocol redesign. Existing features of existing products. Doug Foster On Fri, Apr 28, 2023 at 5:24 PM Hector Santos <sant9...@icloud.com> wrote: > Douglas, > > In general, you can’t impose or mandate rules under PO RT 25 unsolicited, > unauthenticated sessions. You can do this with ESMTP AUTH a.k.a SUBMISSION > Protocol (RFC????) which is Port 587. Under this port, you can mandate more > Authentication/Authorization than with Port 25 and not using ESMTP AUTH. > > So for example, for PCI, you must use A/A mechanisms probably under Port > 587 because it can be mandated. Not under Port 25. > > — > HLS > > > On Apr 27, 2023, at 7:04 AM, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > > There are options on TLS failure. > > Mandatory TLS is actually pretty common, since PCI DSS, HIPAA and GDBR > have all been interpreted as requiring TLS on email. For outbound mail, > our MTA is configured to drop the connection if encryption cannot be > established. I think this configuration option has become pretty common in > commercial products. Domains that cannot accept encrypted traffic are > handled with secure web relay (Zixmail or one of its many imitators.) In > the case of a report recipient that cannot accept TLS traffic, we would > simply drop the destination. > > For inbound mail, my organization has concluded that data security is the > responsibility of the sender, so we do accept unencrypted messages. > > By and large, mandatory TLS will be implemented consistently, rather than > on a specific message like a DMARC report, so I don't know how much needs > to be said in this document. > > Doug > > On Tue, Apr 25, 2023 at 12:29 PM John R. Levine <jo...@iecc.com> wrote: > >> >> Since the only mechanism is mail and nobody's going to S/MIME encrypt >> >> their reports, I suggest just deleting it. >> > >> > TLS vs not TLS. >> >> I suppose, but that's not up to the report sender. If I say >> "rua=mailto:rep...@cruddy.org";, and the MX for cruddy.org doesn't do >> STARTTLS, what are you going to do? >> >> R's, >> John >> >> _______________________________________________ >> 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 > > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
