[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ih] bounce notifications and archive status
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
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
> 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
> So call me backward and that i stink, but to me all that sounds
> like more and more surroundings to protect lesser and lesser
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.
Internet-history mailing list
Internet-history at elists.isoc.org