Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dotzero <[e-mail]>]

On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz <[e-mail]>
wrote:

>
>
> On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) <[e-mail]>
> wrote:
>
>> On Fri, Aug 14, 2020 at 7:31 AM Dotzero <[e-mail]> wrote:
>>
>>>
>>> I've been involved in setting up DMARC with a policy of p=reject for
>>> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
>>> in getting buy-in across the organization that it is a worthwhile effort,
>>> getting control of your organization's mail flows and ensuring policies and
>>> procedures are communicated and followed. For complex environments there
>>> may need to be some automation required for creating and maintaining
>>> private/public key pairs and DNS records but that is much more
>>> straightforward than the aforementioned heavy lifting.
>>>
>>
>> Also note that said "heavy lifting" is not a one time expenditure of
>> effort. Having hoisted the weight bar above your head, it requires
>> organizational will and ongoing knowledge to stick to the higher bar week
>> in and week out. Entropy is never your friend in an organizational security
>> context. Neither are acquisitions :-)
>>
>> Yes, and that's why I use DMARC mostly as a tool for reporting. My
>> clients are typically small businesses who are worried about selling
>> widgets not about email so even if I help them set up email perfectly, they
>> could make a change a year from now without updating their SPF record or
>> deploying DKIM. I just changed my policy to reject (just for fun) assuming
>> this email will get through because of DMARC's OR logic.
>>
>
Which brings us back to the question of organizational implementation
issues vs  interoperability issues. Can a technical standards body solve
the problem of organizations shooting themselves in the foot because they
are worried about selling widgits and not about email? Why do I have a
feeling they start caring about email when it no longer works for them?
They have created a self induced personal interoperability issue. If they
changed their MX to use a random port other than port 25 to receive SMTP
connections would you suggest that the RFC should be written to
accommodate that?

Michael Hammer