Dear Terry, Since DMARC assertions cause compliance issues for third-party domains, and since some think customers would be unable to manage a third-party exception list needed for draft-otis-tpa-label, draft-levine-dkim-conditional, draft-kucherawy-dkim-delegate, and rfc6541, one solution would use DMARC assertions to delegate the heavy lifting to a separate organization specializing at handling third-party conflicts. That would allow all of their customers to expend little effort in their system configuration such as _dmarc TXT "v=DMARC1; p=quarantine; tpa=third-party-authority.com;
This way, the most that administrator would concern themselves with is dealing with is simple TXT records from their perspective. Perhaps hotmail might even offer their zone on a fee basis. It also seems like an ideal way to ensure your customers are likely to remain happy and not leave. I would be happy to make tpa-label look more like atps, but I don't think the reasons for the additional terms were clearly understood. These terms ensure third-party messages could be differentiated from direct mailing using simple sort criteria. It would be equally wrong to suggest anything included in the dkim-conditional header would be indicating exactly what a malefactor needs to add to their message for acceptance. More on that later. Regards, Douglas Otis On 4/15/15 5:55 PM, Terry Zink wrote: > Hi, Hector, > >> For the umpteenth time, not everyone need 4000 domains. Most of the >> domains that will or may utilize it, simply don't need this scale. > I'm not sure you get the point that the others are trying to make. While this > *may* scale for small domains (a big maybe), it won't scale for large domains > like Hotmail, Yahoo, Google, AOL, and a lot of other large providers who are > unlikely to implement it. They make up a small number of implementers but a > massive number of users. If it won't work for this massive user base, then > it's not worth implementing even on a small scale because for the average > user (of which there are millions), the people they try to send to (Hotmail, > Google, Yahoo) aren't supporting this. > > -- Terry > > -----Original Message----- > From: dmarc [mailto:[email protected]] On Behalf Of Hector Santos > Sent: Wednesday, April 15, 2015 5:48 PM > To: [email protected] > Subject: Re: [dmarc-ietf] Publishing and Registration Concerns > > On 4/15/2015 4:39 PM, Scott Kitterman wrote: >> For the umpteenth time, the issue isn't managing a DNS zone. That's the easy >> part. The hard part is knowing what to put in it. > Right. I never said it was hard problem. This didn't stop the large > domain with SPF in adding INCLUDE and still have an unknown result. > >> Many companies, not even >> the really big ones, have thousands of domains. > and millions more does not. > >> Go publish SPF, DKIM key, and DMARC records for 4,000 domains and then tell >> me >> it's all easy to then figure out what the right list of authorized forwarders >> should be for each one. > For the umpteenth time, not everyone need 4000 domains. Most of the > domains that will or may utilize it, simply don't need this scale. > >> P.S. I'm done on the topic of is keeping a list of forwarders a useful >> solution for the group to work on. No matter how you wrap it up, it's not. > So move on, scott. > _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
