Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Scott Kitterman via dmarc-discuss 
On Tuesday, February 16, 2016 06:17:27 AM Roland Turner via dmarc-discuss 
wrote:
> Scott Kitterman wrote:
> > To
> > the extent ARC is useful to mitigate the DMARC mailing list issue, it's
> > only useful with additional data inputs that are not public and are not
> > feasible for small providers to generate on their own.
> 
> 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.

> 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).

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.  

> Would the public availability from a trustworthy source of data that makes
> it possible to use ARC to decide when to override DMARC policies[1] change
> your position?
> 
> - Roland
> 
> 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.

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).  So generically, 
yes, but I'm not certain what the characteristics of such a data source would 
be.

Scott K
___
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] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Roland Turner via dmarc-discuss 
Franck Martin wrote:

> As I said earlier spamhaus and surbl has the data. The question is not
> which domains to trust, but which domains not to trust.

They may or may not. (Analysing Received: headers to learn about forwarding 
behaviour is not an obviously important input for those organisations at 
present and, consequently, is something that they're probably not doing much 
of.) I'd suggest that the important question is whether they're likely to be 
willing to publish data to support ARC-enabled DMARC decision-making once (a) 
good ways of doing so are known and (b) fast-moving pieces that are worth 
delivering this way have been identified.

I'd guess "yes", but we're not yet at the point where we know that either of 
those assumptions is true.

- 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)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Scott Kitterman via dmarc-discuss 
On Tuesday, February 16, 2016 06:02:31 AM Roland Turner via dmarc-discuss 
wrote:
> Scott Kitterman wrote:
> >> Roland Turner wrote:
> >> 
> >> This is just a diffusion process, not an exclusion of smaller players.
> >> Indeed, it would almost appear that you'd be happier if the big guys had
> >> excluded smaller players from this initiative...
> > 
> > Until maybe someday the results of the analysis to use ARC are somehow
> > available, they have.
> 
> All diffusion looks like this.
> 
> The "one size fits all" mentality gave us the lost decade. Recognising that
> differently-situated practitioners need different things and developing a
> range of tools/protocols/etc. to suit the range of needs (most of which
> will be not useful for most practitioners) is not merely more effective, it
> currently appears to be the only way forward.
> > The use of an open standard (which I am in favor of and
> > this is good), doesn't materially change that.  If I can write code to
> > implement a standard, but don't have the necessary inputs to use it, it's
> > not particularly of use.
> 
> "not particularly of use to Scott" != "not useful".
> 
> This is of course a different question to the one about whether/how to
> involve yourself, more below.
> > Personally, I try to consider putting my time where either I'll benefit
> 
> Eminently sensible, I do the same.
> 
> > or I think the global Internet will benefit.
> 
> Likewise, and so here's the challenge: the big guys hardening their part of
> the environment against criminals doesn't merely improve life for the big
> guys (e.g. by shifting criminals' focus elsewhere), they are so big that
> they are materially altering the economics in a way that makes crime less
> profitable and therefore less likely than it would otherwise be. This
> directly benefits the global Internet in a way that a
> batteries-included-but-less-impactful approach could not, even assuming
> that such an approach exists (are you aware of one?).
> 
> Do you really mean "or", or do you actually mean "and"? We are talking about
> an initiative that, if successful, will materially benefit the global
> Internet, even though you personally will not be able wield the resulting
> tool for some time, or possibly even ever (unlikely, but possible). Do you
> support it anyway?
> 
> (A less charitable interpretation is that your concern is merely resentment
> or envy of large organisations. Presumably this is not correct.)

No.  Not at all.  I do mean 'or'.  I quite routinely invest time in things to 
make the Internet work better that don't personally benefit me.  Obviously the 
greater the personal and systemic benefit the greater my motivation, but I 
certainly have and do work on things that don't help me in any way 
proportionate to the time I invest in it. 

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.

Thanks,

Scott K
___
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] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Roland Turner via dmarc-discuss 
Scott Kitterman wrote:

> To
> the extent ARC is useful to mitigate the DMARC mailing list issue, it's only
> useful with additional data inputs that are not public and are not feasible
> for small providers to generate on their own.

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?

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?

Would the public availability from a trustworthy source of data that makes it 
possible to use ARC to decide when to override DMARC policies[1] change your 
position?

