27.01.2019 0:14, Дилян Палаузов пишет:
> Hello,
>
> reiterating over the arguments against sending reports to the ruf= …dmarc
> address, the first provided reason was, that
> such report will not match the expectations of the users.
> .... very good technical arguments skipped....
Nope, the point was it can finally lead to violation of privacy and
legal risks.
Since you probably speak Russian, I can give some good example.
As you may be know, E-mail in Russia is regulated by Telecommunication
Act (Закон о связи).
Article 63.4 ("communication privacy") says "Information about messages
sent via electronic communications ... and said messages .... can only
be provided to sender or recipient ...".
To make a ruf report one should send information about message to
address which is neither sender nor recipient.
Your argumentation is very good to explain a technical staff why some
partial information can be safely sent to some site. The only problem
is, there is no need to explain it here, you should satisfy a lawyer.
> It can be assumed, that sending reports to the ruf= address at a certain
> domain
> matches the expectations of the users of that domain and any non-matching
> expectation is a problem of the one who
> published the ruf= entry, not the one generating a report. I do not say that
> once the report is generated and sent the
> sender has to store the report, so that the expectation of the user, that
> received the initial mail, are also met, when
> the report generating server does not store a copy of the sent report.
>
> The second argument was, that staff managing DNS and staff managing emails
> (and able to read user’s email) are
> completely different persons. I do read here, that the DNS staff can use its
> posititon to insert arbitrary email
> addresses in the ruf= tag and by this way come in a position to read emails,
> that otherwise the DNS staff would not be
> entitled to read. Seriously, if the ruf= tag is not trusted, why shall the
> p= tag be honoured, and why shall also be
> the DKIM public signature and MX record be trusted? Either the ruf= email
> address is trusted to receive reports, or the
> whole DNS of the sending domain is not trusted.
>
> The third argument is, that in case 1% ouf of 10 000 000 messages between two
> hosts are reported in the aggregate
> message not to match DKIM, then it is worth investigating the cause.
> Alright, that is exactly my point. I want the
> reports, provide ruf=, and don’t receive the reports. Where will you start
> investigating? How can you find out if the
> problem is on the sender or receiver side? If you validate once again your
> implementation and find nothing wrong with
> it, does it prove, that the implementation of other side has bugs? Perhaps
> the other side has also proven in the very
> same way, that it is error-free. You see only that 1% of the messages do not
> match DKIM validation, now and then. What
> is the next step to make signer and verifier compatible?
>
> Guessing? If making signers and verifier compatible can be achieved only by
> guessing, then DMARC cannot be trusted/is
> not mature.
>
> I have no problems if due changes somewhere DKIM for a while fails, as in
> this case there is nothing I can do. But I
> want to be sure, that the cause is not on my side, and currently this is not
> evident. It is just not clear, if there is
> a problem report, if the problem is temporary, when the cause was resolved,
> if the cause is on my side… This properties
> make DMARC not reliable.
>
> Regards
> Дилян
>
> On Sat, 2019-01-26 at 12:56 -0500, Dotzero wrote:
>> Please, RUF is a ""Failure Report", not a "Forensic Report". Please read RFC
>> 7489 - https://datatracker.ietf.org/doc/rfc7489/
>>
>> On Sat, Jan 26, 2019 at 12:21 PM Дилян Палаузов <dilyan.palau...@aegee.org>
>> wrote:
>>> Hello John,
>>>
>>> On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote:
>>>> In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.ca...@aegee.org> you
>>>> write:
>>>>> How can a domain owner communicate, that its users agree to have
>>>>> investigations on forensic reports, where DKIM
>>>>> signatures failed (fot the purpose of avoiding repeating errors in DKIM
>>>>> signing/validation)? In particular, that there
>>>>> is no expectation of the users that a deleted message is erased and that
>>>>> the domain owner, DNS staff and email staff
>>>>> function good as whole?
>> This is way outside the scope of DMARC., however, the very fact that the
>> domain has provided an email address for receiving RUF reports is a pretty
>> reliable indicator. Presumably DNS and mailops staff work for/on behalf of
>> the domain owner.
>>
>>>> I suppose they could try to put it in the terms of service, but I
>>>> wouldn't begin to guess whether that would be enforcable or even legal
>>>> in places with the GDPR and other privacy laws.
>>>>
>>>> More to the point, I wouldn't bother. The failure reports are almost
>>>> entirely useless. Of the ones I get, the majority are random Chinese
>>>> spam that happened to forge one of my domains on the From line, the
>>>> rest are from mailing lists where I wouldn't expect DMARC to pass.
>> Clearing out the chaff originating from servers other than your own helps,
>> but I'm not going to try to teach John anything.
>>> A domain owner can certainly clarify anything in the terms of service, but
>>> even if the domain owner does these
>>> clarifications, s/he will not receive DKIM/DMARC forensic reports, because
>>> there is no mean to communicate to the
>>> generators of those reports, that sending forensic reports violates users
>>> expectations.
>> Individual user expectations are well outside the scope of DMARC. It is a
>> domain/subdomain level protocol. If you don't want the reports then don't
>> provide a destination for them to be delivered to.
>>> The reasons mentioned here against sending forensic reports were, that this
>>> might not match user expectations (on
>>> deleted information) and because email staff and DNS staff may differ. I
>>> approached both concerns, by stating that user
>>> expections can be put in Terms of Use and that a domain owner can decide,
>>> that for a domain it is acceptable to receive
>>> forensic reports and insert this infomation in the Terms of Use. So… what
>>> else exactly needs to happen, to resolve the
>>> concerns against sending forensic reports (which was my original question)?
>>>
>>> If GDPR is the only concern, this can also be clarified. But clarifying
>>> that GDPR is not a problem, will be losing
>>> time, if independent of it there are other concerns.
>>>
>>> Imagine there is a failure report stating that after a direct communication
>>> between your server and another server, the
>>> receiving server sends you an aggregate report, stating that 1% of the
>>> messages you sent yesterday do not validate DKIM.
>>> How do you suggest to proceed to reduce this to 0%?
>> Over time you are unlikely to keep "legitimate" failures at 0%. There are
>> lots of moving parts and pieces that can cause a failure. It also depends on
>> the characteristics of the mail streams involved. The domain owner(s) and
>> staff will need to determine how much effort they are willing to put in
>> eliminating (legitimate) email failures. If I'm sending 10 million emails to
>> a domain and 1% are failing then I'm likely to look into it. On the other
>> hand, if I'm sending 100 emails a day to a domain from an overall large
>> system and 1% (1 email) is failing, that really falls into the noise and is
>> unlikely to get much time spent on it.
>>
>> Michael Hammer
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
--
Vladimir Dubrovin
@Mail.Ru
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
