On May 12, 2014, at 1:38 PM, S Moonesamy <[email protected]> wrote:
> Hi Doug, > At 12:16 12-05-2014, Douglas Otis wrote: >> be compromised. A better approach would not use DMARC, but would federate >> third-party services they can see their customers employ. The federation of >> email, much like that of XMPP, would be an effective means to exclude bad >> actors without breaking mailing-list and other third-party email services. >> As it is now, it seems Yahoo only protects their own > > Is federation effective in excluding bad stuff? Bad stuff also occurs in > closed systems (see > https://support.twitter.com/groups/56-policies-violations/topics/238-report-a-violation/articles/64986-reporting-spam-on-twitter > ). XMPP has been mentioned previously. There wasn't any information > provided to assess whether it does exclude bad stuff. Dear SM, 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. 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. Yahoo likely considered DMARC the closest approximation of server federation that could be enabled. After all, there are no other email policy layers reliably acted upon. What is missing is a minor amount of feedback needed to communicate what the Author-Domain knows to be legitimate sources. Doing so should represent a negligible amount of effort. 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. :^). Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
