On Tue, May 29, 2018 at 8:10 AM Alessandro Vesely via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:
> On Tue 29/May/2018 01:27:33 +0200 Roland Turner via dmarc-discuss wrote:
> > On 28/05/18 19:26, Alessandro Vesely via dmarc-discuss wrote:
> >
> > 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.
>
> You seem to imply that only mailing list activity needs to deploy ARC.
>
> I know ARC proponents don't want author's domains to sign ARC-0, but never
> understood why. Anyway, ordinary forwarders will need to ARC sign
> forwarded
> messages too, which includes pretty much all mail sites. The latter is
> *not* a
> slow-moving data set. It grows steadily.
>
No, ordinary forwarders which break DKIM need to ARC sign. If you're just
an ordinary forwarder, why break DKIM?
As for ARC-0, there's no need for the actual From domain to sign as ARC,
that's what DKIM/SPF are for. If you're talking about
a third party author, that's a very different trust statement.
Ie, for regular ARC forwarding, the trust is that they implement ARC
correctly and are not faking the ARC results.
For ARC-0, the trust is that the "author" domain has permission to send on
behalf of another domain. What that permission
looks like can vary greatly, from say the simplest level of "email address
confirmation" to some level of live user query.
Ie, the simple confirmation won't typically do a good job of preventing an
ex-employee who already registered with a third party service from sending
mail as that service, unless you required every sent message to first have
a confirmation via email to the sender. Is that really a useful level of
service to justify ARC-0?
I'm sure there are vendors who would benefit from that, typically those
sending larger volumes of messages for users from domains that don't
support that, ie your small business using an @gmail.com address and using
say Constant Contact. But is Gmail really going to trust a third party to
send mail on it's behalf (pretty sure the answer would be no).
Another use case would be "having my hosted domains set up SPF/DKIM is too
hard, I'll just sign for them". I can see some utility in that, but it has
the same "how do I know that?" Ie, we probably have some documentation on
how we manage domain ownership for GSuite domains and enforce that
ownership, and even if we do an excellent job with that, there's almost
certainly some grace period involved in verification failures, during which
the ex-domain owner would still be able to send mail as the domain. We've
even debating doing something like that for Gmail to Gmail mail when we had
some big issues with a prominent DNS provider having outages. I still have
a hard time believing the rest of the world wants to just say "trust
anything Gmail sends as authed".
Really, the solution for ARC-0 is probably MSA with OAUTHBEARER, which
allows for an individual to auth a specific sender for their own address,
and enforces all of the regular controls for the account, and allows the
individual to list and manage those auths. It won't help the cases where
they want to use their address for higher volume, though.
Brandon
_______________________________________________
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)
