Re: [mailop] DMARC p=quarantine pct=0

[Brandon Long via mailop]

Well, that's the nature of production changes.  The best you can do is what
you have available with your tools and the standards.

At some point, you've exhausted the corrections you can make based on
p=none, and you need to make the next step, which is p=quarantine pct=0.

You should stay at that point for as long as it's useful.  You can see what
monitoring you can do while at that stage, see if there's any way to
measure your production mail traffic to see if there's major changes in
traffic.

There are obviously limitations built into this, given that this mostly
effects what other systems do with your traffic and the time frame before
you get feedback, but that's the break.

Theoretically, you could try it on some staging/limited/testing domain
first, but you probably won't have the volume necessary.  You can come up
with a list of services you care about and test them directly on a test
domain.  You could theoretically set up some end-to-end test (send email
from foo to bar and monitor whether it gets there, and do so with a new
email every 5 minutes)

If you consider any single email going awry a problem, then DMARC is
probably not what you want to do anyways, since there will never be 100%
non-false positives with DMARC.  That said, whether your mail is accepted
by any system ever is somewhat out of your hands, and improving your
chances of other servers accepting your legitimate email might depend on
setting up DMARC to clean out the garbage...

Brandon

On Fri, Apr 6, 2018 at 10:48 AM Jesse Thompson 
wrote:

> Well, that's the crux of the issue.  If I make this change and a
> DMARC-incompatible mailing list forwards a message to Gmail, the message
> might be treated as spam.  But I don't know which mailing lists are
> DMARC-incompatible until after I make this change.  I'm in a state of
> paralysis.  :-(
>
> Jesse
>
> On 4/6/2018 10:57 AM, Brandon Long wrote:
> > I know when I suggested it originally on this list, some folks found
> > some bugs, which we fixed.
> >
> > That said, the spam team seems to reinvent dmarc parsing periodically
> > (on top of our main dmarc processing), and it's often less than
> > correct.  In this case, it'll just mean that mail that doesn't pass will
> > more likely be marked as spam, so it's probably mostly safe if you've
> > gotten most of your sources covered.  And let me know, I can hassle them
> > again if it's broken again.
> >
> > Brandon
> >
> > On Fri, Apr 6, 2018, 8:31 AM Jesse Thompson  > > wrote:
> >
> > Great, thank you!  I'll give it a whirl and report back if anything
> > negative happens.
> >
> > Jesse
> >
> > On 4/5/2018 7:42 PM, Todd Herr via mailop wrote:
> >  > We saw no negative side effects when we did it here for our
> > domains, and
> >  > we did it for precisely the reason you're planning to do it, to
> > trigger
> >  > Google Groups.
> >  >
> >  > On Thu, Apr 5, 2018 at 7:00 PM, Jesse Thompson
> > 
> >  >  > >> wrote:
> >  >
> >  > Does anyone know of any negative side effects of setting a
> DMARC
> >  > policy: p=quarantine pct=0 ?
> >  >
> >  > Is it equivalent to: p=none ?
> >  >
> >  > I'm curious because I want to trigger Google Groups (and maybe
> >  > others list forwarders?) to rewrite the From in a DMARC
> compliant
> >  > fashion *prior* to changing the domain's DMARC policy... to
> avoid
> >  > the "leap of faith" that p=none's monitoring mode was
> supposed to
> >  > alleviate.
> >  >
> >  > Thanks,
> >  > Jesse
> >  > ___
> >  > mailop mailing list
> >  > mailop@mailop.org 
> > >
> >  > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> >  > 
> >  >
> >  >
> >  >
> >  >
> >  > --
> >  >
> >  > *todd herr**
> >  > **sr. delivery engineer
> >  > www.sparkpost.com 
> > *
> >  > *twitter* @toddherr @sparkpost
> >  >
> >  > *tel* 415-578-5222 x477
> >  > *mobile* 703-220-4153
> >  > *email* todd.h...@sparkpost.com 
> >  >  > >
> >  >
> >  >
> >  >
> >  > ___
> >  > mailop mailing list
> >  > mailop@mailop.org 
> >  > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> >  >
> >
> > 

Re: [mailop] DMARC p=quarantine pct=0

[Jesse Thompson]

Great, thank you!  I'll give it a whirl and report back if anything 
negative happens.


Jesse

On 4/5/2018 7:42 PM, Todd Herr via mailop wrote:
We saw no negative side effects when we did it here for our domains, and 
we did it for precisely the reason you're planning to do it, to trigger 
Google Groups.


On Thu, Apr 5, 2018 at 7:00 PM, Jesse Thompson > wrote:


Does anyone know of any negative side effects of setting a DMARC
policy: p=quarantine pct=0 ?

Is it equivalent to: p=none ?

