On 2017 Feb 8, 10:08, Jim Popovitch via dmarc-discuss wrote:
> On Wed, Feb 8, 2017 at 9:45 AM, John Levine via dmarc-discuss wrote:
>
> > But perhaps this discussion can be over now.
>
> Not with false and misleading statements/assumptions.
Oh, come on!
https://xkcd.com/386/
--
Peter Gonzal
On Feb 9, 2017 01:36, "Roland Turner via dmarc-discuss" <
dmarc-discuss@dmarc.org> wrote:
On 02/08/2017 10:45 PM, John Levine via dmarc-discuss wrote (after Jim
Popovitch wrote):
They have an obligation, to everyone, to get it right, irregardless of
>> sender preferences.
>>
> I have to say that
On 02/08/2017 10:45 PM, John Levine via dmarc-discuss wrote (after Jim
Popovitch wrote):
They have an obligation, to everyone, to get it right, irregardless of
sender preferences.
I have to say that it's amusing that someone apparently believes that
every DMARC installation in the world should
On Wed, Feb 8, 2017 at 9:45 AM, John Levine via dmarc-discuss
wrote:
>>They have an obligation, to everyone, to get it right, irregardless of
>>sender preferences.
>
> I have to say that it's amusing that someone apparently believes that
> every DMARC installation in the world should rewrite their
>They have an obligation, to everyone, to get it right, irregardless of
>sender preferences.
I have to say that it's amusing that someone apparently believes that
every DMARC installation in the world should rewrite their code,
breaking backward compatibility, merely because he can't be bothered
t
On Wed, Feb 8, 2017 at 3:13 AM, Roland Turner via dmarc-discuss
wrote:
>
>Are you conceding that receivers sending reports may not find your preferences
>terribly important?
They have an obligation, to everyone, to get it right, irregardless of
sender preferences.
> Noting Google's tendency t
Jim Popovitch wrote:
You should definitely disregard reports that aren't useful to you.
>>>
>>> I'd actually prefer to work with the sender in order to fully
>>> understand the differences between what they see and what larger
>>> receivers see.
>>
>> Given that feedback is provided on an as-
On Fri, Feb 3, 2017 at 1:50 AM, Roland Turner via dmarc-discuss
wrote:
> Jim Popovitch wrote:
>
>
>>> You should definitely disregard reports that aren't useful to you.
>>
>> I'd actually prefer to work with the sender in order to fully
>> understand the differences between what they see and what
Jim Popovitch wrote:
>> You should definitely disregard reports that aren't useful to you.
>
> I'd actually prefer to work with the sender in order to fully
> understand the differences between what they see and what larger
> receivers see.
Given that feedback is provided on an as-is basis, and
On Thu, Feb 2, 2017 at 1:58 AM, Roland Turner via dmarc-discuss
wrote:
> Jim Popovitch wrote:
>
>
>> The difficulty I have is exactly as you described. I received a
>> DMARC report that says there is a DKIM failure, but what is not clear
>> is whether or not the email was "quite possibly not tes
Jim Popovitch wrote:
> The difficulty I have is exactly as you described. I received a
> DMARC report that says there is a DKIM failure, but what is not clear
> is whether or not the email was "quite possibly not tested or
> recorded". That DMARC report is pointless without knowing more.
You
On Wed, Feb 1, 2017 at 5:31 PM, A. Schulze via dmarc-discuss
wrote:
>
>
> Am 01.02.2017 um 15:11 schrieb Jim Popovitch via dmarc-discuss:
>> I'm running postfix and AFAIK it's only sending 7bit.
>>
>> postfix postscreen
>> postfix smtpD
>> postfix local -> mailman
>>
Am 01.02.2017 um 15:11 schrieb Jim Popovitch via dmarc-discuss:
> I'm running postfix and AFAIK it's only sending 7bit.
>
> postfix postscreen
> postfix smtpD
> postfix local -> mailman
> mailman 8bit -> postfix:587 pickup
> postfix cleanup (converts 8bit
On Wed, Feb 1, 2017 at 4:03 PM, Peter Gonzalez via dmarc-discuss
wrote:
> On 2017 Jan 31, 21:14, Jim Popovitch wrote:
>> On Tue, Jan 31, 2017 at 5:24 PM, Peter Gonzalez wrote:
>>
>> > So what exactly did you do to "roll out additional DMARC support" in
>> > your Mailman setup?
>>
>> Mailman has hi
On 2017 Jan 31, 21:14, Jim Popovitch wrote:
> On Tue, Jan 31, 2017 at 5:24 PM, Peter Gonzalez wrote:
>
> > So what exactly did you do to "roll out additional DMARC support" in
> > your Mailman setup?
>
> Mailman has historically done some funky things with moderator/owner
> notifications. Depend
Peter Gonzalez via dmarc-discuss skrev den 2017-01-31 23:24:
I don't see why you suspect receivers of your mailing list traffic are
doing it wrong when checking it for DMARC. Mailing list traffic is
prone
to fail DMARC checks in subtle ways.
funny part here is that dmarc.org do dmarc pass, b
On Wed, Feb 1, 2017 at 6:50 AM, A. Schulze via dmarc-discuss
wrote:
>
> Jim Popovitch via dmarc-discuss:
>
>> I'd bet a few beers that the DKIM failures are due to those companies
>> injecting inbound msg headers before processing DMARC checks.
>
>
> an other option: the MX server don't announce 8
Jim Popovitch via dmarc-discuss:
I'd bet a few beers that the DKIM failures are due to those companies
injecting inbound msg headers before processing DMARC checks.
an other option: the MX server don't announce 8BITMIME. You send 8-BIT
and your sending MTA recode down to 7-BIT. DKIM invalidat
On Tue, Jan 31, 2017 at 11:14 PM, Roland Turner via dmarc-discuss
wrote:
> Jim Popovitch wrote:
>
>
>> I rolled out additional DMARC support for Mailman (outbound alignment)
>> recently, and to be honest I'm not yet convinced that all receivers
>> have a clue when verifying alignment...
>
> Can yo
Jim Popovitch wrote:
> I rolled out additional DMARC support for Mailman (outbound alignment)
> recently, and to be honest I'm not yet convinced that all receivers
> have a clue when verifying alignment...
Can you explain what difficulty you're describing here? From the examples that
you linked
On Tue, Jan 31, 2017 at 5:24 PM, Peter Gonzalez via dmarc-discuss
wrote:
> On 2017 Jan 31, 05:59, Jim Popovitch wrote:
>> On Sat, Jan 28, 2017 at 1:49 AM, Dave Warren wrote:
>> > On Fri, Jan 27, 2017, at 04:23, Jim Popovitch wrote:
>> >
>> >> But what can you do about it? What is the "value" of h
On 2017 Jan 31, 05:59, Jim Popovitch wrote:
> On Sat, Jan 28, 2017 at 1:49 AM, Dave Warren wrote:
> > On Fri, Jan 27, 2017, at 04:23, Jim Popovitch wrote:
> >
> >> But what can you do about it? What is the "value" of having that
> >> information, and what is the "cost" of capturing it?
> >
> > To
On Sat, Jan 28, 2017 at 1:49 AM, Dave Warren via dmarc-discuss
wrote:
> On Fri, Jan 27, 2017, at 04:23, Jim Popovitch via dmarc-discuss wrote:
>> On Thu, Jan 26, 2017 at 11:13 PM, John Levine via dmarc-discuss
>> wrote:
>> > I concur with Roland. Looking at my failure reports, I see some from
>>
On Fri, Jan 27, 2017, at 04:23, Jim Popovitch via dmarc-discuss wrote:
> On Thu, Jan 26, 2017 at 11:13 PM, John Levine via dmarc-discuss
> wrote:
> > I concur with Roland. Looking at my failure reports, I see some from
> > Hotmail and Linkedin and beyond that a few from Chinese and Russian
> > IS
On 01/27/2017 04:23 AM, Jim Popovitch via dmarc-discuss wrote:
>
> I can appreciate that folks do that, and that's awesome. For me and
> my systems that just seems like unnecessary overkill.
Ultimately that's a decision each domain owner/operator has to make for
themselves.
But I would hope tha
On Fri, Jan 27, 2017 at 7:23 AM, Jim Popovitch wrote:
> On Thu, Jan 26, 2017 at 10:33 PM, Roland Turner via dmarc-discuss
> wrote:
>> Bear in mind that all reporting is at the good graces of receivers; the
>> options to fine-tune what is sent may, or may not, actually be implemented
>> by any g
On Thu, Jan 26, 2017 at 10:33 PM, Roland Turner via dmarc-discuss
wrote:
> Bear in mind that all reporting is at the good graces of receivers; the
> options to fine-tune what is sent may, or may not, actually be implemented by
> any given receiver.
Great point. I do already see a fair bit of i
>I guess I'm now more inclined to remove the rua= stanza as I don't
>manage user accounts and am really only interested in the failures.
I concur with Roland. Looking at my failure reports, I see some from
Hotmail and Linkedin and beyond that a few from Chinese and Russian
ISPs generally reportin
alf of Jim
Popovitch via dmarc-discuss
Sent: Friday, 27 January 2017 07:43
To: John Levine
Cc: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] Why do I receive RUAs for emails that align?
On Thu, Jan 26, 2017 at 5:50 PM, John Levine wrote:
> In article
> you
> write:
>>Hel
On Thu, Jan 26, 2017 at 5:50 PM, John Levine wrote:
> In article
> you
> write:
>>Hello,
>>
>>I'm trying to limit RUA/RUFs to legitimate emails that need eyeballs.
>>
>>To that end, I'm scratching my head as to why I get RUAs that clearly align.
>
> That's how it works. See section 7.2 of RFC
In article
you write:
>Hello,
>
>I'm trying to limit RUA/RUFs to legitimate emails that need eyeballs.
>
>To that end, I'm scratching my head as to why I get RUAs that clearly align.
That's how it works. See section 7.2 of RFC 7489. Aggregate reports
tell you about all the mail a system got th
Hello,
I'm trying to limit RUA/RUFs to legitimate emails that need eyeballs.
To that end, I'm scratching my head as to why I get RUAs that clearly align.
Here's the RR:
~$ dig TXT _dmarc.netcoolusers.org
"v=DMARC1; p=reject; pct=100; fo=1; adkim=r; aspf=r;
rua=mailto:dmarcr...@domainmail.org;
r
32 matches
Mail list logo