- Roland

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.
___
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] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Franck Martin via dmarc-discuss 
The problem with the e-mail community, is few people drives all of us
away from mailing lists.

On Mon, Feb 15, 2016 at 3:47 PM, John R Levine  wrote:
>> As I said earlier spamhaus and surbl has the data. The question is not
>> which domains to trust, but which domains not to trust.
>
>
> No, really, they don't.  Take it from someone who actually writes MTA
> software, and probably knows more than most people about what's in the DBL.
>
>
>>> 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.)
>>>
>>> That means that it only makes sense to evaluate ARC headers on mail
>>> from hosts that you believe are generally trustworthy.  Large mail
>>> systems have enough mail flow that they usually already have a pretty
>>> good idea who's trustworthy, small mail systems don't.
>>>
>>> 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.
>>> Scott and I aren't saying the code's too hard to write, we can code
>>> anything we want to.  We don't have the data.
___
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] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Franck Martin via dmarc-discuss 
As I said earlier spamhaus and surbl has the data. The question is not
which domains to trust, but which domains not to trust.

On Mon, Feb 15, 2016 at 3:35 PM, John Levine  wrote:
>>ARC purpose is to say when DMARC fail and the email should be rejected that
>>it is ok to let it through. As such there is no scale problem and anyone
>>can do it.
>
> 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.)
>
> That means that it only makes sense to evaluate ARC headers on mail
> from hosts that you believe are generally trustworthy.  Large mail
> systems have enough mail flow that they usually already have a pretty
> good idea who's trustworthy, small mail systems don't.
>
> 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.
> Scott and I aren't saying the code's too hard to write, we can code
> anything we want to.  We don't have the data.
>
> 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] introduction to the list-virtual server & mailman questions

2016-02-15 Thread John Levine via dmarc-discuss 
>ARC purpose is to say when DMARC fail and the email should be rejected that
>it is ok to let it through. As such there is no scale problem and anyone
>can do it.

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.)

That means that it only makes sense to evaluate ARC headers on mail
from hosts that you believe are generally trustworthy.  Large mail
systems have enough mail flow that they usually already have a pretty
good idea who's trustworthy, small mail systems don't.

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.
Scott and I aren't saying the code's too hard to write, we can code
anything we want to.  We don't have the data.

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] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Franck Martin via dmarc-discuss 
Spamhaus and SURBL both publish a domain blocking list, this is enough to
use to block emails that went through bad domains (as per ARC custody chain)

Of course, this has to be built into the MTA, but it is all opensource, it
is not out of reach, just volunteers and work...

