>ARC purpose is to say when DMARC fail and the email should be rejected that >it is ok to let it through. As such there is no scale problem and anyone >can do it.
ARC provides no protection against replay attacks, in particular, against taking a set of ARC headers from a benign message and sticking them on malware or spam. (This isn't saying it's misdesigned, just that it does what it does.) That means that it only makes sense to evaluate ARC headers on mail from hosts that you believe are generally trustworthy. Large mail systems have enough mail flow that they usually already have a pretty good idea who's trustworthy, small mail systems don't. I have a database that has logged every single connection to my MTA since 2008, and which mail was treated how, but that's still nowhere near enough to provide useful reputation info about sources other than ones that are so so large that I can just whitelist them anyway. Scott and I aren't saying the code's too hard to write, we can code anything we want to. We don't have the data. R's, John _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
