Doug,
On Mon 03/May/2021 14:25:54 +0200 Douglas Foster wrote:
No. I can't talk straight.
I meant to say that we need N unique (and valid) smtp TO addresses, so that an
attacker cannot send a single email address and wait for an rua report to know
where it lands.
A simple positive DSN can confirm email addresses better than elaborate DKIM
design. To confirm delivery is usually not considered a privacy violation,
given that the sender learned the recipient's address. Privacy violation
occurs when senders track the recipient's opening of each message, which is
typically obtained by inserting unique images in HTML messages.
Avoiding to reveal final email addresses requires various precautions, which,
if I understood what Laura wrote, can be put into effect on forwarding. I
would *add to the Privacy Consideration section* that, due to reporting,
changing the envelope from is not enough, From: has to be changed as well in
order to forward without revealing the final address.
Valid addresses are needed to hinder usage of bogus addresses to defeat the
test.
However, the aggregate report counts the number of messages, not the number of
recipients.
Requiring aggregation on DKIM selector follows the sane logic to hinder
tracking an individual.
Using DKIM selectors for tracking will also put a huge load on DNS if
implemented at scale, so it needs to be obstructed.
I think mass mailers have better means to track recipients. But I agree that
to generate, publish, retrieve and report million DKIM selectors would be
somewhat impractical. Putting a limit on aggregate report size (even if not
requested by the report consumer) can prevent excessive disaggregation.
It is also not enough to null the DKIM selector; the null aggregate still needs
to meet the N recipient requirement. If not, then additional selectors need to
be nulled or the nulled-selector messages need to be completely excluded from
the report.
Most reports I send have <count>1</count>, given my volumes. Yet, by
aggregating many of them one could reach significant sums.
If the To domain is included in the report, the aggregation rules should still
apply. If they cannot be met, then the To domain must be nulled out or the
report not sent.
This is a recipient's choice. If I wanted to stay anonymous, I'd use a domain
like gmail.com rather than tana.it.
I favor making To domain an option which the owner domain requests and the
sending domain chooses to follow or ignore. This provides upward
compatibility. The request for this data element keeps coming up. The
protocol can allow flexibility so that the participants make the final decision.
It is already optional in the I-D. (Not that I find it useful.)
I asked previously whether report senders do any filtering based on domain
reputation, and the answer was "probably not". I think the specification
should encourage recipients to omit reporting to sources with negative
reputations, as their motive for report collection may be unrelated to
self-identification.
Some receivers cannot report mail discarded during early SMTP phases at all,
for example because the DMARC filter is run after the end of data.
I want the protocol to address all of Laura's concerns. I think ensuring
aggregation is the best way to do this.
DMARC cannot address those concerns directly, IMHO. However, it can note under
what conditions aggregate reporting doesn't violate privacy. It is especially
useful to note that, in most cases, aggregate reports do NOT constitute a
privacy risk.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
