A concrete example occurred to me of an analysis which benefits from
receiving reasonably accurate success data in addition to failure data:
a non-Domain-Owner/non-Sender Report Receiver who is attempting to
assess the competence of Domain Owner policy assertions will typically
not have direct information about how many messages were sent in total;
if success information is excluded by most/all report generators then
any numerical analysis will be impossible, or at least very inaccurate.
On balance this case may be moot, but for completeness:
* For a Report Receiver performing such an analysis for a Domain
Owner, the latter is likely to be willing to provide relevant
numbers anyway, albeit with greater difficulty and less accuracy.
* For the same relationship, visibility of the behaviour - successful
and unsuccessful - of ESPs acting on behalf of the Domain Owner is
likely to be of particular interest. (This is also true for the case
where the Report Receiver and Domain Owner are the same entity.)
* A Report Receiver may face a conflict of interest in publishing
competence assessments of the same Domain Owners who have requested
that feedback be delivered to them in the first place, but equally
they may not. Other things being equal, it would appear desirable to
foster conditions in which this might happen.
None of these are directly helpful to receivers, but they do contribute
to the usefulness of DMARC to other honest participants in the email
system which is likely to indirectly benefit receivers in much the same
sense that providing feedback does in the first place.
- Roland
On 01/23/2014 06:33 PM, Roland Turner wrote:
Domain owners will of course make use of whatever data they can get
their hands on, but for many of the likely analyses the less
contaminated/biased/truncated the data is, the better. DMARC as a
whole will work better if the only limits to feedback are:
* Legal constraints on receivers, if/where they exist
* Distrust by receivers of specific domain owners
* Throughput problems (domain owner/report receiver's mail-server is
overloaded/down)
Receivers are of course free to do, or not do, as they wish - even if
the spec says otherwise - however I suspect that adding knobs to
twiddle that aren't widely useful will complicate the implementation
of DMARC for receivers (and indeed, each knob adds decision questions
for receivers to resolve thereby adding implementation cost; each on
its own is small, but a large enough number invites implementation
oversights and errors) and the interpretation of them by domain owners
("in addition to any other oddities, some receivers drop reporting of
successes!") and thus diminish the effectiveness of DMARC overall.
This is not to say that features to suit receivers shouldn't be made
to receiver-side implementations, but I'm inclined to believe that
there's a better way to handle this particular issue. If I understand
the initial report correctly, the concern is not the sending of "all
is well" reports per se, but rather that domain owners/report
receivers with broken infrastructure cause reports to get stuck in the
receiver's/report sender's outbound queue. The solution to this
problem is obvious: don't queue. Inconveniently, implementing this
approach has to happen in the receiver's/report sender's outbound MTA
unless you're willing to add an SMTP client (with DKIM signing!) to
opendmarc. (Details of this discussion belong in another list, I know.)
- Roland
On 01/22/2014 04:55 AM, Murray S. Kucherawy wrote:
I've received a feature request for OpenDMARC to limit what goes into
aggregate reports. Specifically, the suggestion is not to store any
data regarding messages that pass the DMARC test and thus only report
on things that fail.
I don't believe the current specification says anything requiring
that all messages be recorded, so I think this wouldn't violate the
specification, but it might violate the spirit of what was intended
or what's desirable to Domain Owners.
Comments?
-MSK
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
