Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

[Jim Popovitch via dmarc-discuss]

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 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
> to learn how to use the analysis tools that everyone else uses.
>

I would hazard a guess that he hasn't grasped that this is the corollary of
the obligation that he is asserting that senders of reports have to him.
More importantly, it would appear that - despite my coming at the question
from multiple directions in the hope of finding common ground on this point
- he really does believe that random third parties have this obligation to
him. This being the case, agreement on how to address his initial concern
would appear to be impossible to achieve.


But perhaps this discussion can be over now.
>

I'm being politely prodded off-list along these lines and, sadly, am
inclined to agree. Apologies to all for not disengaging sooner.

- Roland



The only proper way to end this discussion is with a mental image: Statler
and Waldorf sitting in a balcony box, high above the stage.

-Jim P.
___
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] DMARC management how to

[Jim Popovitch via dmarc-discuss]

On Wed, Feb 8, 2017 at 5:01 AM, Sistemisti Posta via dmarc-discuss
 wrote:
> Hello,
>
>  how do you manage DMARC in multidomain environment?
>
> Renew the DKIM keys, deal with all DNS record... is not easy.

You could always use CNAMEs back to a few rotated keys.

-Jim P.
___
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 

Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

[Jim Popovitch via dmarc-discuss]

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 tested or
>> recorded".   That DMARC report is pointless without knowing more.
>
> 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.

> 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.

> and perhaps to improve it to that end - in order to encourage you to
> purchase. That's not what's going on. Partial visibility into receivers'
> systems is being provided, gratis, on an as-is basis (warts and all), in
> order to allow interested domain registrants/owners to take action to
> tighten their own practices and to detect and act against fraudulent uses of
> their domains. Experience to date suggests that what is being provided is
> appropriate and useful to that end. There remains scope for improvement of
> course, and the fact that some receivers' systems don't work in a way that
> even gathers the information that you'd like to receive - let alone report
> it - is an unfortunate fact of real world email systems.
>
> If you're unwilling or unable to process raw feedback, then you should
> perhaps seek out a service provider whose expertise includes dealing with
> the rough edges. There are several; naturally, most cost [quite a bit of]
> money.

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.

>> 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.


>>  In those days pundits decreed that DMARC wasn't
>> for MLMs and that mailinglists would be whitelisted and treated with
>> special care.  As it turns out, the truth is somewhat different.
>
> This is hardly surprising. Pundits should be considered entertainers, not
> oracles.

Some of those pundits are still reading this.

>> Of course, my interest has now turned to
>> trying to understand why XYZ determines there is a failure (was it a
>> DNS problem?, was there a middle man?, etc.).  The end goal being
>> perfect delivery, sans any problems or implication of there being a
>> problem needing investigation or effort on my part.
>
> This is fair enough, but as above, you'll do better if you understand the
> limitations of the tools that you're working with. Choices include:
>
> 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.

> 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.

-Jim P.
___
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 Wed, Feb 1, 2017 at 5:31 PM, A. Schulze via dmarc-discuss
<dmarc-discuss@dmarc.org> 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
>> mailman 8bit -> postfix:587 pickup
>
>> postfix cleanup (converts 8bit into 7bit)
>
> this assumption I wouldn't sign blindly. At least I'm not aware it's default 
> behaviour.

Well I am, and I trust the documentation.

> But this seem to be no longer interesting on this list.
> Maybe you like to clarify that on postfix-users...

I didn't come here for postfix support, I only provided the chain to
prove to you that it's not a 8bit vs 7bit issue.

Clearly it's a receiver side issue for a handful of lesser entities as
Google, Hotmail, and Yahoo ascertain the alignment of the same emails
that the handful fail.

-Jim P.
___
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 Wed, Feb 1, 2017 at 6:50 AM, A. Schulze via dmarc-discuss
<dmarc-discuss@dmarc.org> 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 8BITMIME. You send 8-BIT
> and your sending MTA recode down to 7-BIT. DKIM invalidation per design.
> Solution: send 7 BIT only
>

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 into 7bit)
postfix qmgr
postfix non-smtpD-milters -> opendkim
postfix qmgr
postfix smtp

-Jim P.
___
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 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 you explain what difficulty you're describing here? From the examples
> that you linked I saw messages that had SPF passes, meaning that the DKIM
> result was not important (and quite possibly not tested or recorded).

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.

>> so it makes it much more
>> difficult, for me, to trust the data.So... imho it's a waste of
>> time/effort building an archive of suspect data until faith can be
>> established in what is reported.
>
> You certainly shouldn't spend time and effort on this if you're not deriving
> value from it. The idea of trusting the data is an unusual one in a DMARC
> context though. One of the things that DMARC reporting does is to expose the
> variability and complexity of real-world email systems, meaning that the
> data often requires human interpretation and even guesswork. DMARC reports
> should be treated as indicative rather than trustworthy, in any typical
> sense of that word. It is certainly to be taken for granted that there is
> incomplete and/or erroneous data in the reports.
>
> It occurs to me that you've not spelled out clearly what you're attempting
> to achieve with DMARC (or I missed your doing so). Doing so might surface an
> incorrect expectation on your part that might allow your difficulties to be
> resolved in one step.

