[ih] bounce notifications and archive status

Mon Nov 11 15:13:11 PST 2019

Dave Crocker wrote in <061317a8-654f-d1f4-ca33-f0b4bf6971e0 at dcrocker.net>:

Please excuse the late reply.  I am mostly a political person who
happens to do some coding, so i initially refrained from sending
this.

 |On 11/7/2019 8:32 AM, Steffen Nurpmeso via Internet-history wrote:
 |> DMARC/DKIM/ARC etc. really trample on the email infrastructure,
 |
 |DKIM doesn't.  DMARC does.  ARC seeks to counteract the damage of DMARC 
 |in 'indirect' mail such as mailing lists.  It is new.  We'll see how 
 |well it works.

So i live in fear of being too loud.  But i must say i am not
Al Gore, i mean, how could i, i have not been in a war, let alone
at the front, but.  Maybe better it is to say i do not follow him
when he looks optimistically in the future and says that technical
improvements will solve the problems that we face.  The majority
of which we have created in the first place.  Such a statement
thus neglects the apparent fact that the more we do the more will
happen the more future improvements are necessary to actually fix
the problem.

This (my way of thinking) is maybe heavily influenced from an
impression of my early teenage years, when i watched a (not only
to me) legendary talk show appearance of the wonderful Wolfgang
Neuss, who then happened to face Richard von Weizsäcker, who was
about to run to become Germany's president, and i still hear von
Weizsäcker repeatedly say "Jetzt warten Sie es doch einmal ab"
(maybe "Now, why don't you wait and see"), with Neuss responding
"Ich habe die Zeit nicht mehr" ("I don't have the necessary
time").  (Which was then finally and actually responded with "Das
sieht man", "that can be seen".  (Neuss had taken off his false
teeth, iirc: indeed!))  Well, i dare to say that i was truly
impressed by one speech of Mr. von Weizsäcker, i have seen it live
on TV, and it was truly an impressive speech.  Wolfgang Neuss
could wait for the entire first tenure.

(I think it should be added that Mr. von Weizsäckers brother,
Mr. Carl Friedrich von Weizsäcker, was a truly impressive person,
who had been asked for becoming Germany's President by the other
side of the political road a decade earlier.  Maybe, just maybe,
he, Heisenberg and Bohr united in an anti-nuclear-bomb alliance,
but who knows.  Anyway Mr. Neuss also stated something like "the
brother is the real intellectual in that family" in the talk show,
a fact that solely survived, on Youtube, for example.  A shame it
is!)

 |This being a history list, it's worth noting that DMARC was designed to 
 |work in the very limited scenario of 'direct' mail, from large sender, 
 |with direct transit to actual recipient.  The first problem was that it 
 |got re-purposed by fiat, by a couple of large email service providers. 
 |The second, and much larger, problem is that there is a broad view in 
 |the email industry that this re-purposing is a wonderful thing.  (They 
 |don't experience the downsides, or at least not very much, so they 
 |aren't concerned about them.)

DKIM could also have been designed to enwrap protected content in
an envelope, instead of just adding yet another header line.  That
noone sees.  (The users that should be kept away from reality on
a nice and smooth trivia that is.)

There is for example RFC 1847 from October 1995, and
Multipart/Signed looks promising for the desired use case.  That
is my opinion, and if users accept entirely different things for
secure communication, i do not use them but i think there are
some, signal, and some whatever apps, then they will very well
accept such.  I think all mail readers in practical use are
capable to deal with the thing, in one way or the other.  Maybe
just like in the browser URL GUI element, with all the buttons
which someone can see in a modern browser.

Given the people who pushed this technology forward it feels odd
to me that they of all people need to hide something in the
headers that normal users will not see.  But ok, maybe separating
carrier security and user content was an understandable design
goal, given that letters only get stamps and seals on the
envelope, too.

But then why do the Yahoo people not ask their users, look into
some List-Id: field for example, and if there is one, ask their
users for confirmation for a specific list.  It is too error
prone, not automatic, and requires too much logic i guess.

I do not go with the "We'll see how well it works" of yours.  This
is the industry pushing through a standard that tramples on the
infrastructure half a decade or longer since "the war on spam was
won", according to some (ex- iirc) Google employee.

In the last weeks a tremendous number of mailing-lists have been
converted to work regardless of the current state of affairs.  For
example the GNU project managed ones have all been converted.  So
this is how well it works in practice!  And with ARC everybody
along the mail path has to apply his or her own signature?!

And then things like Autocrypt are added upon that, which ship the
entire public key of a person with each and every mail that is
sent, just in case someone may possibly ever sent an encrypted
message to someone else.  We are talking about many kilobytes of
header data which is sent along with each and every message at
that time.

So call me backward and that i stink, but to me all that sounds
like more and more surroundings to protect lesser and lesser
content.

All those standards, all the necessity for the increased
bandwidth, including increased demands of electrical power, and
all the trouble in the end-user infrastructure to which i count
MLs could have been avoided if a signed envelope would have had
been wrapped around the to-be-protected content.

 |There is an interesting third problem, namely that it is trivial to work 
 |around the protection that DMARC is seen as providing.  The protection 
 |stems from the view -- and apparently empirical evidence in support of 
 |the view... for now -- that phishers will use the domain name of 
 |organization they claim to be representing, both in the message body and 
 |the author From: field.  However almost no use actually sees the author 
 | From field domain name anymore; even better, it doesn't seem to matter 
 |if they do.  The real dangerous part of phishing is in the body and 
 |DMARC doesn't (and can't) do anything about that.
 |
 |Most problems about DKIM come from misunderstanding what it is supposed 
 |to do.  For the most part, it does what it is supposed to, pretty well.

