Re: [dmarc-ietf] UNCOL and Reversing modifications from mailing lists

[Alessandro Vesely <[e-mail]>]

On Tue 23/Nov/2021 21:34:05 +0100 John Levine wrote:
> It appears that Wei Chuang  <[e-mail]> said:
>>I saw Ale's draft draft-vesely-dmarc-mlm-transform
>><https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform> in
>>the ARC list, and wanted to discuss some of the ideas. ...
> 
> Please humor me for a moment while I turn the clock way back to 1958.
> 
> Fortran and Cobol had shown that compilers worked, and people were busy
> writing compilers for lots of languages for lots of computers.  But that
> was a daunting amount of work, N languages for M computers is NxM compilers.
> 
> Mel Conway, best known for the law "Organizations, who design
> systems, are constrained to produce designs which are copies of the
> communication structures of these organizations", published a paper
> proposing a Universal Computer Oriented Language or UNCOL.  The front
> end of each compiler would translate from Fortran or whatever to UNCOL,
> and the back ends would translate from UNCOL to IBM 7070 machine code
> or whatever, reducing the work from NxM to N+M.
> 
> Work started with great enthusiasm in the early 1960s, and people
> produced UNCOLs that could handle one or two input languages, and one
> or two output machine codes, and reported great success. But they
> found that every new input language or output machine required more
> and more special cases which swamped whatever was supposed to be
> common, and UNCOL experienced heat death, was quietly shelved and forgotten.
> 
> The Open Software Foundation had an ANDF, Architecture Neutral
> Distribution Format around 1989.  They were very offended when I said it
> sounded just like UNCOL, but it died the same way.


The GNU Compiler Collection includes front ends for C, C++, Objective-C, 
Fortran, Ada, Go, and D.  It doesn't cover all languages, but it's still alive.


> This proposal is UNCOL for mailing lists. Can you come up with a demo
> that handles a few common changes that Mailman makes? Sure. How about
> if you add the slightly different changes that Sympa makes? Probably.
> What about LISTSERV and phpList and ezmlm and listproc and groups.io
> and Google Groups and Yahoo Groups and body headers and MIME footers
> and all the other things that mailing lists do?  Maybe not.


Without going beyond Mailman lists, some of them remove DKIM signatures 
altogether, so there is no chance to recover anything.

For the M computers part of the equation, we may match the metaphor by 
considering authors' domains signing practices.  Thus far, I basically see just 
two sets, those who sign rfc6376-recommended fields, and those who sign 
transport-specific fields like MIME-Version, Content-Transfer-Encoding and 
Content-Type.  The latter cannot be recovered.

This is a striking difference w.r.t. UNCOL.  There are cases where it makes no 
sense to try to cover them.  So the above proposal is not an attempt at a 
universal solution for indirect mail flows.  Rather, it says that if people 
really want to set up an authenticated indirect mail flow, there is a way to do it.


> Uh, perhaps we could focus on how to get ARC more widely adopted,
> since it has the advantage of not making any unrealistic assumptions
> about what changes lists might make.


ARC implies a reliable global reputation system, which only giant providers can 
afford.  In addition, rfc8617 doesn't even consider From: rewriting and how to 
undo it.  It is a different thing, used for different purposes, and focusing on 
it doesn't preclude recovering original signatures.


Thanks for the flashback, anyway

Best
Ale
--