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

Wed Mar 24 00:04:57 UTC 2021

On 3/23/21 4:34 PM, Grant Taylor via NANOG wrote:
> 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.

This has the unfortunate downside of teaching people not to pay 
attention to the From: domain. For mailing lists maybe that's an OK 
tradeoff, but it definitely not a good thing overall. I noticed that the 
IETF list does From re-writing for DMARC domains that are p=reject.

>
> 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).

That is the essence of the problem and always has been. If somebody 
resigns an altered message, does that change my decision of what to do 
in the face of DMARC p=reject? That means I need to know something about 
that mailing list if the answer is yes. Best practices have nothing to 
do with it. It is all about reputation. A message mangler can be Lawful 
Evil, after all.

>
>> 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 went back to the DMARC mailing list wondering what magic that ARC 
provided that we didn't think about 15 years ago only to be disappointed 
that the answer was "none". I really don't understand how this got past 
IESG muster, but it was an experiment.

>
> 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.

Yes, I think that's a given and feeds into their reputation.

>
> 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.

 From the standpoint of the receiving domain, it has no clue who mangled 
the original message. The only thing they know is that there isn't a 
valid signature from the originating domain and what the originating 
domain's advice is for that situation.

>
> 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?

This is the so-called replay attack. It's nonsense. Email has always 
been essentially multicast.

>> 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>

Signatures shouldn't be removed: a broken signature is identical to a 
missing signature security-wise, but broken signatures can be used for 
forensics. I, for example, could reconstruct a very large percentage of 
mailing list messages to unbreak signatures. It was to the point that it 
was quite tempting to use that approach to deal with MLM traversal.

Mike