On 12/28/2020 1:17 PM, Michael Thomas wrote:
On 12/28/20 10:05 AM, Seth Blank wrote:
We agreed to split aggregate and failure reporting into different
documents, and this split was discussed on the list several times,
as well as at IETF 108.
The intention was to split apart the key components that
realistically get updated in different manners / at different cadences.
Aggregate reports and failure reports get used in wholly different
manners, have fundamentally different use cases, are implemented in
wildly different ways, and have completely different privacy and
security considerations. Hence, we agreed they should be split into
separate documents, so each can be concise, to the point, and
independently updated.
Does that mean all of the reporting? So that DMARC is really ADSP-bis?
When Seymour Cray was asked by his engineers building the Cray super
computer, what primary language should they use for the new concept of
Vectorization computing, Seymour responded; "I don't care what
language we use ... just call it FORTRAN!"
It's marketing now, folks. It was what academia was teaching and
industry engineers were using at the time. Lets just get the
DKIM-POLICY model done and call it DMARC. I really don't care because
the basic fundamental concept has been established and to me, that is
the most significant gain we have here - the DKIM-POLICY DNS LOOKUP
concept has traction.
Yes, functionally, they were all the same, SSP, ADSP, DSAP and DMARC,
from the basic LMAP "Lightweight Mail Authorization Protocol" concept
of using an author domain for a DKIM-POLICY DNS lookup model. DMARC is
the latest with a different syntax language that has gained traction.
I support DMARC for that only reason -- its about TIME!! I rather we
define the protocol DKIM-POLICY Model because we already have a
DKIM-TRUST model in the standard.
Nonetheless, now we can piggy-back off the _dmarc.example.com DNS
lookup rather than _adsp._domainkey.example.com.
All the same concept, therefore all the same problems. Lets get DMARC
done as a basic-lookup protocol and begin adding more to it related to
3rd party authorization protocols which can piggy-back of the DNS
call. Reporting should of always been a separate consideration.
PS: Consider how many DNS lookups an all-things SMTP receiver does for
port 25, non-authenticated/Authorized connections. For wcSMTP:
At connection:
IP Geo Location Filter
IP DNS RBL
At SMTP before DATA
Maybe EHLO domain DNS matching check
Maybe EHLO domain SPF check
Maybe MAIL FROM SPF check
Maybe MAIL FROM Call Back Verifier (MX)
At SMTP DATA if it gets this far:
Maybe DKIM check
Maybe ADSP 5322.From check
Maybe DMARC 5322.From check
Maybe ATPS 5322.From check
Maybe VBR 5322.From check
Overall, there are a lot of calls today per SMTP session.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