On Mon, Feb 15, 2016 at 3:00 PM, Scott Kitterman via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> The difference in this case is one, maintaining a Wordpress site, requires
> a
> lot of vigilance, but no information/data that's not publicly available.
> To
> the extent ARC is useful to mitigate the DMARC mailing list issue, it's
> only
> useful with additional data inputs that are not public and are not feasible
> for small providers to generate on their own.
>
> It's the difference between can, but often shouldn't and can't.
>
> I'll stop here though, the horse was probably dead a few mails ago.
>
> Scott K
>
> On Monday, February 15, 2016 02:11:57 PM Al Iverson via dmarc-discuss
> wrote:
> > Scott, I don't really see any difference in the class of problem. You
> could
> > choose to outsource email it to Google Apps or Microsoft Office 365 if
> you
> > don't want to figure this stuff out yourself. Many do, from SMB to
> > enterprise level, even though email is core to just about every company's
> > business. For some, that's very much the reason to job it out to a
> company
> > who focuses on email as an area of expertise.
> >
> > On the flip side, I disagree with regard to your take on running a blog.
> > Anybody can do it, but many people outsource that as well. I personally
> > host my blog with a third party service, because self-hosted Wordpress is
> > one of the most hacked into things out there and I want no part of that
> > noise, even though in theory I could handle it. I know I'm not the only
> > one, and just about anything in this paragraph could similarly apply to
> > email.
> >
> > Regards,
> > Al Iverson
> >
> >
> > --
> > Al Iverson - Minneapolis - (312) 275-0130
> > Simple DNS Tools since 2008: xnnd.com
> > www.spamresource.com & aliverson.com
> >
> > On Mon, Feb 15, 2016 at 1:35 PM, Franck Martin via dmarc-discuss <
> >
> > dmarc-discuss@dmarc.org> wrote:
> > > ARC purpose is to say when DMARC fail and the email should be rejected
> > > that it is ok to let it through. As such there is no scale problem and
> > > anyone can do it.
> > >
> > > If email is your core business, then complaining you have to do some
> work,
> > > will not give any sympathy.
> > >
> > > On Mon, Feb 15, 2016 at 11:17 AM, Scott Kitterman via dmarc-discuss <
> > >
> > > dmarc-discuss@dmarc.org> wrote:
> > >> That's a totally different class of problem.  Any competent sysadmin
> with
> > >> some
> > >> time can maintain a CMS based web site (e.g. Wordpress).  The fact
> that
> > >> so
> > >> many are not competently managed is a function of capability and
> > >> willingness
> > >> to do a little work, not a function of inadequate scale.
> > >>
> > >> Also, following that example, I choose to blog on wordpress.com,
> > >> specifically
> > >> so I don't have to worry about such things, but the blog isn't a core
> > >> business
> > >> function, so that's fine.  Email is more important, so I care more how
> > >> and
> > >> where it gets done.
> > >>
> > >> Scott K
> > >>
> > >> On Monday, February 15, 2016 10:56:57 AM Franck Martin via
> dmarc-discuss
> > >>
> > >> wrote:
> > >> > Yes it is a "you have to be this tall to ride with us". For
> instance,
> > >>
> > >> many
> > >>
> > >> > Wordpress sites are on URL blocking lists, because the managers
> cannot
> > >>
> > >> keep
> > >>
> > >> > with basic security updates. So if you want to host a website, you
> have
> > >>
> > >> to
> > >>
> > >> > be that tall to ride with us (or find a hosting company, that will
> give
> > >>
> > >> you
> > >>
> > >> > a child seat)
> > >> >
> > >> > The mail ecosystem is going this way too. The tools are opensource,
> > >> > available to all, but you need to deploy them and maintain them.
> > >> >
> > >> > The spat of serious data breaches because of email, is making all
> of us
> > >> > very nervous that kids can create so much havoc so easily...
> > >> >
> > >> > On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
> > >> >
> > >> > dmarc-discuss@dmarc.org> wrote:
> > >> > > Scott Kitterman wrote:
> > >> > > > It would be nice if we didn't design standards that only worked
> at
> > >> > > > a
> > >> > >
> > >> > > certain
> > >> > >
> > >> > > > scale.  "You must be this tall to ride" worries me.
> > >> > >
> > >> > > There's nothing about ARC that is scale-specific, except for the
> > >>
> > >> obvious
> > >>
> > >> > > observation that there's a batteries-not-included problem, so the
> > >>
> > >> analysis
> > >>
> > >> > > work required to make good use of it as a receiver is likely to be
> > >> > > infeasible for smaller receivers meaning that:
> > >> > >
> > >> > > - initially only larger receivers will do it, and
> > >> > > - if it

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Scott Kitterman via dmarc-discuss 
The difference in this case is one, maintaining a Wordpress site, requires a 
lot of vigilance, but no information/data that's not publicly available.  To 
the extent ARC is useful to mitigate the DMARC mailing list issue, it's only 
useful with additional data inputs that are not public and are not feasible 
for small providers to generate on their own.

It's the difference between can, but often shouldn't and can't.

I'll stop here though, the horse was probably dead a few mails ago.

Scott K

