[ih] bounce notifications and archive status

[Dave Crocker via Internet-history]

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

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

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.



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


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


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


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

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history