On Sat, May 8, 2021 at 2:12 PM Murray S. Kucherawy
wrote:
> On Sat, May 8, 2021 at 7:31 AM Alessandro Vesely wrote:
>
>> > - #62 makes reporting mandatory, which leaves the mail receiver with no
>> > means to mitigate the privacy threat.
>>
>
> #62 (assuming it has WG consensus) makes it clear w
It appears that Murray S. Kucherawy said:
>Personally, I think mandatory reporting wouldn't survive Last Call or IESG
>Evaluation. Even if it did, there's no mechanism to enforce it ...
Indeed. I check DMARC on all my incoming mail, but it is unlikely
that I will ever get around to sending rep
On Sat, May 8, 2021 at 7:31 AM Alessandro Vesely wrote:
> > - #62 makes reporting mandatory, which leaves the mail receiver with no
> > means to mitigate the privacy threat.
>
#62 (assuming it has WG consensus) makes it clear we really want reporting
to be mandatory, but at a glance I don't see
On Sat 08/May/2021 14:29:11 +0200 Matthäus Wander wrote:
Laura Atkins wrote on 2021-05-08 13:59:
The current system does not allow for reconstruction of the forwarding
pathway.
I agree in that envelope_to makes it easier for reconstruction of the
pathway, but disagree otherwise. DMARC reporti
Laura Atkins wrote on 2021-05-08 13:59:
>> What happens to the existing "envelope_to"?
>
> The proposal objected to was adding a new piece of information to pass
> along information that would allow reconstruction of a forwarding pathway.
>
> Case 1: Identify mail flows along forwarders.
Th
> On 8 May 2021, at 10:50, Matthäus Wander
> wrote:
>
> Barry Leiba wrote on 2021-05-06 16:16:
>> Chair weighing in, as chair:
>>
>> We're divided in the sense that there are some who want to add this
>> information, but as I see it the rough consensus is not divided:
>> - This is extra inform
Barry Leiba wrote on 2021-05-06 16:16:
> Chair weighing in, as chair:
>
> We're divided in the sense that there are some who want to add this
> information, but as I see it the rough consensus is not divided:
> - This is extra information that's being proposed... so, a new
> feature. That require
st
>
> > -Original Message-
> > From: dmarc On Behalf Of Alessandro Vesely
> > Sent: Tuesday, May 4, 2021 5:07 AM
> > To: dmarc@ietf.org; Douglas Foster
> >
> > Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
> >
> > Doug,
: dmarc@ietf.org; Douglas Foster
>
> Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
>
> 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 (
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
> On 4 May 2021, at 03:49, John Levine wrote:
>
> It appears that Murray S. Kucherawy said:
>> Is that enough? If I control a domain, I can make up any number of
>> apparently-valid envelope addresses I want.
>>
>> Using DKIM selectors for tracking will also put a huge load on DNS if
>>> im
It appears that Murray S. Kucherawy said:
>Is that enough? If I control a domain, I can make up any number of
>apparently-valid envelope addresses I want.
>
>Using DKIM selectors for tracking will also put a huge load on DNS if
>> implemented at scale [...]
Hi. Passive-aggressive mail operator
I am open to improvements. Laura's original point was that an RUA should
not facilitate stalking. My inference from that is that it should not
allow reporting on messages to an individual recipient.
One of those attacks would be to use a unique domain to send a single email
to a single recipien
On Mon, May 3, 2021 at 5:26 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> 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.
>
> Valid addresses are ne
John Levine wrote on 2021-05-02 22:30:
> It appears that Matthäus Wander said:
>> envelope_to allows you to automatically correlate these reports and
>> reconstruct the forwarding path. This helps to identify the culprit who
>> is breaking DKIM signatures, especially with longer forwarding chains.
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.
Valid addresses are needed to hinder usage of bogus addresses to defeat the
test.
Requiring ag
In the bulk email space most messages are sent with a unique 5321.from address
(VERP). Are you suggesting that no DMARC reports should be sent for commercial
bulk mail?
laura
> On 3 May 2021, at 12:21, Douglas Foster
> wrote:
>
> To address Laura's concerns about individual targeting, the
To address Laura's concerns about individual targeting, the reporting needs
to ensure a minimum level of aggregation on all reports.
This starts with MailFrom. If less than N unique recipient addresses are
included, the report should not be sent at all
If a DKIM selector occurs on less than N u
> On 3 May 2021, at 07:27, Hans-Martin Mosner wrote:
>
> Am 02.05.21 um 22:30 schrieb John Levine:
>> It appears that Matthäus Wander said:
>>> envelope_to allows you to automatically correlate these reports and
>>> reconstruct the forwarding path. This helps to identify the culprit who
>>> is
Am 02.05.21 um 22:30 schrieb John Levine:
> It appears that Matthäus Wander said:
>> envelope_to allows you to automatically correlate these reports and
>> reconstruct the forwarding path. This helps to identify the culprit who
>> is breaking DKIM signatures, especially with longer forwarding chai
John, your logic is circular. The only way that Matthäus can know if he
objects to what you are doing with his message is to monitor what you are
doing with his message.
It is also irrelevant. Data privacy is pretty thoroughly lost,
notwithstanding GDMR's efforts to fight the system. It seems s
It appears that Matthäus Wander said:
>envelope_to allows you to automatically correlate these reports and
>reconstruct the forwarding path. This helps to identify the culprit who
>is breaking DKIM signatures, especially with longer forwarding chains.
>Without envelope_to, reconstructing the mail
I see the following use cases for the envelope_to.
Case 1: Identify mail flows along forwarders.
With an increased adoption of DMARC reporting, we will be getting
reports like this:
Report from $ForwarderOrg:
HeaderFrom=$OriginDomain + EnvFrom=$OriginDomain --> $ForwarderOrg
Report from $Recipie
On Wed, Apr 28, 2021 at 9:22 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I understand that additional detail might make the reporting effort
> unacceptable to the big organizations that are creating them, and this
> reason alone may prevent alternatives.
>
> It seems that the
I understand that additional detail might make the reporting effort
unacceptable to the big organizations that are creating them, and this
reason alone may prevent alternatives.
It seems that the potential uses for reports are:
- Identifying and fixing my own infrastructure problems
- Celebrating
C WG
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
Apologies to Matt; I sent this originally only to him when I meant to send it
to the list...
On Wed, Apr 28, 2021 at 4:27 AM Matthäus Wander
mailto:40wander.scie...@dmarc.ietf.org>>
wrote:
Hello everyone,
I'm n
Apologies to Matt; I sent this originally only to him when I meant to send
it to the list...
On Wed, Apr 28, 2021 at 4:27 AM Matthäus Wander wrote:
> Hello everyone,
>
> I'm new to the party. I'd like to bring in some practical experience of
> working with DMARC rua reports.
>
> #23 introduces "
Hello everyone,
I'm new to the party. I'd like to bring in some practical experience of
working with DMARC rua reports.
#23 introduces "receiving_domains" in the report metadata, justified by
large infrastructures that host a large number of domains (e.g. Google).
I think, this information would
28 matches
Mail list logo
