On Wed, Jul 31, 2019 at 9:40 PM Scott Kitterman
wrote:
> Can we discuss this choice? I know this has been implemented already, so
> I'm
> at least slightly reluctant to do the semi-standard lets rename existing
> stuff
> dance that the IETF often does, but I really don't like this. There isn't
On Thursday, June 27, 2019 5:10:39 AM EDT Alessandro Vesely wrote:
> On Wed 26/Jun/2019 22:27:46 +0200 Murray S. Kucherawy wrote:
> > On Tue, Jun 4, 2019 at 4:01 AM Alessandro Vesely wrote:
> >> Appendix D1 of rfc7208 mentions DNSWL as a way to mitigate SPF's
> >> reject-on-fail. The score
On Wed, Jul 31, 2019 at 7:58 AM Freddie Leeman wrote:
> 0: Generate a DMARC aggregate report for every message, regardless of its
> alignment.
>
1: Generate a DMARC aggregate report if any underlying authentication
> mechanism produced something other than an aligned "pass" result.
>
> d:
On Mon, Jul 29, 2019 at 12:38 PM Scott Kitterman
wrote:
> I'd like to add the option to record DMARC results in an A-R header field
> for
> consumption by a downstream processor. I think it would be something like
> this:
>
> Authentication-Results: mail-router.example.net; dmarc=pass
>
On Tue, Jul 30, 2019 at 7:29 AM Дилян Палаузов
wrote:
> if policy quarantine will be kept, I propose including this text in the
> specification:
>
> Messages, subject to the quarantine policy, directed to a single recipient
> that does not support the concept of
> quarantining, can be either
On Sun, Jul 28, 2019 at 6:37 AM Tim Wicinski wrote:
> From our end user point of view, I'm against abolishing quarantine, even
> with its current shortcomings.
>
Why's that?
-MSK, also hatless
___
dmarc mailing list
dmarc@ietf.org
Thanks for this, much better. Some additional feedback.
Please note (everyone) that I'm offering these as clarifying contributions
to text; I'm not prescribing or proscribing anything. If the text I'm
proposing isn't worthy of consensus, please speak up.
On Sat, Jul 27, 2019 at 1:45 PM Scott
Having both passes and failures is incredibly useful. The percentage of
failures is very useful. Any set of mail streams will always have some
failures. Once you know what the baseline rate for a (sub)domain is, simply
seeing changes in that rate will help you identify problems. An increase in
the
Hello Fredie,
DMARC limits the amount of servers that can generate emails for a particular
domain. The aggregate reports show to
which extend DMARC does work correctly and when it fails for a domain. The
aggregate reports to not tell you how to fix
your DKIM implementation, so that sender and
Hi Дилян,
Thanks for your input and feedback. Maybe a single tag, that allows the domain
owner to avoid receiving aggregate reports for messages that align, would be
enough? I personally have little experience with mailing lists which, I
understand, can be a real pain when it comes to
Thanks Kurt, I’ve made the adjustments to the document.
--Freddie Leeman
Van: Kurt Andersen (b) [mailto:kb...@drkurt.com]
Verzonden: woensdag 31 juli 2019 17:00
Aan: Freddie Leeman
CC: dmarc@ietf.org
Onderwerp: Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies
On
Hello Freddie,
if a message has 5 DKIM-Signatures, some of them fail DKIM validation and some
of them do not align, irrespective of validation status, you want to receive a
report for the failed DKIM signatures. The proposed option d is in the DKIM
domain. DMARC without alignment is DKIM or
On Wed, Jul 31, 2019 at 2:47 AM Freddie Leeman wrote:
> I’ve been processing millions of DMARC aggregate reports from a lot of
> different organizations, and have been trying to make sense of them for
> quite some time now. I’ve noticed that most of them, even those from large
> parties like
Would it be useful to add an 'ao' tag name for aggregate reporting options?
Something like:
ao: Aggregate reporting options (plain-text; OPTIONAL; default is
"0").
Provides requested options for generation of aggregate reports. This tag's
content MUST be ignored if a "rua" tag is not
On Wed, Jul 31, 2019, at 6:46 AM, Scott Kitterman wrote:
> On July 31, 2019 7:11:49 AM UTC, Alessandro Vesely wrote:
> >On Tue 30/Jul/2019 15:56:16 +0200 Scott Kitterman wrote:
> >
> >> The published policy (that's why I suggest dmarc.policy).
> >
> >
> >Published policy can be ambiguous. Say you
I've been processing millions of DMARC aggregate reports from a lot of
different organizations, and have been trying to make sense of them for
quite some time now. I've noticed that most of them, even those from large
parties like Google and Yahoo!, fail to follow the DMARC RFC guidelines
On Tue 30/Jul/2019 15:56:16 +0200 Scott Kitterman wrote:
> The published policy (that's why I suggest dmarc.policy).
Published policy can be ambiguous. Say you have p=quarantine; sp=none. The
MTA chooses which to apply based on the domains (publishing and From:). So it
makes sense to write
17 matches
Mail list logo
