Hi Terry,
No one ever proposed an open-ended user access to DNS or APIs that
access the backend, server side files. No, thats a clear security
threat. As a design rule of SE thumb, you MUST never give normal
and/or unregulated users access to system level operations. That is
typically reserved for system operators and administrators, "gods" of
the system. A compromised system, an inside job, bad guy got in,
would be the #1 security threat as it always is for anything else.
When it comes to hosting, a customer with one domain has the same SMTP
and mail hosting functional and technical operational needs and
requirements that a customer with a million domains. If you have a
problem, its a bug whether its small, mid, large and operate
privately, publicly or mixed with its domains. That is how I've
designed hosting products that is for all customer types.
For this application need, how one registers domains is entirely up to
the domain including not registering at all as a corporate policy.
Thats a product feature. It SHOULD also be a product feature that
domains MAY register resigner domains in DNS for the purpose of
performing domain authorization queries.
Either way, its a feature to have for those who can do it and many
customers will have the ability to handle their delegation of
resigners using DNS. If one of your domains has a tougher problem
with it, then you can't do it, period. That is why microsoft.com has
an SPF hardfail but the other microsoft property public service
domains do not.
Let me ask you this, if you implement the conditional @fs method for
your MLM,, are you going to honor the restrictive policies of incoming
domains, those who will not want to have resigners of any kind and
will not use the conditional @fs method themselves (no need)? Will
you honor this rejection policies at the MLM, and in reality, across
all Microsoft domains receivers?
--
HLS
On 5/9/2015 2:11 PM, Terry Zink wrote:
The reliability aspect is realistic to set a high bar. The decision to allow
unregulated users to publish to the zones of
Hotmail.com/outlook.com/msn.com/live.com/Hotmail.ca/outlook.ca/live.ca... etc.
is one that comes with its own security challenges. This now no longer a way to
allow indirect mailflow to pass DMARC, but instead how to figure out a way to
secure your DNS zone. For the amount of work that would be, I would rather just
inventory all mailing lists and if an email comes from it into a domain
filtered by Microsoft, suppress DMARC.
It's not just Microsoft's consumer brands. Office 365 hosts email for small,
medium, and large businesses - each with their own DNS zone. If we have 500,000
domains [1] and there are 100,000 mailing lists, are we going to publish DNS
records for the full matrix of combinations - 50 billion? Or even 1 billion? We
don't control customer's DNS zones, so we'd have to convince our customers to
publish these records and to do it on a regular basis. I can see nobody
agreeing to do that. And if it won't work for Office 365 then it won't work for
Hotmail, outlook.com, live.com, etc.
I can't see the solution of publishing things in your DNS zone as a workable
solution. That's why I like the conditional @fs DKIM signature better (or some
variant of it) - it's done on the MTA level. A customer domain, example.com,
can sign up for the Office 365 service and not have to publish any mailing list
third party authorization in their zone. Instead, the sending MTA adds the
required DKIM signatures and the receiving MTA decodes the incoming receiving
signatures and does the right thing. The process is transparent to end users,
most of whom don't want to update their DNS zones.
-- Terry
[1] I don't know exactly how many domains we have, I just picked this as an
example.
-----Original Message-----
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos
Sent: Saturday, May 9, 2015 10:13 AM
To: dmarc@ietf.org
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note
Your bar is too unrealistically high for typical IETF project work that is
still in the experimental stages. You should be thankful, we didn't apply
this bar to the SPF experiment.
--
Hector Santos
http://www.santronics.com
On May 9, 2015, at 10:09 AM, Scott Kitterman <skl...@kitterman.com> wrote:
On May 9, 2015 5:00:24 AM EDT, "Stephen J. Turnbull" <step...@xemacs.org> wrote:
Murray S. Kucherawy writes:
Agreed again. And as Terry has said and I think we can infer about
other large operators, it's incorrect to assume (and plain wrong to
assert) that this is an easy problem for them to solve in a
reliable way.
Please define "reliable." I gather you all think that missing some
mailing lists is a bigger problem than missing all of them, but for
the life of me, I cannot see why.
How many solutions do you think operators will be willing to implement? As I
indicated in my utility assessment framework, I think we get a maximum of one
solution that requires cooperative implementations in multiple parts of the
originator/mediator/receiver trilogy. Given that, it had better be reasonably
comprehensive.
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