On Monday, February 15, 2016 02:11:57 PM Al Iverson via dmarc-discuss wrote:
> Scott, I don't really see any difference in the class of problem. You could
> choose to outsource email it to Google Apps or Microsoft Office 365 if you
> don't want to figure this stuff out yourself. Many do, from SMB to
> enterprise level, even though email is core to just about every company's
> business. For some, that's very much the reason to job it out to a company
> who focuses on email as an area of expertise.
> 
> On the flip side, I disagree with regard to your take on running a blog.
> Anybody can do it, but many people outsource that as well. I personally
> host my blog with a third party service, because self-hosted Wordpress is
> one of the most hacked into things out there and I want no part of that
> noise, even though in theory I could handle it. I know I'm not the only
> one, and just about anything in this paragraph could similarly apply to
> email.
> 
> Regards,
> Al Iverson
> 
> 
> --
> Al Iverson - Minneapolis - (312) 275-0130
> Simple DNS Tools since 2008: xnnd.com
> www.spamresource.com & aliverson.com
> 
> On Mon, Feb 15, 2016 at 1:35 PM, Franck Martin via dmarc-discuss <
> 
> dmarc-discuss@dmarc.org> wrote:
> > ARC purpose is to say when DMARC fail and the email should be rejected
> > that it is ok to let it through. As such there is no scale problem and
> > anyone can do it.
> > 
> > If email is your core business, then complaining you have to do some work,
> > will not give any sympathy.
> > 
> > On Mon, Feb 15, 2016 at 11:17 AM, Scott Kitterman via dmarc-discuss <
> > 
> > dmarc-discuss@dmarc.org> wrote:
> >> That's a totally different class of problem.  Any competent sysadmin with
> >> some
> >> time can maintain a CMS based web site (e.g. Wordpress).  The fact that
> >> so
> >> many are not competently managed is a function of capability and
> >> willingness
> >> to do a little work, not a function of inadequate scale.
> >> 
> >> Also, following that example, I choose to blog on wordpress.com,
> >> specifically
> >> so I don't have to worry about such things, but the blog isn't a core
> >> business
> >> function, so that's fine.  Email is more important, so I care more how
> >> and
> >> where it gets done.
> >> 
> >> Scott K
> >> 
> >> On Monday, February 15, 2016 10:56:57 AM Franck Martin via dmarc-discuss
> >> 
> >> wrote:
> >> > Yes it is a "you have to be this tall to ride with us". For instance,
> >> 
> >> many
> >> 
> >> > Wordpress sites are on URL blocking lists, because the managers cannot
> >> 
> >> keep
> >> 
> >> > with basic security updates. So if you want to host a website, you have
> >> 
> >> to
> >> 
> >> > be that tall to ride with us (or find a hosting company, that will give
> >> 
> >> you
> >> 
> >> > a child seat)
> >> > 
> >> > The mail ecosystem is going this way too. The tools are opensource,
> >> > available to all, but you need to deploy them and maintain them.
> >> > 
> >> > The spat of serious data breaches because of email, is making all of us
> >> > very nervous that kids can create so much havoc so easily...
> >> > 
> >> > On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
> >> > 
> >> > dmarc-discuss@dmarc.org> wrote:
> >> > > Scott Kitterman wrote:
> >> > > > It would be nice if we didn't design standards that only worked at
> >> > > > a
> >> > > 
> >> > > certain
> >> > > 
> >> > > > scale.  "You must be this tall to ride" worries me.
> >> > > 
> >> > > There's nothing about ARC that is scale-specific, except for the
> >> 
> >> obvious
> >> 
> >> > > observation that there's a batteries-not-included problem, so the
> >> 
> >> analysis
> >> 
> >> > > work required to make good use of it as a receiver is likely to be
> >> > > infeasible for smaller receivers meaning that:
> >> > > 
> >> > > - initially only larger receivers will do it, and
> >> > > - if it works then, over time, vendors/developers will embed
> >> 
> >> slow-moving
> >> 
> >> > > pieces in products and/or reputation data providers will add faster
> >> 
> >> moving
> >> 
> >> > > pieces to their services.
> >> > > 
> >> > > This is just a diffusion process, not an exclusion of smaller
> >> > > players.
> >> > > Indeed, it would almost appear that you'd be happier if the big guys
> >> 
> >> had
> >> 
> >> > > excluded smaller players from this initiative...
> >> > > 
> >> > > I'd also point out that we spent most of a decade (2003 - 2011)
> >> 
> >> wandering
> >> 
> >> > > in a

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Al Iverson via dmarc-discuss 
Scott, I don't really see any difference in the class of problem. You could
choose to outsource email it to Google Apps or Microsoft Office 365 if you
don't want to figure this stuff out yourself. Many do, from SMB to
enterprise level, even though email is core to just about every company's
business. For some, that's very much the reason to job it out to a company
who focuses on email as an area of expertise.

On the flip side, I disagree with regard to your take on running a blog.
Anybody can do it, but many people outsource that as well. I personally
host my blog with a third party service, because self-hosted Wordpress is
one of the most hacked into things out there and I want no part of that
noise, even though in theory I could handle it. I know I'm not the only
one, and just about anything in this paragraph could similarly apply to
email.

Regards,
Al Iverson


