John Levine wrote: > 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.)
This is literally true, but only a concern for fairly naive uses of ARC. > That means that it only makes sense to evaluate ARC headers on mail > from hosts that you believe are generally trustworthy. Large mail Yes, just as for DKIM signatures, SPF records, ... > systems have enough mail flow that they usually already have a pretty > good idea who's trustworthy, small mail systems don't. For very small systems (my personal mail server), sure. For mid-sized systems (receivers with tens of thousands of mailboxes) this may well be true, but stems from not having had reason to perform the analysis rather than from not having access to enough data to do so. I did some work on this a few years ago on a receiver at this size and was able to make useful inferences about forwarder behaviour, but had to assume that most Received: headers weren't forged which, clearly, was not an approach worth publishing because as soon as it became popular it would present another vector for criminals. Signed Received: headers (essentially what ARC is) would have solved that problem. I infer that the big guys have noticed the same things but - concerned about creating an incentive for criminals to forge Received: headers - could not proceed without signed Received: headers; thus ARC. > 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. How many mailboxes do you host? If it's just you (and perhaps a few others) then, sure. If you're talking about posts to mailing lists then, likewise, this is not likely to be the right data (there being far less upstream forwarding on the way into mailing lists than there is on the way into mailboxes generally). - Roland _______________________________________________ dmarc-discuss mailing list [email protected] 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)
