On 28/05/18 19:26, Alessandro Vesely via dmarc-discuss wrote:
Your points define ARC's scope very well. But what's big guys' role?
Let me call /semantic mailbox providers/ those company or personal mail sites
whose users have some kind of trust relationship with, e.g. because they work
for the company, are postmaster's friends, or whatever. These providers can
afford to let their users transparently perceive forwarders' filtering ability,
be it naive SA deployment or sophisticated AI categorization. They may
consider that users subscribing to mailing lists know what they do and let them
enjoy or suffer its output as-is. "I trust these guys not to lie in From:
rewriting" could be enough for them to whitelist DMARC breakage while keeping
its anti-phishing feature, and dnswl.org would probably suffice to implement
that, if agreeing on any single public whitelist were an acceptable means to
make a protocol work.
By contrast, big guys have so many users because they offer astounding
functionalities, among which filtering is one of the most relevant. They need
to filter forwarded messages in a manner 100% consistent with messages coming
in directly. As you say, ARC will permit that by removing dependencies upon
upstream filtering. I doubt anybody but big guys really needs that, but will
be glad to be confuted.
Your question was "what's big guys' role", but your argument appears to
be the reverse:
* That small guys can function without ARC on a hand-to-hand fighting
basis, perhaps with the aid of third-party reputation data.
* That big guys have a clear interest in ARC so they can project their
filtering expertise upstream.
I'd suggest that you've therefore answered your stated question in your
second paragraph.
For the implied question ("Why would small guys be interested?"):
* ARC headers simply provide a view as to what happened upstream.
Whatever effort you're willing to invest in hand-to-hand fighting is
amplified (greater efficiency and/or effectiveness) simply by making
use of that visibility.
* A single public whitelist is not necessary for ARC to work, multiple
lists are certainly possible, but the mapping of well-behaved
whitelist operators is:
o much easier than mapping abusers, as the latter are seeking to
_*evade*_ detection;
o much slower moving (new small list operators appear at a rate of
perhaps one per week; abusers gain control of IP addresses at a
rate of many per second); and
o more resilient in that possession of the abuse data by abusers
doesn't provide a means to optimise abuse by focusing on IP
addresses and identifiers that haven't yet been identified[1],
meaning that a slow-moving list can be included in email
security software, as with the current rule set for something like
SpamAssassin.
- Roland
1: Granted, the list becomes a priority list for compromise attempts,
much as happened with ESPs several years ago, but sudden spikes in
volume can be treated as suspicious anyway, so the benefit in
compromising a small forwarder is limited.
_______________________________________________
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)
