Thanks for doing this work. It cleans up a messy corner of DMARC.
It appears that OLIVIER HUREAU said:
>I was personally thinking about the following options:
>
>1) Specify Version "2" ...
>
>2) Explore a JSON Format for Aggregated Reports: ...
>
>3) Create an Extended XML Schema for
Hi,
As mentioned here: [
https://mailarchive.ietf.org/arch/msg/dmarc/ouSBtpMhD5KJp2osPfUXJktuoMQ/%C2%A0
| https://mailarchive.ietf.org/arch/msg/dmarc/ouSBtpMhD5KJp2osPfUXJktuoMQ/ ]
I have found out that the current reporting ecosystem uses two types of XML
Schema Definitions.
During
On Tue, Nov 14, 2023 at 5:33 AM Seth Blank wrote:
> As Chair, Douglas, again, what operational issue per charter are you
> trying to address, and where is your suggested text to address?
>
I agree, this far exceeds DMARC's charter. None of this to say the topic
is not one worth exploring, but
As an individual, I concur with Richard
As Chair, Douglas, again, what operational issue per charter are you trying
to address, and where is your suggested text to address?
Seth
On Tue, Nov 14, 2023 at 07:41 Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> A server is anything
A server is anything with an IP address and the potential to send mail
using unauthenticated mail on port 25.
Our most important server control is the foundation of SPF: a multi-tenant
server will only allow tenants to originate messages using their own
domain. Without that control, SPF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Douglas Foster writes
>Our document needs a section on server controls.
what is a "server" ? did you mean an MTA ??
>Impersonation prevention begins with enrollment controls that prevent
>service accounts from being created using
Our document needs a section on server controls.
Impersonation requires a server that allows impersonation messages to be
created.This means that impersonation usually comes from attacker-owned
servers. Legitimate infrastructure services should, and usually do,
implement controls which
