> 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
This is something we've done many times, except that rather than creating an
ATPS record, we just add the 3rd party's IPs to a subdomain's SPF record (e.g.,
email.microsoft.com or e-mail.microsoft.com) and set up DKIM keys for it, and
then tell the 3rd party to send email that way. The example you have is not
aligned because I haven't done every domain within Microsoft, but if I ever get
to this one, that's how I'll do it.
> and manage it of course.
And herein lies the trouble. "Manage it of course" is more than a simple line
of text. If I want to add a 3rd party to Microsoft's zone:
1. I need get sign off from necessary parties
2. I create a DNS change request
3. It goes through a review process
4. I have to review the zone updates since I created the tickets
5. They usually ask me to validate it manually when the Ops team does the
change.
None of this process is automated, and that's intentional. Instead, we make
deliberate changes to the Microsoft zone so we know what's going in.
By contrast, the ATPS for 3rd parties - mailing lists - is not something we
would automate. I know of a few mail servers that other employees use that
relays email as @microsoft.com in the From: address that will fail DMARC. But
if we had to add every 3rd party mailing list that employees used, we'd have to
go through this change review process each time. But because employees signing
up for a mailing list is not official company business, we *wouldn't* update
our zone just for that without a good reason.
Similarly, for Hotmail, would we really want to update our zones automatically
for every mailing list a subscriber signs up for? Without any change control?
I'm inclined to say no.
-- Terry
-----Original Message-----
From: Hector Santos [mailto:hsan...@isdg.net]
Sent: Wednesday, April 15, 2015 10:58 AM
To: dmarc@ietf.org; Terry Zink
Subject: Re: [dmarc-ietf] Publishing and Registration Concerns
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:dmarc-boun...@ietf.org] On Behalf Of Hector Santos
> Sent: Tuesday, April 14, 2015 2:48 PM
> To: dmarc@ietf.org
> 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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