In it's infancy DMARC was designed for transactional email, not human
generated content.   In those days pundits decreed that DMARC wasn't
for MLMs and that mailinglists would be whitelisted and treated with
special care.  As it turns out, the truth is somewhat different.  For
starters, a LOT of what a MLM does *is* transactional, so DMARC is a
perfect fit for at least that part of it.  In particular Mailman sends
a lot of transactional notifications (subscription notices, posting
notices, password reminders, etc.) and it never really mattered (until
now) that Mailman would have a Sender and From with different domains
(sitelist vs mailing list).   In order to improve longterm
deliverabilty it was (to me) imperative to fix the Mailman domain
alignment issues wrt notifications.   Now that that is coded, and
DMARC RRs published, it's working perfectly, save for the few "false
positive" failure reports. Of course, my interest has now turned to
trying to understand why XYZ determines there is a failure (was it a
DNS problem?, was there a middle man?, etc.).  The end goal being
perfect delivery, sans any problems or implication of there being a
problem needing investigation or effort on my part.

-Jim P.
___
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 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 having that
>> >> information, and what is the "cost" of capturing it?
>> >
>> > To me, the value of these reports is pre-deployment, by carefully
>> > reviewing the reports you can identify any legitimate sources of mail
>> > which are not properly signed and aligned.
>>
>> 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... so it makes it much more
>> difficult, for me, to trust the data.So... imho it's a waste of
>> time/effort building an archive of suspect data until faith can be
>> established in what is reported.
>
> 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.   Depending on your Mailman config, mailman *might*
send list notifications in ways you might not expect.   I set out last
year to identify what I saw as bugs in the way Mailman sent
notifications differently than list traffic.   Those changes are
tracked here:
https://code.launchpad.net/~jimpop/mailman/virtual-notices


> 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.

It is disingenuous, imho, for a receiver to submit a DMARC report to a
sender if the subtle failures are receiver side or if those reports
don't contain enough information for the receiver to understand the
reason(s) for the subtle failure ("give me the RUF or STFU").  :-)

>> Here's a few examples for the same email:
>>
>> Hotmail gets it right:
>> http://domainmail.org/dmarc-reports/hotmail.com%21netcoolusers.org%211485698400%211485784800.xml
>>
>> ItaliaOnline gets it right:
>> http://domainmail.org/dmarc-reports/italiaonline.it%21netcoolusers.org%211485778386%211485778386.xml
>>
>> VirginMedia gets it wrong:
>> http://domainmail.org/dmarc-reports/virginmedia.co.uk%21netcoolusers.org%211485734404%211485820804.xml
>>
>> CSP-Net gets it wrong:
>> http://domainmail.org/dmarc-reports/bechu-vir0001.csp-net.ch%21netcoolusers.org%211485730804%211485817204.xml
>
> I see in those samples you provide that DKIM is failing for some
> messages. Could it be that some subscriber(s) to your mailing list has
> set up some kind of subject-tagging and ulterior forwarding when he
> receives your mailing list messages?

Great question, but you should ask Virgin Media or CSP-Net.   I'd bet
a few beers that the DKIM failures are due to those companies
injecting inbound msg headers before processing DMARC checksbut
without the RUF who really knowsand more importantly why should I
invest time/effort into tracking that "failure".

>> So it's 50/50 for the same small sample of list traffic.   Do I care,
>> sure!   If someone from Virgin Media or CSP-Net wants to explain the
>> failures (or send me the RUFs that I already ask for) then I am all
>> ears.   Until then, I remain a skeptic.  ;-)
>
> Skeptic about what: about those receivers ability to properly check
> DMARC, or about the usefulness to you of DMARC reporting?

Skeptic about the usefulness of the reporting.  As I said before, If 1
receiver shows alignment then my work is complete.

> It seems to me that DMARC reporting is all about statistics, and for
> statistics to be relevant you have to drown down the noise, and for that
> you need to have a big enough sample. The samples you provided are very
> small in the quantity of messages reported, so it could well be that
> you are seeing noise just now, and that you need a much bigger sample
> to reap the value of DMARC reporting.

I disagree.   The larger sample size is still statistically suspect
due to all the blind spots in the receiver generated data.   Just
knowing you have a 0.02% DKIM failure is meaningless without knowing
why.


> For example, see bullet point 3 here to read
> about the true value of DMARC reporting:
> https://blogs.msdn.microsoft.com/tzink/2016/09/27/how-we-moved-microsoft-com-to-a-pquarantine-dmarc-record/
>

