From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: <dcrocker@bbiw.net>, "IETF DMARC WG" <dmarc@ietf.org>
Date: Mon, 03 Aug 2020 00:43:56 GMT
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=98fb3daf40474046a88018f8756fb733
In-Reply-To: <fa39426a-c14b-493c-85f2-58a682461c2d@dcrocker.net>
References: <20200802165756.3892C1DC82FD@ary.qy>
 <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com>
 <CAL0qLwYFoGHL13tLOnbgf97qtgLFDo4AmutZdQvMVsuX56Vz0Q@mail.gmail.com>
 <fa39426a-c14b-493c-85f2-58a682461c2d@dcrocker.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/FQc0Wupv0DKhYAu3ViI22_Q73as>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header
 domains
Precedence: list

This is a multipart message in MIME format.

--98fb3daf40474046a88018f8756fb733
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Murray took server too literally.   I have expressed before that a system c=
ould do a sender authentication lookup on List-ID as easily as on From.   I=
n this respect, it is similar to Dave's proposal, without the added complex=
ity of additional identifiers.   So think "Registerd List-ID plus DKIM sign=
ature (or SPF, but DKIM seems both sufficient and preferable.)

I am not sure what "Internet Scale" means to you.   Most of the major recip=
ients have bulk mailer registration systems.   It does not guarantee whitel=
isting, but it tends to produce that effect.   I have had occasion to regis=
ter with most of them.   So "does not scale" is not obvious to me.

Even more to the point, check out this link:
https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing=
-relevance-performance-through-vto 

Verizon appears to be offering a service (probably for extra cost) which is=
 based on:
(a) a well-defined mail stream from a known sender, and 
(b) a mailbox user identifying that mail stream as subscribed, and therefor=
e desirable.

It appears that the target senders are retailers who want to ensure that th=
eir sale announcements are read before the sale is over.   It is an "Intern=
et scale" application of the type of registration I was suggesting:   Well-=
identified senders, coupled with end-user endorsement, receive preferred tr=
eatment.

As to the transparency question, it should be clear that there will be no s=
imple solution to the ML problem.  As long as mailing lists appear identica=
l to a malicious spoofer, their only protection is their own sterling reput=
ation.   But the only way to establish an acceptable reputation is to eithe=
r register with the receiver directly, or register with the sender in a way=
 that the receiver will honor.    Your proposal does nothing to distinguish=
 mailing lists from malicious spoofers, so it does nothing to solve the pro=
blem.   Mailing lists either need to send using the ML domain as the From a=
ddress, not modify the message, or establish a credible reputation.   There=
 are no other possibilities on this side of FantasyLand.

DF 

----------------------------------------
From: Dave Crocker <dhc@dcrocker.net>
Sent: 8/2/20 5:29 PM
To: IETF DMARC WG <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header do=
mains
On 8/2/2020 2:22 PM, Murray S. Kucherawy wrote:
> Ignoring for the moment the problems of scale with any "register your
> lists" solution, I don't think users can reasonably be expected to
> keep such a registration current if, say, the servers were to move. 
> Such a migration would no longer be transparent, as it is today.

+1

When someone proposes a scheme, it will help for them to list who the
relevant actors must be and what they must do and then deal with the
question of scaling.  That is, how will it be possible for this to work
at Internet scale?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



--98fb3daf40474046a88018f8756fb733
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-family: arial; font-size: 12px;"><div>Murray took server=
 too literally. &nbsp; I have expressed before that a system could do a sen=
der authentication lookup on List-ID as easily as on From. &nbsp; In this r=
espect, it is similar to Dave's proposal, without the added complexity of a=
dditional identifiers. &nbsp; So think "Registerd List-ID plus DKIM signatu=
re (or SPF, but DKIM seems both sufficient and preferable.)</div><div><br><=
/div><div>I am not sure what "Internet Scale" means to you. &nbsp; Most of =
the major recipients have bulk mailer registration systems. &nbsp; It does =
not guarantee whitelisting, but it tends to produce that effect. &nbsp; I h=
ave had occasion to register with most of them. &nbsp; So "does not scale" =
is not obvious to me.</div><div><br></div><div>Even more to the point, chec=
k out this link:</div><div><a href=3D"https://blog.postmaster.verizonmedia.=
com/post/616023179026202624/increasing-relevance-performance-through-vto" t=
arget=3D"_blank">https://blog.postmaster.verizonmedia.com/post/616023179026=
202624/increasing-relevance-performance-through-vto</a>&nbsp;</div><div><br=
></div><div>Verizon appears to be offering a service (probably for extra co=
st) which is based on:</div><div>(a) a well-defined mail stream from a know=
n sender, and&nbsp;</div><div>(b) a mailbox user identifying that mail stre=
am as subscribed, and therefore desirable.</div><div><br></div><div>It appe=
ars that the target senders are retailers who want to ensure that their sal=
e announcements are read before the sale is over. &nbsp; It is an "Internet=
 scale" application of the type of registration I was suggesting: &nbsp; We=
ll-identified senders, coupled with end-user endorsement, receive preferred=
 treatment.</div><div><br></div><div>As to the transparency question, it sh=
ould be clear that there will be no simple solution to the ML problem. &nbs=
p;As long as mailing lists appear identical to a malicious spoofer, their o=
nly protection is their own sterling reputation. &nbsp; But the only way to=
 establish an acceptable reputation is to either register with the receiver=
 directly, or register with the sender in a way that the receiver will hono=
r. &nbsp; &nbsp;Your proposal does nothing to distinguish mailing lists fro=
m malicious spoofers, so it does nothing to solve the problem. &nbsp; Maili=
ng lists either need to send using the ML domain as the From address, not m=
odify the message, or establish a credible reputation. &nbsp; There are no =
other possibilities on this side of FantasyLand.</div><div><br></div><div>D=
F&nbsp;</div><div><br></div><div><br></div><div contenteditable=3D"false"><=
/div><div><br></div><hr id=3D"previousmessagehr"><div><span><strong>From</s=
trong>: Dave Crocker &lt;dhc@dcrocker.net&gt;<br><strong>Sent</strong>: 8/2=
/20 5:29 PM<br><strong>To</strong>: IETF DMARC WG &lt;dmarc@ietf.org&gt;<br=
><strong>Subject</strong>: Re: [dmarc-ietf] non-mailing list use case for d=
iffering header domains</span></div><div>On 8/2/2020 2:22 PM, Murray S. Kuc=
herawy wrote:</div><div>&gt; Ignoring for the moment the problems of scale =
with any "register your</div><div>&gt; lists" solution, I don't think users=
 can reasonably be expected to</div><div>&gt; keep such a registration curr=
ent if, say, the servers were to move.&nbsp;</div><div>&gt; Such a migratio=
n would no longer be transparent, as it is today.</div><div><br></div><div>=
+1</div><div><br></div><div>When someone proposes a scheme, it will help fo=
r them to list who the</div><div>relevant actors must be and what they must=
 do and then deal with the</div><div>question of scaling.&nbsp; That is, ho=
w will it be possible for this to work</div><div>at Internet scale?</div><d=
iv><br></div><div>d/</div><div><br></div><div>--</div><div>Dave Crocker</di=
v><div>Brandenburg InternetWorking</div><div>bbiw.net</div><div><br></div><=
div>_______________________________________________</div><div>dmarc mailing=
 list</div><div>dmarc@ietf.org</div><div><a href=3D"https://www.ietf.org/ma=
ilman/listinfo/dmarc" target=3D"_blank">https://www.ietf.org/mailman/listin=
fo/dmarc</a></div></div>

--98fb3daf40474046a88018f8756fb733--