Re: [dmarc-discuss] RUA vs RUF reports
In article you write: >I'm surprised to learn of the low value of failure reports. It's a lawyer thing. Failure reports send copies of your users' mail to total strangers. Maybe those strangers had something to do with that mail, maybe not. You can make various arguments about why even if the strangers didn't have anything to do with the mail they should get to see it anyway, but you know how lawyers are, always telling you to spend $1000 to defend against a $10 risk. 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)
Re: [dmarc-discuss] General DMARC weakness - personal forwarding
In article you write: >No, ordinary forwarders which break DKIM need to ARC sign. If you're just >an ordinary forwarder, why break DKIM? Unfortunately, some people still authenticate with SPF, so an unmodified forward can break DMARC. 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)
Re: [dmarc-discuss] General DMARC weakness - personal forwarding
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)
Re: [dmarc-discuss] RUA vs RUF reports
Thank you all! This has been very insightful. I'm going to turn aggregate reports back on, and maybe build something to process them (really as a programming exercise, I know there are tools and services existing already). I'm surprised to learn of the low value of failure reports. But it's good to learn. For now I'm going to leave them on so I can peek at them for curiosity's sake. Cheers, Al Iverson On Mon, May 28, 2018 at 9:16 AM John Levine wrote: > In article you write: > >This is very helpful, thank you! I guess I assumed the issuance of forensic > >(failure) reports was more common than you indicate; because at my day job > >we get gobs of them for various domains ... > Looking at my last 100 or so failure reports, I see that that more > than half of them are from large Chinese ISPs, mostly for random spam > that faked one of my domains, a few for mailing lists. (Who knew that > there were NANOG subscribers in China?) There's maybe a dozen from > Linkedin, which are a mix of mailing lists and bounces from Office 365 > for a customer who, against my advice, hosts their mail there. > Perhaps someday Microsoft will figure out how to do SPF alignment for > bounces but not today. Other than that it's from a smattering of tiny > systems, almost all mailing list messages. > None of them are anything I can fix here, and I am not inclined to > tell mailing list operators how to run their lists. > I find the aggregate reports occasionally interesting. The volume is > not huge. I have over a dozen active mail domains and the total > number of reports since 2012 is 143,000, which I store in an ordinary > mail folder. I give away a little perl script to which I feed the > report messages so it can put the interesting bits in a mysql database. > R's, > John -- al iverson // wombatmail // miami http://www.aliverson.com http://www.spamresource.com ___ 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)
Re: [dmarc-discuss] General DMARC weakness - personal forwarding
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.
> 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.
Spamtraps will also work well, as usual. However, no spam indicator implies
that the upstream ARC chain is faked. In theory, for example, ARC would allow
me to switch to forward-before-filter (maybe CPU happened to cost me more than
bandwidth, say.) In that case, you would tend to classify me as a spammer and
possibly suspect that my keys were compromised. How to maintain the list
remains unclear.
Best
Ale
--
___
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)
