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

[Wei Chuang <[e-mail]>]

On Tue, Nov 23, 2021 at 12:34 PM John Levine <[e-mail]> 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.
>
> 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.
>

Understood there is a lot of complexity in this space.  On the other hand
there doesn't seem to be a complete solution to email authentication with
regard to content modification by email forwarders.  The result is that
DMARC adoption is low despite its benefit in preventing important classes
of email impersonation.  I guess it makes sense that a lot of these are
experimental, and that hopefully one of these will emerge to be the best,
and thereby make the other techniques redundant, and clean up some of the
complexity.


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

There ought to be a thread trying to figure out why that is.  (FWIW as
mentioned in the other thread, IMO there are places where ARC makes more
sense to use, hence should figure this out)
-Wei


>
> R's,
> John
>