KasparEtter
KasparEtter on Hacker News
> SCRAM seems incredibly insecure.
Why do you think so?
> Does anyone have information on how many servers support SCRAM?
I'd be interested in this as well. :-)
For one thing, you can configure a DMARC policy without a reporting address. For another thing, you can use third-party services, such as
https://dmarc.postmarkapp.com/, to aggregate DMARC reports for you (if you're fine with the privacy implications of that).
I chose the name of the blog to mean analytic, reductionist reasoning (in contrast to associative, vague reasoning). In the meantime, I also like the following framing, which I wanted to add to the front page of the blog for some time:
https://www.cold-takes.com/minimal-trust-investigations/
This is a valid question. I'm the author of the blog and I've asked this myself in the past. The main reasons why I haven't done this so far are
- artistic freedom (regarding the form/structure, the style/tone, the interactivity),
- the process (I prefer not to have long discussions and unexpected revisions; but I must admit that I should collect actual experience in this regard),
- and the lack of attribution (part of it is certainly vanity, but I'd also like to make a living out of this at some point).
Hi layer8, thanks for the feedback! I must say that your standards for thoroughness are pretty high. Since I claimed at the very top that my article covers all aspects of modern email, I don't mind your criticism at all.
I haven't thought about the prefix chaining issue, and I'm happy to mention this in a future revision of the article. I would still argue that this is below a reasonable level of technical significance as neither conversation grouping nor message delivery is affected by it. It's more like displaying "(No subject)" instead of actually displaying no subject.
Do you have any source for what you say is an old display name convention? I've just checked the standards, and as far as I can tell after a quick glance, RFC 822 (https://datatracker.ietf.org/doc/html/rfc822#section-6) doesn't mention display names at all, and its successor RFC 2822 (https://datatracker.ietf.org/doc/html/rfc2822#section-3.4) mentions display names only with angle brackets.
PS: I have quite a few topics on my todo list, which I should add in a future revision of the article in order to live up to the claim of covering all aspects of modern email. These include MAPI, Microsoft's autodiscover mechanism, direct mailbox addressing, domain-to-domain encryption, and link rewriting in incoming mails. Some information is also no longer up to date by now.
Out of curiosity: What's the "feature" you needed; and what for?
Just to be clear: Due to email forwarding, having an SPF record isn't enough for domain authentication; you also need DKIM and DMARC. Mailbox providers want to deliver emails that people actually want to get, so not relying only on SPF records is a reasonable policy. But yes, thanks to domain authentication, we should be able to move away from IP reputation to domain reputation – at least in theory.
For me, "from first principles" is not the same as "elementary". It's just about "reductionism" and answering all (or at least most) "why" questions. Let me know if you find any gaps in the explanations, which make it impossible for you to follow. While I would claim that the first five chapters of the article/"book" are fairly elementary, it's in the nature of the topic that things get more and more advanced after that. (PS: I'm the author of the blog.)
As the title before this very sentence says, this is the outline of the whole article/"book". Since it is a web page, I link to the corresponding chapter instead of mentioning the page number. The very first chapter starts with explaining what a function is and what I mean by "one-way" and "linear". If this is beyond your attention span, then this article isn't for you. (PS: I'm the author of the article. I'm also aware that it's difficult to get an overview on mobile, so I'd suggest reading the article on a laptop or tablet.)
Hi, I'm the author of the article/"book" being discussed here. :-) I'm fully aware that the article isn't for everyone, but I can't see what's wrong with outlining the structure of a book in its introduction. Elliptic curves are covered in chapter 9 (out of 11). And while the first chapter is about linear one-way functions, it just motivates the rest of the article by explaining what we would like to build. Since I explain all the terms I use there (or link to Wikipedia for those who don't know, for example, what a "set" is), I can't see what's wrong with this either. But, as with any work, there are valid criticisms, of course:
- Is "number theory" an appropriate title? Should it be called "linear one-way functions explained from first principles"? Or "abstract algebra"? Or "math behind modern cryptography"? Maybe. But I think I made it quite clear in the introduction what the article is about. If you were looking for something else, feel free to leave again.
- Should I have introduced modular arithmetic and the groups of integers modulo some number before finite groups in the abstract? Maybe, but I also explain my reasoning behind this order in the introduction. As mentioned there, you get to these examples by scrolling just a bit.
Thank you for your feedback. I see how this can be confusing. The first chapter is explicitly about user-facing concepts, though. I explain message envelopes here:
https://explained-from-first-principles.com/email/#message-v...Right afterwards, you find an example of how and why the envelope diverges from the message header fields, followed by an in detail treatment of who removes the Bcc header field, and how Gmail recovers the Bcc recipients.
Thanks for the feedback. I summarized over a 100 RFCs in this article so I certainly hope it's factual and complete. :-)