Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

[Hector Santos <[e-mail]>]

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