>
>
> Barry, this is obviously a new relaxation option. From a mail system
> integration standpoint, the options are:
>
> 1) A version bump to DMARC2 with new semantics with backward DMARC1
> compatibility, or
>
> 2) Use a DMARC1 Extended tag option allowed by DMARC1. Alessandro cited
> an
t with an API hook allowing the hosting providers to hook this up
for their clients at scale.
Regards,
Ken
--
Ken Simpson
CEO, MailChannels
<https://www.mailchannels.com/?utm_source=Email%20Signature_medium=Ken%20Simpson_campaign=Website>
Facebook <http://bit.ly/2dnoP3K> | Twitter
nticated message to be distrusted by some
>> >> evaluators.
>> >>
>> >> Similarly, needs multiple types of FAIL. Since the data indicates
>> >> that missing (or invalid) public keys are a significant portion of
>> >> all failures, it needs a separate failure code
On Thu, Mar 21, 2019 at 10:09 AM John R Levine wrote:
> > IMHO, by cutting out direct domain spoofing, DMARC makes it easier for
> > receivers to craft algorithms that spot impersonation attacks.
>
> I realize that's the theory, but do we know how well that works in
> practice?
>
That would be
>
>
> > I'm going to have to disagree with you John. DMARC is about preventing
> > direct domain abuse. It does not specifically address phishing as the bad
> > guys can simply use cousin domains, homoglyphs, etc.
>
> Well, it's abount a subset of phishing. It's surely more about phishing
> than