I'm curious because I want to trigger Google Groups (and maybe
others list forwarders?) to rewrite the From in a DMARC compliant
fashion *prior* to changing the domain's DMARC policy... to avoid
the "leap of faith" that p=none's monitoring mode was supposed to
alleviate.

Thanks,
Jesse
___
mailop mailing list
mailop@mailop.org 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop





--

*todd herr**
**sr. delivery engineer
www.sparkpost.com *
*twitter* @toddherr @sparkpost

*tel* 415-578-5222 x477
*mobile* 703-220-4153
*email* todd.h...@sparkpost.com 





___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BGP Announcements

[Ryan Harris via mailop]

Thanks Ken and David. It's helpful to get your insight.

On Fri, Apr 6, 2018 at 5:47 AM, David Hofstee 
wrote:

> Hi Ryan,
>
> If spamfilters use machine learning, like the ones at Google, Microsoft,
> Yahoo, Proofpoint (and Cloudmark) then they tend to have a lot of inputs.
> Including "reputation" on AS and IP which may be dependent on changes in
> routing. Because that is one of the tricks that spammers use. This can
> cause weird false-positives (good email being filtered). You may not even
> know that you are doing something wrong, but you may still end up on the
> bad side of filtering because of that.
>
> Thing is, these ML engines are hard to "introspect" (its rules are not
> laid out, but are the result of self tuning internal parameters). It
> decides itself what is bad and not bad. Not even the people managing the
> filter may be able to tell exactly unless they have an example. Or tune it,
> for that matter.
>
> So watch those... I would not worry about the rest.
>
> Yours,
>
>
> David
>
> On 6 April 2018 at 12:21, Ken O'Driscoll via mailop 
> wrote:
>
>> On Thu, 2018-04-05 at 12:21 -0600, Ryan Harris via mailop wrote:
>> > Could this cause other issues I'm not thinking of?
>>
>> I think you just need to make sure that whatever you're doing wouldn't
>> look
>> like hijacking to a (moderately intelligent) machine learning algorithm.
>> And if you're keeping it all under the same AS then it probably wouldn't.
>>
>> I've never personally encountered a problem which was purely caused by
>> reassigning netblocks under the same org.
>>
>> Ken.
>>
>> --
>> Ken O'Driscoll / We Monitor Email
>> t: +353 1 254 9400 | w: www.wemonitoremail.com
>>
>> Need to understand deliverability? Now there's a book:
>> www.wemonitoremail.com/book
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>
>
>
> --
> --
> My opinion is mine.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BGP Announcements

[David Hofstee]

Hi Ryan,

If spamfilters use machine learning, like the ones at Google, Microsoft,
Yahoo, Proofpoint (and Cloudmark) then they tend to have a lot of inputs.
Including "reputation" on AS and IP which may be dependent on changes in
routing. Because that is one of the tricks that spammers use. This can
cause weird false-positives (good email being filtered). You may not even
know that you are doing something wrong, but you may still end up on the
bad side of filtering because of that.

Thing is, these ML engines are hard to "introspect" (its rules are not laid
out, but are the result of self tuning internal parameters). It decides
itself what is bad and not bad. Not even the people managing the filter may
be able to tell exactly unless they have an example. Or tune it, for that
matter.

So watch those... I would not worry about the rest.

Yours,


David

On 6 April 2018 at 12:21, Ken O'Driscoll via mailop 
wrote:

> On Thu, 2018-04-05 at 12:21 -0600, Ryan Harris via mailop wrote:
> > Could this cause other issues I'm not thinking of?
>
> I think you just need to make sure that whatever you're doing wouldn't look
> like hijacking to a (moderately intelligent) machine learning algorithm.
> And if you're keeping it all under the same AS then it probably wouldn't.
>
> I've never personally encountered a problem which was purely caused by
> reassigning netblocks under the same org.
>
> Ken.
>
> --
> Ken O'Driscoll / We Monitor Email
> t: +353 1 254 9400 | w: www.wemonitoremail.com
>
> Need to understand deliverability? Now there's a book:
> www.wemonitoremail.com/book
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>



-- 
--
My opinion is mine.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BGP Announcements

[Ken O'Driscoll via mailop]

On Thu, 2018-04-05 at 12:21 -0600, Ryan Harris via mailop wrote:
> Could this cause other issues I'm not thinking of?

I think you just need to make sure that whatever you're doing wouldn't look
like hijacking to a (moderately intelligent) machine learning algorithm.
And if you're keeping it all under the same AS then it probably wouldn't.

I've never personally encountered a problem which was purely caused by
reassigning netblocks under the same org.

Ken.

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Need to understand deliverability? Now there's a book:
www.wemonitoremail.com/book


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop