search

ietf-wg-dmarc / draft-ietf-dmarc-dmarcbis

6 stars 4 forks source link

Add Privacy Considerations, initial #102

Closed kitterma closed 2 years ago

kitterma commented 2 years ago

As discussed on the WG ML, this is a start to build on.

Scott K

jrlevine commented 2 years ago

I think this is basically fine, but I would be slightly more explicit about what the reports reveal. For aggregate reports, it can reveal patterns of communication, e.g., a burst of mail between a department of the organization and another company might reveal negotiations that are supposed to be confidential to that department. Failure reports can reveal both patterns of communication and frequently specific details about senders, recipients, and message contents, even after redaction.

kitterma commented 2 years ago

I think that makes sense. If this is a reasonable start, then I'd propose you (for whichever of you is appropriate) merge this and I'll work on that as a follow-up.

Scott K

kitterma commented 2 years ago

Will do. Might not be until Friday, due to other stuff I have to deal with.

Scott K

On August 31, 2022 12:44:10 AM UTC, John L @.> wrote: @. requested changes on this pull request.

Please expand per my comments.

alevesely commented 2 years ago

I oppose line 1729, PSDs MUST NOT include the ruf= tag. Since we allow PSDs to send messages (so much so as to detail what to do when psd=y appears on the author's domain) they should also be able to receive failure reports on the messages they send.

kitterma commented 2 years ago

This is about requesting failure reports, not sending them. There is equivalent language in RFC9091, so this is nothing new.

Scott K

On September 1, 2022 8:51:30 AM UTC, Alessandro Vesely @.***> wrote:

I oppose line 1729, PSDs MUST NOT include the ruf= tag. Since we allow PSDs to send messages (so much so as to detail what to do when psd=y appears on the author's domain) they should also be able to receive failure reports on the messages they send.

alevesely commented 2 years ago

If I cannot request record I'll never get one.

An SDO which sends messages should be able to request failure reports, but only for messages sent by itself; that is, failed authentication from a child domain without its own DMARC record MUST NOT be reported.

kitterma commented 2 years ago

This should be discussed on the working group mailing list, not here. Instead of continuing here, please reply to the email I sent to the list with this text.

Scott K

On September 1, 2022 11:27:15 AM UTC, Alessandro Vesely @.***> wrote:

If I cannot request record I'll never get one.

An SDO which sends messages should be able to request failure reports, but only for messages sent by itself; that is, failed authentication from a child domain without its own DMARC record MUST NOT be reported.

toddherr commented 2 years ago

Changes in this pull request were incorporated in the Marmot7 branch - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/104