You can use it to verify that the message has been sent exactly as
you have received it, at least the protected fields.  And this
happens transparently to users.
But is this really a value by itself, i would have asked.
Especially given that many people have faced signed or even
encrypted messages in their life before, may it be S/MIME or
OpenPGP, it seems the former is more often added automatically on
some gateways by companies.

Not that the MUA i maintain works nicely with that, let alone with
deep hierarchies and let totally aside a nice user experience.
But these standards are old and established and sometimes even
enforced on company-wide levels.  I believe people would very well
have accepted another envelope around that envelope, and would
have appreciated the possibility to get rid of that in their
visual user interface experience with a click (or two).
It just had to be done like that.  In "A Research UNIX Reader" we
can read on MAIL "Old UNIX hands groan at the monstrous headers",
and if that is not irony sarcasm is applicable.  (I am guilty of
a fat program manual myself.)

 |> especially mailing-lists.  Many have chosen to remove Subject:
 |> line tags, or only do the From: rewriting the way we see here.
 |> The nice outcome of the approach you have chosen is that the
 |> original is fully retained, and that (therefore) future people who
 |> search archives will actually know who was actually speaking,
 |> since the original mail address should be available in a way that
 |> survives ML archiving, which i deem important.  Thanks.
 |
 |Mailing lists involve the /delivery/ of an original message and the 
 |/posting/ of a new one.  In terms of user experience, there is the sense 
 |of a single posting from the original author, but that has never been 
 |the architectural reality.

You look forward to ARC seal chains, which requires that all
mailing-list operators upgrade their infrastructure.  Those which
do not are left behind.  This is especially delicate given that
many many projects in the free software world stopped using
mailing-lists, moved to RSS feeds and/or gitXY issue trackers,
i.e. much, much more bloated environments.

In my opinion this direction is a pity, since with MLs i can work
in a small terminal program, use my normal editor, can have my own
archive which i can organize and manage just the way i want,
etc. etc.  I can today look into threads that happened thirty and
more years ago, and this will absolutely not be true with anything
web forum etc. alike.  None of that.

 |Hence, mailing list software can 'legally' do whatever it wants to a 
 |message.

This has always been the case, of course.
Yes.  But you could use S/MIME or OpenPGP since decades if this
would concern you.  Some mailing-lists even do this on a per-list
level, the private oss-security for example does it like this,
i think.

 |> I for one would have preferred if said standards would have done
 |> it the very way*you*  are doing it now, placing protected content
 |> as a whole in a new envelope, maybe even using the CMS standard as
 |> a content envelope, a.k.a. S/MIME-alike.  An another list i wrote
 |
 |Each of the workarounds for dealing with the breakage caused by DMARC 
 |has some benefits and some noticeable detriments.  None seems to be far 
 |better than the others.  The encapsulation method really messes up doing 
 |a reply.  Eg, I had to do a hack in order to include the text of your 
 |message in this reply.

But this really is a bad MUA then.  Multipart mails etc. exist for
a quarter of a century.  I must admit the MIME of mine only works
well for the first subpart, i.e., a flat thing, yet.  And the
OpenSSL library S/MIME verification only works for such a single
flat level, too (you need to separate them and feed each one in
separately, of course).  I never used other MUAs let alone
graphical ones, but i have seen Apple Mail show some icons for
attachments.  This is just bad, right.  Users need to be able to
easily look into things, and for multipart/signed etc. things are
pretty clear.

 |>    RFC 4871 on DKIM says at least
 |> 
 |>       A common practice among systems that are primarily
 |>       redistributors of mail is to add a Sender header field to the
 |>       message, to identify the address being used to sign the
 |>       message.  This practice will remove any preexisting Sender
 |>       header field as required by [RFC2822].  The forwarder applies
 |>       a new DKIM-Signature header field with the signature, public
 |>       key, and related information of the forwarder.
 |
 |In case this is otherwise missed, note that the above text is not normat\
 |ive.

I solely provided the two snippets of the DKIM and DMARC RFCs to
demonstrate the spirit and overall think approach their authors
seem to live in.

 |The simple, semantic reality about DKIM is that it embeds whatever 
 |identifier it wishes (into the d= parameter of its header field).
 |
 |DKIM is not 'authenticating' a message, never mind not authenticating 
 |its content or author or, really, anything else, other than the validity 
 |of the d= domain name being used.
 |
 |The purpose of DKIM is to reliably and validly associate a domain name 
 |with a mail stream, so that filtering engines (at the receive side) have 
 |a clean, noise-free information source, for developing a reputation 
 |assessment about messages using that domain name.
 |
 |>    whereas the Yahoo! only RFC 7489 says
 |
 |DMARC has a very different task, namely to ensure that the author From: 
 |field domain name is only used when authorized and then offer a request 
 |to receivers about disposition of any message that has that domain name 
 |in that field but isn't authorized to use it.
 |
 |>    They break a field already present in RFC 822 from 1982.
 |>    ...
 |>    the job is done, maybe they got a bonus.  Sounds bitter...
 |
 |Only DMARC adds a semantic to the author From: field.

My ML currently strips DKIM fields.  I do track the OpenDKIM repo
for some years now, but never stepped ahead and started using it.
The Mailman ML manager basically offers DKIM stripping to get over
the DMARC problem.  I do not know.

Mr. Crocker.

 |d/
 |-- 
 |Dave Crocker
 |Brandenburg InternetWorking
 |bbiw.net
 --End of <061317a8-654f-d1f4-ca33-f0b4bf6971e0 at dcrocker.net>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history