On Fri, May 26, 2023 at 9:47 AM Scott Mutter via mailop <mailop@mailop.org> wrote:
> It just seems that if people would read the documentation for SPF and > specify exactly what IP addresses are suppose to be sending email from your > domain name (I mean... if you own that domain name, shouldn't you know what > IP addresses are going to be sending legitimate mail from that domain?) > then the only all operator that should be used is -all. > > But because nobody could seem to grasp this idea another record had to be > created to act as oversight for SPF and DMARC was born. > > I fully expect that eventually another oversight record will be created to > oversee DMARC. > > And we wonder why email is in the disarray that it is. > It is often useful to understand something before being dismissive of it. When forwarding mail, there are two options: rewrite the envelope sender or not. There are a variety of pros and cons to both of them, and cases where one or the other is more prominent. Not rewriting has been the dominant form of 1:1 forwarding such as aliases and address migration, and enforcing SPF -all would break that use case. There were aborted attempts like SRS to fill the gap, but there are challenges especially with the general desire for such forwarding to be stateless. DKIM was the solution, auth that can survive being forwarded as long as the message isn't modified in transit... but it turns out, messages get modified in transit sometimes without actually changing the "contents" of the message in a user visible way. Whether that's because DKIM is based on the raw message and is not content aware, maybe that's part of it. Also, the bar is higher for implementing DKIM, and key rotation is always a fun time. Unlike SPF, DKIM was only authentication, not policy. The policy portion was attempted via ADSP, but it suffered from the point that few enough people implemented DKIM and how to handle the cases where the message was modified. DMARC attempts to put the policy of SPF and ADSP together in a simpler package. It also solves another fundamental challenge that you think is so easy, which is reporting so domains have any chance of knowing what/where/how their domain is being used. There are entire companies that exist to help domain owners figure out how they legitimately use their own domain for email. Look at the SPF include: list for many modern enterprises to see even a fraction of what that can mean. Is DMARC the best thing ever, no. Are there still issues with it? Yes. ARC was the attempt to fill the forwarding gap once and for all... but fundamental to its design is that it's only providing enough information to validate the forwarding path. It doesn't give you a nice warm and fuzzy yes/no decision. There have been arguments over whether we need a DMARC++ "no I really mean it" to not let ARC override DMARC, but the real answer to all of these things is that the receiver makes the choice. All we can do is provide as much useful information to the receiver as possible so that they can make the best choice they can. Brightline good/bad decisions are great when you can make them, and the line on that strictness has been moving over time, but email delivery is not generally a straight deliver/don't decision. Even if you think the answer is a tri-state, the real answer is how do you handle the other messages like it. How do you figure out whether you made the right decision. How do you make your system adapt over time to changes in the mail stream. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
