Hi Terry,
I understand your point. Just consider, Microsoft still has its DNS
TXT record for its original Caller ID for Email Protocol (CEP), the
original clone of SPF that eventually became Sender-ID:
D:\Users\Administrator>lmap _ep.hotmail.com
Server: ns.santronics.com
Address: 208.247.131.210
Non-authoritative answer:
_ep.hotmail.com text =
"<ep xmlns='http://ms.net/1' testing='true'>
<out>
<m>
<indirect>list1._ep.hotmail.com</indirect>
<indirect>list2._ep.hotmail.com</indirect>
<indirect>list3._ep.hotmail.com</indirect>
</m>
</out>
</ep>"
Early on, MS application developers were high on using XML, it was
being explored for both program and data. Thats just to show you of
the DNS changing mindset for accepting the additional overhead and
increasing usage for app developers. The fact it hasn't been removed
(and please don't yet, I like keeping it for prosperity), shows there
is still some corporate/DNS controls. I do know that hotmail.com was
acquired so that might still mean something people/team wise.
Overall, I believe you are missing the software tools to manage this.
Like most DNS applications like this, it still required the tools.
However, my point, other than believing MS has the resources and power
to do this, when it comes to the protocol itself, it should not, and
it is generally isn't, a reason for excluding such a natural protocol
idea like this even as a protocol option. Its a natural fit to detect
1st vs 3rd party and make authorization decisions.
Finally, consider that its not always applicable across all email
applications, especially for the larger public service area as you
pointed out. But it still applies for many of the other mail hosting
systems including other Microsoft email applications. For example,
the MS Security Bulletins it has message ADID and SDID values such as:
DKIM-Signature: d=email.microsoftemail.com
From: e-mail.microsoft.com
That is a third party. All you need to do is add a ATPS DNS TXT record:
base64(sha1("email.microsoftemail.com")._atps.e-mail.microsoft.com
and manage it of course. No code change is necessary on your end as a
publisher and signer. The change is for DMARC receivers to add a
extension to the lookup logic. Based on RFC4686 (Security threats
Analysis) and RFC5016 (Requirements), the consensus which was also
reflected by the APIs written, it used a ADID != SDID condition to do
a POLICY lookup.
So you can apply this. Harder for Hotmail.com, well understood, but
not for microsoft.com which has a strong policy with known senders.
Your SPF policy reflect this. For signers, well, you need 3rd party
logic before e-mail.Microsoft.com flips the DMARC p=reject switch.
--
HLS
On 4/14/2015 6:41 PM, Terry Zink wrote:
When I talk about scale [1], it's not just a matter of doing DNS lookups.
That's important, but it's not what I worry about because we can solve
it by adding more hardware [2]. Instead, by "scale" I mean "management",
that is, having humans manage the process, or needing humans to do something.
But thats the same problem for everything. How will MS work it out
for your hotmail.com SPF operations? For SPF, hotmail.com has a
relaxed SPF policy with a long list of DNS lookups. Lots of
processing waste here. For DMARC, thousands, perhaps millions, high
volume of mail are getting NXDOMAIN on the expectation there is a
DMARC record.
Hi, Hector, sorry to derail your point, but I don't understand your point as it
relates to what I was saying. At Microsoft, there's a dedicated team (handful
of people) who manage the SPF record and there's a change review process, and
expertise moves out of the team gradually. Still, there are people that are
assigned to it. In addition, Hotmail.com fits into the 10 DNS lookup limit as
required by the RFC.
My point was that Hotmail can inventory what all of its IPs are, and updates
its DNS records manually. But plenty of others don't know what their IPs are;
furthermore, Office 365 does email hosting for small, medium, and large
businesses. The part that doesn't scale is the following:
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.
-- Terry
-----Original Message-----
From: dmarc [mailto:[email protected]] On Behalf Of Hector Santos
Sent: Tuesday, April 14, 2015 2:48 PM
To: [email protected]
Subject: Re: [dmarc-ietf] Publishing and Registration Concerns
On 4/14/2015 3:03 PM, Terry Zink wrote:
Hi, Doug,
TPA-Label operates within its own sub-domain. This
sub-domain can be delegated or use DNAME.
How is the scaling issue really worse than the changes
currently required for SPF? In fact, SPF often entails more
DNS transactions per use
When I talk about scale [1], it's not just a matter of doing DNS lookups. That's important, but
it's not what I worry about because we can solve it by adding more hardware [2]. Instead, by
"scale" I mean "management", that is, having humans manage the process, or
needing humans to do something.
But thats the same problem for everything. How will MS work it out
for your hotmail.com SPF operations? For SPF, hotmail.com has a
relaxed SPF policy with a long list of DNS lookups. Lots of
processing waste here. For DMARC, thousands, perhaps millions, high
volume of mail are getting NXDOMAIN on the expectation there is a
DMARC record.
Are we at a point where all DNS TXT-based solutions will need to be
converted to in-band mail only solutions and we eliminate DNS from the
picture?
if ADID == SDID
DO DNS_DMARC
else
DNS PROBLEM TOO HARD.
Is that what we going to tell the DNS folks on last call? The better
solution was punted because interfacing with DNS people is a tough
problem.
That is what is astonishing me the most here. Billion dollar
corporations saying this problem is too hard for them to address.
Wow. I'm sorry, but it seems odd that we were going for a far more
complex workaround that has security holes just because the we can't
get the DNS folks involved as part of the solution package when DNS is
required in the first place. This all seems very strange to me to
read this.
I don't mind an In-band solution as an OPTIONAL alternative to the
more optimized, more secured, more technically feasible, time tested
simple DNS lookup solution. The IETF, this WG, the chairs owes it to
the interested industry participants to offer and provide a solid
solution, even if it involves getting DNS administration involved.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
