Re: [dmarc-discuss] A bit quiet?

[Brandon Long via dmarc-discuss]

Actually, do you have any more specifics for me to take a look?  Best case
would be the recipient and message-id of something that ended up in the
spam label.

Off list would be fine.

Brandon

On Fri, Feb 3, 2017 at 5:05 PM, Brandon Long  wrote:

> I'll take a look.
>
> On Thu, Feb 2, 2017 at 11:28 PM, Roland Turner <
> roland.tur...@trustsphere.com> wrote:
>
>> John Payne wrote:
>>
>> >> Presumably this just indicates that the rewrite rule that Brandon
>> described for Google Groups
>> >> is not in use by IETF's mailing lists?
>> >>
>> >> Tradeoffs in every direction...
>> >
>> > I wasn't expecting behavior changes for ietf mail.
>> >
>> > To clarify, with p=none I had no complaints. With p=quarantine, pct=0 I
>> have complaints from gmail users.
>> >
>> > I believe this points to gmail perhaps not looking at the pct...
>>
>> Apologies, wrote before thinking it through. What should have happened is
>> that the failures identified in aggregate reports should have gone down as
>> Google Groups would rewrite because of it, but that no changes in receiver
>> behaviour should occur.
>>
>> I agree, this looks like a Gmail bug.
>>
>> Brandon, are you able to explore this with your colleagues?
>>
>> - 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] A bit quiet?

[Brandon Long via dmarc-discuss]

I'll take a look.

On Thu, Feb 2, 2017 at 11:28 PM, Roland Turner <
roland.tur...@trustsphere.com> wrote:

> John Payne wrote:
>
> >> Presumably this just indicates that the rewrite rule that Brandon
> described for Google Groups
> >> is not in use by IETF's mailing lists?
> >>
> >> Tradeoffs in every direction...
> >
> > I wasn't expecting behavior changes for ietf mail.
> >
> > To clarify, with p=none I had no complaints. With p=quarantine, pct=0 I
> have complaints from gmail users.
> >
> > I believe this points to gmail perhaps not looking at the pct...
>
> Apologies, wrote before thinking it through. What should have happened is
> that the failures identified in aggregate reports should have gone down as
> Google Groups would rewrite because of it, but that no changes in receiver
> behaviour should occur.
>
> I agree, this looks like a Gmail bug.
>
> Brandon, are you able to explore this with your colleagues?
>
> - 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] Can dmarc-discuss-owner please step forward?

[Roland Turner via dmarc-discuss]

I've been having a subscription management problem for a couple of weeks, can't 
solve it myself, and the dmarc-discuss-owner alias doesn't appear to be 
working/responding.


- Roland


[https://www.trustsphere.com/images/signatures/trustsphere.gif] Roland 
Turner
Chief Privacy Officer
Mobile: +65 9670 0022
13-03 Royal Group Building, 3 Phillip Street, Singapore 048693


[facebook]  [twitter] 
 [linkedin] 
   [youtube] 

www.trustsphere.com


___
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] Why do I receive RUAs for emails that align?

[Jim Popovitch via dmarc-discuss]

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 larger
>> receivers see.
>
> Given that feedback is provided on an as-is basis, and particularly given
> your assertion immediately below, your preferences are presumably not
> relevant to this question.

Thank you Mr. Manners.

>
>>> This and some earlier remarks[1] suggest that you're treating DMARC as a
>>> product or service that you're being invited to purchase and whose vendor
>>> is
>>> therefore motivated to present a product or service that is to your
>>> liking -
>>
>> Absolutely not.   There is nothing I've said to remotely indicate
>> that, even that footnoted comment doesn't suggest I feel others have
>> an obligation to meet my demands.   They do, however, have an
>> obligation to send accurate data, and if they don't that is
>> disingenuous.
>
> Setting aside the mismatch between my observation and your response, you
> contradict yourself. Receivers who are providing you with feedback, on a
> gratis and as-is basis, obviously don't have the obligations that you are
> asserting.


That's just your opinion, man.   For the good of the industry they do
have an obligation to get it right.

>
>> Let me reiterate something I've said a few times now.   I only need 1
>> accurate report, that attests to alignment, to know that my work is
>> complete.   The rest are chaff, and I've got no interest in reading
>> reports on chaff.
>
> This claim is difficult to reconcile with the fact that you continue to look
> at smaller receivers' feedback and then complain about their failure to
> provide with accurate data. If this claim were correct, then
> your observed behaviour would be that you'd check against Yahoo! and/or
> Gmail and then not even look at other receivers' reports. This quite clearly
> does not describe the situation correctly and therefore invalidates your
> claim.

You are just reading and seeing what you want to see.   It's pretty
clear that I don't need to look at all reports, all the time; but that
I do, on occasion, look at all reports to see how things are going.

 In it's infancy DMARC was designed for transactional email, not human
 generated content.
>>>
>>> This is not correct. Right from the first high-volume domain with a
>>> p=reject
>>> policy (paypal.com) there was a mix of transactional and human-generated
>>> email with the same domain-name.
>>
>> I'm not going to dig up the history (esp at this hour of the AM before
>> the coffee is done brewing) but it's there in one of the early specs.
>> I've highlighted it before on this list.
>
> It is you who raised the history in support of your argument. If you're
> conceding that DMARC was originally designed/intended/implemented for use
> with individual email then this is moot. If not, then I'd happy to address
> any actual quote from relevant source material that appears to support your
> argument.

It's the first hit when you Google for "dmarc transactional"... should
I put that in a lmgtfy format for you?  :-)

>>> continue assessing DMARC feedback yourself, and accept that it contains
>>> warts and will never be perfect;
>>> find a vendor who will provide digested feedback which makes all of the
>>> unpleasantness go away before you see it (this is costly, and the
>>> likelihood
>>> of an exact match between your desires and the services on offer is low,
>>> however...); or
>>> disregard DMARC feedback entirely.
>>
>> I think I've already made my intention well known, and I would never
>> pay someone to report on suspect data.
>
> You appear to have multiple conflicting intentions (receivers are/are-not
> obliged to you, you want to examine only-one/all receivers' reports, etc.).

The world is multi-faceted, I apologize if the number of angles in
this thread has exceeded your capabilities.

To reiterate, I want to only look at necessary reports, but reserve
the right to, on occasion, dive deeper to try and route out and
further understand misc issues (you call them warts).

> Paying someone to report on suspect data is the opposite of what I proposed
> and you quoted.

I'm pretty sure your words advocated paying monies to someone else to
look at the totality of my DMARC reports.

>>> Agitating to have low level feedback mechanisms not have low-level warts
>>> is
>>> unlikely to succeed, particularly when that feedback is provided gratis.
>>
>> Thank goodness other solid ideas didn't struggle with those fiefdom
>> issues.   Imagine if FBLs and ARF had been subjected to this
>> pay-to-play model you're advocating.
>
> I don't advocate a pay-to-play model, I merely point it out as the
> appropriate option for someone who wants real-world warts removed for him,
> rather than deal with them himself. The