(merging two sub-threads)
Scott Kitterman wrote:
> Along with the good things you (quite reasonably) describe, there will also be
> an increased tendency towards concentration of power in a few hands.
> Personally, I think that's a bad thing. Your previous message in this thread
> captured my concern very nicely.
I'd suggest that the tendency towards concentration once uncertainty about the
best way to do a thing subsides is perfectly ordinary and not something to be
any more upset about than the tides, even if you were the kind of person who
enjoyed building ornate sandcastles. The important concern would not be
consolidation per se, but consolidation to the point where independent actors
in related spheres lose their independence as a result. I don't believe that
this result has arisen in the case of SMTP reputation data and see no reason to
assume that it will arise with ARC reputation data (indeed, as described below,
I believe it to be less likely in the ARC case).
> Roland Turner wrote:
>
>> I meant to ask earlier: would you level the same criticism at SMTP, given
>> that running a useful mail-receiving-server without a solid DNSBL is now
>> more-or-less infeasible? Does the fact that Spamhaus is already available
>> free of charge to all of the small guys change this analysis?
>
> The fact that there are high quality services available free/reasonable for a
> little guy to pay does alter my perspective. At the time DNSBLs were
> becoming popular/necessary there wasn't the same level of concentration in the
> market and even going back to open relay lists there's ~always been something
> anyone on a modest budget could use.
So, looking forward a couple of steps: when/if ARC proves to be useful (bear in
mind that it's currently untested) it would seem to me to be a near certainty
that the first and probably both of the following will occur:
- open-source MTAs/tools will gain the capability to make sensible use of ARC
in DMARC decision-making, and
- reputation data providers will provide the "batteries" (assuming that there
are important pieces that are too fast moving to be embedded in source code)
just as they already do for DNSBLs.
You've not advanced any argument to suggest that this is not true, yet much of
your concern appears to assume that it's not true. Do you believe that there's
something special about ARC reputation data (mapping the observed behaviour of
a few thousand well-intentioned forwarders who are not trying to hide) that is
somehow more difficult, or less likely to appear than DNSBLs were and are
(mapping the observed behaviour of hundreds of millions of IP addresses in the
control of criminals who are working hard to hide what they're doing)? So far
as I can tell, ARC reputation data will be a far simpler nut to crack than
blocklists ever were, and may even be slow enough moving that it can be
embedded in source code.
Stated another way, you appear to be making an extraordinary claim not merely
in the absence of extraordinary evidence, but in the face of contradictory
evidence.
>> Perhaps the fact that SMTP was developed at a time that abuse was not
>> widespread gives it a free pass on this front? Presumably you don't argue
>> that, *because* we're already in a high-abuse environment we should
>> therefore cease collaboration on any class of solution which happens to
>> require more data than is either: (a) feasible for small guys to process
>> usefully, or
>> (b) available to small guys at all?
>
> SMTP has always been, with a little study, been something any competent admin
> could do. It takes a lot more study and more resources than a decade or two
> ago, but we haven't, in my opinion, crossed a tipping point where that's not
> longer possible. So SMTP gets a pass because it's ~always been accessible (I
> know in the dim reaches of history that wasn't quite always so).
OK, but that wasn't quite the question that I meant to ask. I was getting at
the dependence that we all have upon DNSBL providers. Generating that data is
already out of range for all but about a dozen organisations in the world
(there are multiple publicly-available products, but there's also a lot of
licensing going on behind the scenes). ARC reputation data is likely to be
easier produce (a smaller number of assessed entities, that are slower-moving,
and aren't hiding themselves). How is it OK for SMTP use to be dependent upon
DNSBLs but not for ARC use to be dependent upon reputation data?
If the issue is only that cheap/free ARC reputation data is not yet available -
and noting the likelihood of its being easier to produce - surely this should
currently be viewed as a transition state rather than a serious problem?
> I think solutions feasible for one segment of the market (large, small,
> purple, blue, don't care) are fine to collaborate on as long as people are
> clear it's a partial solution.
The authors (and most implementers) of both DMARC and ARC are. As in other
spheres, public commentary is frequently poorly informed, but this does not
seem like an important problem.
>> 1: I *don't* believe that this would take the form of a whitelist. It's more
>> like the ability to recognise changes in baseline behaviour by forwarders
>> who may or may not be ARC signing. I suspect that John Levine's concerns
>> about whitelists have some strength.
>
> It would as that data is the barrier to entry I'm worried about. I think it's
> actually two lists:
>
> 1. Domains good enough you ought to trust to believe what they say in ARC.
> 2. Domains bad enough you ought to reject their mail if they show up in ARC.
Your response ("as that data is the barrier...") suggests that you were
addressing a different point to the one that I was making (that useful ARC
reputation data won't take the form of a whitelist). I'll desist addressing
this in this already-too-long-thread (the reason for its being a footnote in
the first place), but reiterate my belief that it's not going to be something
quite that simple.
> I do wonder though if I have the data to toss the message why they didn't in
> the first place (and if they didn't why I should trust them).
This is a basic problem with forwarding (and in my opening comments on this
thread about the assumptions that you appear to be making):
- the policies of the forwarder and receiver about dealing with messages that
are neither clearly OK nor bad are likely to be different, and
- the information available to the receiver (particularly end-user spam
complaints) is in important respects better than the information available to
the forwarder.
This is the reason for some large forwarders, providing separate streams for
messages that they're not certain about. That different receivers will want to
make different decisions about messages which from the forwarder's perspective
aren't usefully distinct means that there is no correct decision for the
forwarder to make, better to forward the message and let the receiver decide.
You certainly shouldn't "trust" the forwarder to make the same policy choice
that you would (this is more like "anticipate" than "trust" in the usual
sense), but this is entirely orthogonal to questions about whether you should
trust the forwarder to attach accurate ARC information (again, refer my opening
remarks on this thread about the different kinds of trust that you appear to be
confusing).
- Roland
_______________________________________________
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)