--
Al Iverson - Minneapolis - (312) 275-0130
Simple DNS Tools since 2008: xnnd.com
www.spamresource.com & aliverson.com

On Mon, Feb 15, 2016 at 1:35 PM, Franck Martin via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> ARC purpose is to say when DMARC fail and the email should be rejected
> that it is ok to let it through. As such there is no scale problem and
> anyone can do it.
>
> If email is your core business, then complaining you have to do some work,
> will not give any sympathy.
>
> On Mon, Feb 15, 2016 at 11:17 AM, Scott Kitterman via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
>> That's a totally different class of problem.  Any competent sysadmin with
>> some
>> time can maintain a CMS based web site (e.g. Wordpress).  The fact that so
>> many are not competently managed is a function of capability and
>> willingness
>> to do a little work, not a function of inadequate scale.
>>
>> Also, following that example, I choose to blog on wordpress.com,
>> specifically
>> so I don't have to worry about such things, but the blog isn't a core
>> business
>> function, so that's fine.  Email is more important, so I care more how and
>> where it gets done.
>>
>> Scott K
>>
>> On Monday, February 15, 2016 10:56:57 AM Franck Martin via dmarc-discuss
>> wrote:
>> > Yes it is a "you have to be this tall to ride with us". For instance,
>> many
>> > Wordpress sites are on URL blocking lists, because the managers cannot
>> keep
>> > with basic security updates. So if you want to host a website, you have
>> to
>> > be that tall to ride with us (or find a hosting company, that will give
>> you
>> > a child seat)
>> >
>> > The mail ecosystem is going this way too. The tools are opensource,
>> > available to all, but you need to deploy them and maintain them.
>> >
>> > The spat of serious data breaches because of email, is making all of us
>> > very nervous that kids can create so much havoc so easily...
>> >
>> > On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
>> >
>> > dmarc-discuss@dmarc.org> wrote:
>> > > Scott Kitterman wrote:
>> > > > It would be nice if we didn't design standards that only worked at a
>> > >
>> > > certain
>> > >
>> > > > scale.  "You must be this tall to ride" worries me.
>> > >
>> > > There's nothing about ARC that is scale-specific, except for the
>> obvious
>> > > observation that there's a batteries-not-included problem, so the
>> analysis
>> > > work required to make good use of it as a receiver is likely to be
>> > > infeasible for smaller receivers meaning that:
>> > >
>> > > - initially only larger receivers will do it, and
>> > > - if it works then, over time, vendors/developers will embed
>> slow-moving
>> > > pieces in products and/or reputation data providers will add faster
>> moving
>> > > pieces to their services.
>> > >
>> > > This is just a diffusion process, not an exclusion of smaller players.
>> > > Indeed, it would almost appear that you'd be happier if the big guys
>> had
>> > > excluded smaller players from this initiative...
>> > >
>> > > I'd also point out that we spent most of a decade (2003 - 2011)
>> wandering
>> > > in a highly-inclusive -all/o=-/discardable wilderness. It took the
>> world's
>> > > most-heavily-phished organisation working directly with one of the big
>> > > guys
>> > > in private to get any purchase on the problem, and their subsequent
>> > > sharing
>> > > of it (DMARC) to bring about progress more broadly. It would appear
>> that
>> > > ARC is on a similar path to improving the situation for largest
>> unresolved
>> > > piece of the problem (supporting forwarding). This does suggest a
>> general
>> > > difficulty in using a consensus-driven process to devise solutions,
>> rather
>> > > than merely refine/standardise/evolve them, however this does not seem
>> > > like
>> > > a reason for concern, it may simply indicate that we've gotten as far
>> as
>> > > we
>> > > can get at present with such processes. The important test when
>> deciding
>> > > whether to cooperate would appear to be whether the particular
>> solution
>> > > unduly benefits the big

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Franck Martin via dmarc-discuss 
ARC purpose is to say when DMARC fail and the email should be rejected that
it is ok to let it through. As such there is no scale problem and anyone
can do it.

If email is your core business, then complaining you have to do some work,
will not give any sympathy.

