Dear SM, Thank you for your thoughtful questions. See comments inline:
On May 22, 2014, at 11:19 PM, S Moonesamy <[email protected]> wrote: > Hi Doug, > At 14:32 22-05-2014, Douglas Otis wrote: >> The goal of federated services is to prevent inclusion of unknown servers. >> It does not in itself exclude bad stuff. When bad stuff is noted, >> federation enables blocking future exchanges. Direct tweets are possible, >> although messaging constrained to 140 characters is difficult to take >> seriously since it is nearly impossible to know whether a tweet is being >> auto-generated. Much of it is. The way this would relate to DMARC is in >> the handling of non-aligned messages. When sources are identified, and >> feedback is generated for all known exceptions, it should not be difficult >> to then invert "block" logic into "accept" logic. > > The question I asked was: is federation effective in excluding bad stuff? > The reason I asked that question is to be able to form an opinion about the > idea of an email federation. The above explains that the email federation is > about preventing the inclusion of unknown servers. That does not help me in > forming an opinion about the idea (see the question I asked). I used tweeter > as an example of a closed system. The argument was that bad stuff can happen > in a system in which the owner has full control. I have been asked nearly the same question by others. A section will be added to explain the how and why and its impact on privacy. Senders and receivers desire a scheme that improves protection of the From header field. The business aspects of this became extremely clear to PayPal by effects on their customers then obligated to sift through massive amounts of email abuse. The benefit of timely out-of-band notification instead caused an exodus of customers. To staunch customer loss, direct appeals to major ESPs to reject non-aligned PayPal messages helped, and helped everyone. Unfortunately, direct appeal does not scale. Hence we have a limited stop-gap scheme. As has become extremely clear, although there was early evidence, DMARC did not fully consider important "corner cases". It seemed okay to leave these issues for receivers to sort out. Now AOL and Yahoo! have made it evident receiver cooperation is in jeopardy. If you are like most others, you have had malicious and socially engineered messages from someone you know prompting you to click a link or call a number, etc. Resorting to the only functional policy scheme able to reject messages is understandable, but this came at a dear cost. As John Levine describes, "a death by a thousand cuts". Asserting whether all messages must have From/Source domain alignment is somewhat analogous to the type of federation supporting single-sign-on schemes. A federation has the purpose of protecting identifiers. In other words using laissez faire protocols where the strategy of "block on event" is inverted to become "accept on event". In the case of DMARC + TPA, "accept on event" is derived from DMARC feedback/log review accurately determining which domains require exception. Further review can even characterize how domains authenticate and which header elements confirm or narrow authorization. TPA uses DNS to signal "trust" based on hash labels. DNS is used because it is ubiquitously relied upon by MTAs, offers low latency and low overhead from legitimate domains. DNS is also able to handily support this scheme at massive scales. >> Imagine your domain supporting millions of users had their accounts exposed >> along with their address-books. This can easily get ugly in respect to the >> harm this would allow. > > I read that "information security and customer data protection are of > paramount importance". My interpretation of that is that the importance is > ranked higher than money. My interpretation would be incorrect if my domain > had millions of accounts exposed. Someone might also point me to > http://www.dilbert.com/strips/comic/2014-05-19/ Cute comic. It is not really the information protected by a federation scheme. It is not even the exclusion of bad stuff. It is protection of federated identities by receivers implementing DMARC + TPA. By using this scheme, associated identities can be protected while also avoiding disruption of legitimate messages. Even Eliot Lear's mother becomes safer. (I hope this is the right example as it was discussed many years ago.) >> I supported a system that reported on _all_ identified bad IPv4 addresses. >> To do this, it required careful exclusion of those randomly assigned >> addresses. We would then apply about 15 million updates every 5 minutes for >> the entire IPv4 address space orchestrated by two redundant servers. This >> information then supported several very large ISPs. The larger ISPs wanted >> to do zone transfers, but a DMARC exception rate for an Author Domain will >> be several orders of magnitude lower in scale. I'll admit this was all done >> using C code that avoided SQL or Hadoop. Judy is your friend. :^). > > I'll make this a little complicated for you. Could that system also be used > for IPv6 addresses? Unfortunately, that approach now only works for authenticated domains. :^( Dane anyone? Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
