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