On Mon, Feb 15, 2016 at 11:17 AM, Scott Kitterman via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> That's a totally different class of problem.  Any competent sysadmin with
> some
> time can maintain a CMS based web site (e.g. Wordpress).  The fact that so
> many are not competently managed is a function of capability and
> willingness
> to do a little work, not a function of inadequate scale.
>
> Also, following that example, I choose to blog on wordpress.com,
> specifically
> so I don't have to worry about such things, but the blog isn't a core
> business
> function, so that's fine.  Email is more important, so I care more how and
> where it gets done.
>
> Scott K
>
> On Monday, February 15, 2016 10:56:57 AM Franck Martin via dmarc-discuss
> wrote:
> > Yes it is a "you have to be this tall to ride with us". For instance,
> many
> > Wordpress sites are on URL blocking lists, because the managers cannot
> keep
> > with basic security updates. So if you want to host a website, you have
> to
> > be that tall to ride with us (or find a hosting company, that will give
> you
> > a child seat)
> >
> > The mail ecosystem is going this way too. The tools are opensource,
> > available to all, but you need to deploy them and maintain them.
> >
> > The spat of serious data breaches because of email, is making all of us
> > very nervous that kids can create so much havoc so easily...
> >
> > On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
> >
> > dmarc-discuss@dmarc.org> wrote:
> > > Scott Kitterman wrote:
> > > > It would be nice if we didn't design standards that only worked at a
> > >
> > > certain
> > >
> > > > scale.  "You must be this tall to ride" worries me.
> > >
> > > There's nothing about ARC that is scale-specific, except for the
> obvious
> > > observation that there's a batteries-not-included problem, so the
> analysis
> > > work required to make good use of it as a receiver is likely to be
> > > infeasible for smaller receivers meaning that:
> > >
> > > - initially only larger receivers will do it, and
> > > - if it works then, over time, vendors/developers will embed
> slow-moving
> > > pieces in products and/or reputation data providers will add faster
> moving
> > > pieces to their services.
> > >
> > > This is just a diffusion process, not an exclusion of smaller players.
> > > Indeed, it would almost appear that you'd be happier if the big guys
> had
> > > excluded smaller players from this initiative...
> > >
> > > I'd also point out that we spent most of a decade (2003 - 2011)
> wandering
> > > in a highly-inclusive -all/o=-/discardable wilderness. It took the
> world's
> > > most-heavily-phished organisation working directly with one of the big
> > > guys
> > > in private to get any purchase on the problem, and their subsequent
> > > sharing
> > > of it (DMARC) to bring about progress more broadly. It would appear
> that
> > > ARC is on a similar path to improving the situation for largest
> unresolved
> > > piece of the problem (supporting forwarding). This does suggest a
> general
> > > difficulty in using a consensus-driven process to devise solutions,
> rather
> > > than merely refine/standardise/evolve them, however this does not seem
> > > like
> > > a reason for concern, it may simply indicate that we've gotten as far
> as
> > > we
> > > can get at present with such processes. The important test when
> deciding
> > > whether to cooperate would appear to be whether the particular solution
> > > unduly benefits the big guys compared to other viable solutions that
> are
> > > already known about. !
> > >
> > >  If there are none, then cooperating on ARC would appear to be a
> > >
> > > no-brainer.
> > >
> > > > Solving the mailing list 'problem' in a way that requires me to
> switch
> > > > to
> > > > gmail (or some other large scale provider) to get my list mail
> delivered
> > >
> > > is
> > >
> > > > worse than no solution at all for me.
> > >
> > > Obviously. This is not being proposed, see the comments about about
> > > vendors/developers and reputation data providers.
> > >
> > > - 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)
>
> ___
> 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] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Scott Kitterman via dmarc-discuss 
That's a totally different class of problem.  Any competent sysadmin with some 
time can maintain a CMS based web site (e.g. Wordpress).  The fact that so 
many are not competently managed is a function of capability and willingness 
to do a little work, not a function of inadequate scale.

Also, following that example, I choose to blog on wordpress.com, specifically 
so I don't have to worry about such things, but the blog isn't a core business 
function, so that's fine.  Email is more important, so I care more how and 
where it gets done.

Scott K