That hurt my eyes to read. :-)   Did you not notice these 2
conflicting sentences in the first paragraph:

   "In case you hadn’t noticed, Microsoft recently published a DMARC record"

   "This means that any sender transmitting email either into
Microsoft’s corp mail servers..."


Hint: Microsoft's DMARC record is NOT used by senders transmitting
email to Microsoft.

-Jim P.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: 

Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

[Jim Popovitch via dmarc-discuss]

On Sat, Jan 28, 2017 at 1:49 AM, Dave Warren via dmarc-discuss
<dmarc-discuss@dmarc.org> 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
>> <dmarc-discuss@dmarc.org> 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
>> > ISPs generally reporting random spam that happened to randomly fake my
>> > domain.
>>
>> But what can you do about it?  What is the "value" of having that
>> information, and what is the "cost" of capturing it?
>
> To me, the value of these reports is pre-deployment, by carefully
> reviewing the reports you can identify any legitimate sources of mail
> which are not properly signed and aligned.
>
> As a company that currently has no employees beyond myself and only a
> few hundred clients, I was able to find a couple legitimate sources of
> mail coming from my own domain that had been previously overlooked.


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... so it makes it much more
difficult, for me, to trust the data.So... imho it's a waste of
time/effort building an archive of suspect data until faith can be
established in what is reported.

Here's a few examples for the same email:

Hotmail gets it right:
http://domainmail.org/dmarc-reports/hotmail.com%21netcoolusers.org%211485698400%211485784800.xml

ItaliaOnline gets it right:
http://domainmail.org/dmarc-reports/italiaonline.it%21netcoolusers.org%211485778386%211485778386.xml

VirginMedia gets it wrong:
http://domainmail.org/dmarc-reports/virginmedia.co.uk%21netcoolusers.org%211485734404%211485820804.xml

CSP-Net gets it wrong:
http://domainmail.org/dmarc-reports/bechu-vir0001.csp-net.ch%21netcoolusers.org%211485730804%211485817204.xml


So it's 50/50 for the same small sample of list traffic.   Do I care,
sure!   If someone from Virgin Media or CSP-Net wants to explain the
failures (or send me the RUFs that I already ask for) then I am all
ears.   Until then, I remain a skeptic.  ;-)

-Jim P.
___
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 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 inconsistencies
("failures" from one or more receivers for the exact same data that
aligns at other receivers).


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
> ISPs generally reporting random spam that happened to randomly fake my
> domain.

But what can you do about it?  What is the "value" of having that
information, and what is the "cost" of capturing it?

> The aggregate reports tell you about both success and failures, so put
> them in a database and query for stats about the failures.  This is
> not, as they say, rocket science.

I can appreciate that folks do that, and that's awesome.   For me and
my systems that just seems like unnecessary overkill.  My interests
end when just 1 legitimate receiver verifies alignment, after that any
failures are 99.999% probably not my fault and most assuredly outside
of my control.

-Jim P.
___
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 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 7489.  Aggregate reports
> tell you about all the mail a system got that has your domain on the
> From: line.
>
> Everyone I know automatically parses the aggregate reports and puts
> the info in a database so they can query it about whatever is of
> interest.
>
> Here's some scripts I give away that do the parse and put in a database part.
>
> http://www.taugh.com/rddmarc/
>
> R's,
> John

Thanks John,

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.

-Jim P.
___
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] RUF reports

[Jim Popovitch via dmarc-discuss]

On Thu, Jan 5, 2017 at 10:05 PM, Steven M Jones <s...@crash.com> wrote:
> On 01/05/2017 17:32, Jim Popovitch via dmarc-discuss wrote:
>> I've been trying, albeit slowly, to determine why I haven't seen any
>> RUF reports since Sept 2016.
>>
>> Shouldn't this RUA report also produce a corresponding RUF?
>
> Are you DKIM signing these messages?

No.  The msg is presumably spam sent by 171.40.246.96 (an IP I don't
have any access to) using a domain that I hold (and it's a domain that
never sends any email)

Google caught similar attempts from 159.253.38.11 using that same domain.

http://domainmail.org/dmarc-reports/google.com%21inug.org%211483401600%211483487999.xml

> Because I notice the reason given
> for the local policy override includes "Ignore dkim/spf DNS query" and
> there's no DKIM section in  - making me wonder if they had
> a problem accessing your selector, and that the comment above really
> means "our DNS query for a DKIM record received no response."
>
> Plausible? I don't see enough information to rule it out...

Interesting, but they won't find a selector for that domain on my DNS
systems as its not used for email.

-Jim P.
___
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] RUF reports

[Jim Popovitch via dmarc-discuss]

Hello,

I've been trying, albeit slowly, to determine why I haven't seen any
RUF reports since Sept 2016.

Shouldn't this RUA report also produce a corresponding RUF?

http://domainmail.org/dmarc-reports/126.com%21inug.org%211483574400%211483660799.xml

-Jim P.
___
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)