On 4/15/2015 2:08 PM, Murray S. Kucherawy wrote:
On Tue, Apr 14, 2015 at 3:41 PM, Terry Zink <[email protected]>
wrote:
1. For Hotmail, every mailing list that our users are signed up for would
result in a new DNS entry. How do we manage the lifecycle around that?
Should we automate its addition? Should we automate its removal? Do we
delay email before the DNS entries are published? Should we thereby bypass
the change review process? If so, how do we audit what's going in and
what's coming out of the Hotmail zone?
2. For Office 365, we can't publish DNS entries for most of our customers.
We could tell them what to publish but I guarantee you almost none of them
would for every single mail list their users signed up for, if they had to
do it every day. Most of them probably wouldn't even do it once.
That's the part that doesn't scale.
+1. The mechanism of generating DNS records is not the issue; we even have
an RFC that shows how that could be done in theory. It's the processes
themselves that simply won't scale or would fail to thrive.
-1.
There is no proof of this other than it hasn't been tried at large
scale. Nonetheless, software guys can produce the tools for anyone to
do this, today, successfully. Once again, by far, and I hope you
agree, most domains will not need the level of scale that would begin
to make it too complex to manage. Not everyone has the "complex
processes" which I believe has been overblown and used as a flat out
reason for excluding the most feasible idea we have.
From a pure protocol standpoint, it is a natural fit. We are talking
about satisfying the ADID != SDID condition lacking in DMARC which can
be a protocol option:
DMARC Receivers MAY use DSAP mechanisms for ADID != SDID conditions.
which can translate into product configuration options.
[X] Support DMARC
[X] Support ATPS Extension
[X] Support @FS=
(o) Global (sign all)
(_) Selective (Disabled, Future)
It is unreasonable to impose more complex changes to both signers and
receivers, all of them, with no option to do a simple lookup which is
all that is required. I am open to having both a direct and inband
methods with direct being the most efficient and least costly. You
can not impose costly changes on all when it is clearly not necessary.
IMV, the IETF should not be in a put into position where it is
creating situations for Mail and DNS folks to battle over the highly
subjective belief that it is just too hard to manage DNS records, thus
lets make the mail less DKIM secured and more DKIM complex with more
in-band (RFC5322) information. It isn't going to fly too well.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