On Monday, February 15, 2016 10:56:57 AM Franck Martin via dmarc-discuss 
wrote:
> Yes it is a "you have to be this tall to ride with us". For instance, many
> Wordpress sites are on URL blocking lists, because the managers cannot keep
> with basic security updates. So if you want to host a website, you have to
> be that tall to ride with us (or find a hosting company, that will give you
> a child seat)
> 
> The mail ecosystem is going this way too. The tools are opensource,
> available to all, but you need to deploy them and maintain them.
> 
> The spat of serious data breaches because of email, is making all of us
> very nervous that kids can create so much havoc so easily...
> 
> On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
> 
> dmarc-discuss@dmarc.org> wrote:
> > Scott Kitterman wrote:
> > > It would be nice if we didn't design standards that only worked at a
> > 
> > certain
> > 
> > > scale.  "You must be this tall to ride" worries me.
> > 
> > There's nothing about ARC that is scale-specific, except for the obvious
> > observation that there's a batteries-not-included problem, so the analysis
> > work required to make good use of it as a receiver is likely to be
> > infeasible for smaller receivers meaning that:
> > 
> > - initially only larger receivers will do it, and
> > - if it works then, over time, vendors/developers will embed slow-moving
> > pieces in products and/or reputation data providers will add faster moving
> > pieces to their services.
> > 
> > This is just a diffusion process, not an exclusion of smaller players.
> > Indeed, it would almost appear that you'd be happier if the big guys had
> > excluded smaller players from this initiative...
> > 
> > I'd also point out that we spent most of a decade (2003 - 2011) wandering
> > in a highly-inclusive -all/o=-/discardable wilderness. It took the world's
> > most-heavily-phished organisation working directly with one of the big
> > guys
> > in private to get any purchase on the problem, and their subsequent
> > sharing
> > of it (DMARC) to bring about progress more broadly. It would appear that
> > ARC is on a similar path to improving the situation for largest unresolved
> > piece of the problem (supporting forwarding). This does suggest a general
> > difficulty in using a consensus-driven process to devise solutions, rather
> > than merely refine/standardise/evolve them, however this does not seem
> > like
> > a reason for concern, it may simply indicate that we've gotten as far as
> > we
> > can get at present with such processes. The important test when deciding
> > whether to cooperate would appear to be whether the particular solution
> > unduly benefits the big guys compared to other viable solutions that are
> > already known about. !
> > 
> >  If there are none, then cooperating on ARC would appear to be a
> > 
> > no-brainer.
> > 
> > > Solving the mailing list 'problem' in a way that requires me to switch
> > > to
> > > gmail (or some other large scale provider) to get my list mail delivered
> > 
> > is
> > 
> > > worse than no solution at all for me.
> > 
> > Obviously. This is not being proposed, see the comments about about
> > vendors/developers and reputation data providers.
> > 
> > - 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)

___
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] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Franck Martin via dmarc-discuss 
Yes it is a "you have to be this tall to ride with us". For instance, many
Wordpress sites are on URL blocking lists, because the managers cannot keep
with basic security updates. So if you want to host a website, you have to
be that tall to ride with us (or find a hosting company, that will give you
a child seat)

The mail ecosystem is going this way too. The tools are opensource,
available to all, but you need to deploy them and maintain them.

The spat of serious data breaches because of email, is making all of us
very nervous that kids can create so much havoc so easily...

On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Scott Kitterman wrote:
>
> > It would be nice if we didn't design standards that only worked at a
> certain
> > scale.  "You must be this tall to ride" worries me.
>
> There's nothing about ARC that is scale-specific, except for the obvious
> observation that there's a batteries-not-included problem, so the analysis
> work required to make good use of it as a receiver is likely to be
> infeasible for smaller receivers meaning that:
>
> - initially only larger receivers will do it, and
> - if it works then, over time, vendors/developers will embed slow-moving
> pieces in products and/or reputation data providers will add faster moving
> pieces to their services.
>
> This is just a diffusion process, not an exclusion of smaller players.
> Indeed, it would almost appear that you'd be happier if the big guys had
> excluded smaller players from this initiative...
>
> I'd also point out that we spent most of a decade (2003 - 2011) wandering
> in a highly-inclusive -all/o=-/discardable wilderness. It took the world's
> most-heavily-phished organisation working directly with one of the big guys
> in private to get any purchase on the problem, and their subsequent sharing
> of it (DMARC) to bring about progress more broadly. It would appear that
> ARC is on a similar path to improving the situation for largest unresolved
> piece of the problem (supporting forwarding). This does suggest a general
> difficulty in using a consensus-driven process to devise solutions, rather
> than merely refine/standardise/evolve them, however this does not seem like
> a reason for concern, it may simply indicate that we've gotten as far as we
> can get at present with such processes. The important test when deciding
> whether to cooperate would appear to be whether the particular solution
> unduly benefits the big guys compared to other viable solutions that are
> already known about. !
>  If there are none, then cooperating on ARC would appear to be a
> no-brainer.
>
> > Solving the mailing list 'problem' in a way that requires me to switch to
> > gmail (or some other large scale provider) to get my list mail delivered
> is
> > worse than no solution at all for me.
>
> Obviously. This is not being proposed, see the comments about about
> vendors/developers and reputation data providers.
>
> - 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)
>
___
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] introduction to the list-virtual server & mailman questions

