[ih] bounce notifications and archive status

Wed Nov 13 10:28:13 PST 2019

Dave Crocker wrote in <a5b47832-f85e-9b18-f04b-34e1c56e3075 at dcrocker.net>:
 |On 11/11/2019 3:13 PM, Steffen Nurpmeso via Internet-history wrote:
 |> 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.)
 |
 |1. Designs always "could have been" something different from what they 
 |are.  Hence it is important to understand the goals and boundaries that 

Of course.  This is why i argue lame, since the facts have already
caused changes to be applied, with a large rush of those in the
past weeks.  But ongoing for years, the TUHS list had a long
thread in the past, for example.

 |were set for the design.  If there is disagreement with the goals or 
 |boundaries, then argue carefully about them, remembering that in a 
 |standards venue, quite a few people spent quite a long time settling on 
 |the design that was chosen.  In the case of work like DKIM, this 
 |actually involved 3 previous generations of work, including significant 
 |deployment experience.
 |
 |2. In terms of how you have raised it here, 'wrapping' is essentially a 
 |minor, syntactic issue.  In semantic terms, DKIM 'covers' a portion of 
 |the message and thereby has a kind of logical wrapping.  If you have 
 |some more interesting intent in mind, you didn't state it.  So I can't 
 |comment on it.

I personally am also a fan of flat parsers, and am at odds with
the MUA i maintain because of its recursive approach (being the
workhorse, still).

But DKIM has to go over individual parts of the entire message (in
practice), so the implementations cannot be as simple as "we dig
anything until the first all-empty line, and do not care for
actual content, the rest we do not care about at all".
That is, i claim that putting it all in an envelope would not
increase the cost of computation compared to status quo.

 |> There is for example RFC 1847 from October 1995, and
 |> Multipart/Signed looks promising for the desired use case.  That
 |
 |That work was part of an effort concerned with authenticating messages, 
 |seeking a common packaging mechanism to be in common between .  DKIM 
 |does not have that intent.
 |
 |Also, the MIME approach only covered the message body, and not the header.

There is (of course: since you are very active and interested in
IETF matters for a very long time i would always imply that you
have seen documents at least by glancing over them, or even doing
a thorough parse) draft-melnikov-smime-header-signing for a long
time, and that in turn is lingering for much too long on the TODO
list of my MUA (in source repo only).

It seems i am at odds again, however, since simply enwrapping
anything within a signed envelope would have been the right
approach also there.  To me, much better than having an encrypted
message in the MBOX which decrypts to multipart/mixed with one
part being text/rfc822-headers, and the other being the message.
Why not take the entire message/rfc822 that it is, and put it in
an envelope.

That is just how it is however.  On the other hand, adding one
more good RFC on top of a lot of other not so good ones to move an
old idea / standard to be the best possible solution has been
seen, so we now have DNS over TCP/TLS and/or DTLS (i for one
dislike DNS/HTTPS unless the HTTPS connection is already open, in
a browser for example), in conjunction with TLSA etc. etc.
There is direct SMTPS.

IDNA is still around, which always frustrated me.  I never
understood why limits were not raised at that time, in order to
let time and software updates overcome restrictions for some
native non-english domains.  Just like with SMTP, which simply --
poof! -- quadrupled all limits.  (But without the poof!, of
course.  But domains names can be quite long even with the full
four byte UTF-8 even without.  Anyway: much better than
introducing incompatibilities in later versions because IDNA
issues were not fully understood initially.)

 |Lastly, I suspect you are thinking in terms of information to be 
 |provided to recipients, to aid in their evaluation of a message. Whereas 
 |DKIM, et al, seek to provide input to the recieving filtering engine. 
 |Plus, input to recipients seems rarely, if ever, to be efficacious.

Yes, i suspected that the envelope approach was not taken in order
to keep users away from the irritating, frustrating, off-topic
administrative surroundings.
This is why i referred to modern web browsers which show some
icons near the visited URL, which seems to be the end-result of
multiple decades of experience in how information shall be
presented to users, i think.

To me it is a matter of the (G)UI only, really.  Someone
complained in this thread that the message/rfc822 message
enwrapping was not displayed initially, which then lead to Mailman
reconfiguration.  Given that message/rfc822 is a mail message, the
core of the protocol all this is about, it makes me wonder.

 |> 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.
 |
 |It isn't about hiding; it is about ensuring a degree of interoperability 
 |without creating distracting effects on users.  A serious effect of 
 |encapsulating a message inside a MIME body part is that it is less 
 |accessible to the end user.  (I've just had a reminder of the reality of 
 |this, over the weekend...)

And that really is the funny part, to me.
(And also the disappointing, looking at my own thing.)

 |> I do not go with the "We'll see how well it works" of yours.  This
 |
 |It's not mine.  I was noting that it seems to describe the view of some 
 |others.
 |
 |> 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.
 |
 |It hasn't been won.  It is a continuing and serious threat.  Note M3AAWG 
 |and APWG.

Hm.  Ok.  Well, since i could only belong to the "least expensive
and most popular level of membership" i am put off a little.  (I
know that from Unicode/CDLR where Google, Microsoft and Apple
employees count a power of two more than my voice.  But they get
paid for translating XY/meat-balls to XY/Fleischbällchen instead
of XY/"Klops", so, well.  Little clod is a Klops.  Basta.  Other
than that there are fully and semi official institutions for good
German, so i do not understand why they are not asked and charged
for doing these things, i guess it would be cheaper, in the end.)

If i recall correctly the essay was about that because of the big
data spam mails can be classified as such very fast and reliably
(like same checksums appear so-and-so often, in different parts of
the world, add on that user classification as "spam" of
a checksum).

 |> 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.
 |
 |A concern that increasingly complexity is providing far less benefit 
 |than people assume isn't backward.  It's a valid concern, IMO.
 |
 |>|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.
 |
 |Exactly so.  And nicely said.
 |
 |But that's actually a secondary benefit.  The primary benefit is have a 
 |domain name associated with the message that is 'noise-free'; it hasn't 
 |been used by anyone except authorized services.

You could always look at the From: (or Sender:, if that contains
multiple addresses) of the signed message/rfc822.  That would be
doable, at least.  All the DNS surroundings are exactly the same.
For verification purposes, all the normalization etc. has to be
done, just the very same (iirc).

 |> 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.
 |
 |They have a completely different goal from DKIM.

I do not really agree with that.  I seem to know that S/MIME is
used by companies as a transparent signing service of outgoing
mails, for example.  So with protected headers you (can) get the
very same thing, for message as well as From: host verification.
It just has to be done.

But as of today complains are futile, since DKIM/DMARC/ARC are
standardized and cause changes all along the infrastructure.
Mailing lists either use From: rewriting which could cause
archives to be mutilated, since the real address is moved to
Reply-To: that is often not archived, or have to stop tagging
Subject: lines and injecting (headers and) footers, which
i personally love to see (especially the Subject: tags).
I do not know whether MUAs use the standardized List-XY: headers
to give some UI feedback, which could be a little workaround.
(Especially in pagers, in summary views some can give a little
hint.  Mine requires some configuration for that, though.)

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