OT: Re: Younger generations preferring social media(esque) interactions.

Grant Taylor gtaylor at tnetconsulting.net
Tue Mar 23 23:34:37 UTC 2021


On 3/23/21 4:16 PM, Michael Thomas wrote:
> But they still have the originating domain's From: address.

My opinion is that messages from the mailing list should not have the 
originating domain in the From: address.  The message from the mailing 
list should be from the mailing list's domain.

No matter how you slice it, you can't get around the fact that DMARC is 
meant to defend against unauthorized using of protected domains in the 
From: header.

> Manifestly using MLM signatures as means of doing a reputation check is 
> a previously unsolved problem hence the silliness of the ARC experiment 
> which relies on the same assumption you are making here.

I do not think that any such endorsements / vouchers / etc. will ever 
work well.

I believe that the mailing list being a terminal and originating entity 
is the way forward.  We all send messages explicitly between two 
parties, ourselves and the mailing list.  Subsequently the mailing list 
originates a new / independent message explicitly between itself and a 
single recipient.

Don't try to graft "can I trust what the mailing list purports or not" 
question onto the problem.  Simplify it to "does this message (from the 
mailing list) pass current best practice security tests or not".  Notice 
how the second question is the same question that is already being posed 
about all email (presuming receiving server is doing so).

> Since Google participated in ARC, that is a pretty tacit admission 
> they don't know how to do mailing list reputation either.

IMHO ARC has at least a priming / boot strapping problem.  How does a 
receiver know if they can trust the purported information they receive 
from the sending system or not.  Simply put, it doesn't.  Hence why I 
think that ARC, as I understand it, is going to fail to thrive.

I personally believe that the mailing list manager, or better it's 
underlying SMTP server infrastructure, should uphold strict requirements 
on the incoming messages.  Only clean messages should be emitted from 
the mailing list manager.  Further, those messages should themselves 
adhere to the same high security standards.

Think about it this way:  Is there really anything (of significant 
value) different between a mailing list manager and a person (or other 
form of automation) receiving a message from a mailbox, copying and 
pasting it (work with me here) into a new message and sending it 
$NumberOfSubscribers times per message to the mailing list?  --  I don't 
think there is.

What would you want SPF / DKIM / DMARC to do if I took a message from 
you (directly vs passing through the mailing list manager) and changed 
the recipient(s) and re-sent it out to one or more other people?  -- 
I'd wager a reasonable lunch that most people would want SPF / DKIM / 
DMARC to detect and possibly thwart such forwarding.  --  So why is a 
mailing list held to different (lower) standards?

Treat the mailing list as a terminal entity that generates a new 
outbound message which happens to be substantially based on the incoming 
message's body contents.

Terminal as in all the SMTP protections for the original sender stop at 
the mailing list manager.  Likewise a new independent set of SMTP 
protections start with the new messages from the mailing list manager to 
subscribers.  Including the contents of the From: header.

> The sticking point is the From: address. If I set up a DMARC p=reject 
> policy, I should not be surprised that the receiver does what I asked 
> and trashes mailing list traffic.

As well it should.

> The point in my blog post is that after over 15 years a solution 
> is not going to be found, and trust me I have tried back in the 
> day.

IMHO:

  - Trying to pass original metadata /through/ the mailing list /and/ 
deliver it successfully is a fool's errand.
  - Treating the mailing list (or anything like it) as a terminal point 
avoids the problem.

> That we should just give up caring about mailing list traversal and 
> put the burden on MLM's to figure it out by either not changing the 
> message body/subject, or using that horrible hack of rewriting the 
> From address.

Is it /truly/ a horrible hack?

I post a morbid scenario:  $BenevolentEntity passes away, and states in 
their will and testament that $Beneficiary should receive $Something. 
--  The message did originate /from/ the benevolent entity, but the 
beneficiary heard / received the message from the $Executor, *NOT* the 
$BenevolentEntity.

> Mailing lists have been sending out resigned messages for over a decade. 
> We still have really low adoption of p=reject signing policy and at 
> least part of the problem is because of fear of mailing lists affecting 
> users.

As you can probably tell, I suspect that most of those mailing lists 
have not been configured to operate as a terminal entity.

In Microsoft domain parlance, this is the difference of trusting a 
domain vs the transitive counterpart of trusting who the domain trusts. 
IMHO the former is a relatively simple problem.  Conversely the latter 
is much more complex.

> An unsigned message is treated the same as a broken signature. That 
> doesn't help from the From: signing policy standpoint.

The original From: signature should have been validated, weighted, and 
judged /before/ it made it to the mailing list manager.  Further, the 
mailing list manager should have removed any reference to the original 
signature.  <full stop>

Optionally, the mailing list manager could have re-added / renamed 
/some/ /of/ the original metadata as alternate headers so that down 
stream systems that understood and wanted to, could extract the metadata 
and maybe do something with it.  A la. ARC.  Alas ... fool's errand.



-- 
Grant. . . .
unix || die


More information about the NANOG mailing list