2016-02-15 Thread Scott Kitterman via dmarc-discuss 
On Monday, February 15, 2016 07:27:21 AM Roland Turner via dmarc-discuss 
wrote:
> Scott Kitterman wrote:
> > It would be nice if we didn't design standards that only worked at a
> > certain scale.  "You must be this tall to ride" worries me.
> 
> There's nothing about ARC that is scale-specific, except for the obvious
> observation that there's a batteries-not-included problem, so the analysis
> work required to make good use of it as a receiver is likely to be
> infeasible for smaller receivers meaning that:

Yes.  Exactly it.

> - initially only larger receivers will do it, and
> - if it works then, over time, vendors/developers will embed slow-moving
> pieces in products and/or reputation data providers will add faster moving
> pieces to their services.
> 
> This is just a diffusion process, not an exclusion of smaller players.
> Indeed, it would almost appear that you'd be happier if the big guys had
> excluded smaller players from this initiative...

Until maybe someday the results of the analysis to use ARC are somehow 
available, they have.  The use of an open standard (which I am in favor of and 
this is good), doesn't materially change that.  If I can write code to 
implement a standard, but don't have the necessary inputs to use it, it's not 
particularly of use.

> I'd also point out that we spent most of a decade (2003 - 2011) wandering in
> a highly-inclusive -all/o=-/discardable wilderness. It took the world's
> most-heavily-phished organisation working directly with one of the big guys
> in private to get any purchase on the problem, and their subsequent sharing
> of it (DMARC) to bring about progress more broadly. It would appear that
> ARC is on a similar path to improving the situation for largest unresolved
> piece of the problem (supporting forwarding). This does suggest a general
> difficulty in using a consensus-driven process to devise solutions, rather
> than merely refine/standardise/evolve them, however this does not seem like
> a reason for concern, it may simply indicate that we've gotten as far as we
> can get at present with such processes. The important test when deciding
> whether to cooperate would appear to be whether the particular solution
> unduly benefits the big guys compared to other viable solutions that are
> already known about. ! If there are none, then cooperating on ARC would
> appear to be a no-brainer.

Personally, I try to consider putting my time where either I'll benefit or I 
think the global Internet will benefit.  

> > Solving the mailing list 'problem' in a way that requires me to switch to
> > gmail (or some other large scale provider) to get my list mail delivered
> > is worse than no solution at all for me.
> 
> Obviously. This is not being proposed, see the comments about about
> vendors/developers and reputation data providers.

It's not being proposed, but I expect it'll be the effect.  

Scott K
___
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)

[dmarc-discuss] reject DMARC policy for my.com domain starting March, 1 2016

2016-02-15 Thread Vladimir Dubrovin via dmarc-discuss 

Hello, list.

Starting March, 1 2016 Mail.Ru begins to implement restrictive DMARC
policy for public mailbox domains with my.com being the first domain to
publish p=reject policy. Please make sure to update configuration if you
need special handling for DMARC-restrictive domains.

In future, policy will be updated for other Mail.Ru public mailbox
domains, including mail.ua, bk.ru, inbox.ru, list.ru and finally mail.ru.

-- 
Vladimir Dubrovin
Head of QA Service
@Mail.Ru
___
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] what MUAs show, was introduction to the list-virtual

2016-02-15 Thread Roland Turner via dmarc-discuss 
John Levine wrote:

> DMARC does an OK job when crooks use the exact domain name, which they
> stilll do a lot, but we still don't have a clue about what to do when
> they don't, other than trying to filter it because it looks evil, not
> because it sorta kinda looks like a domain name in someone else's
> DMARC record.

+1, not the FUSPP.

- 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)