I am self-hosting my (secondary) email and have only implemented SPF and DKIM. This works fine on a practical level for me. What would be the benefit of setting up DMARC on top?
DMARC is essentially an opt-in to strict mode. Primarily it prevents other people from forging email to look like it is coming from you. The goal of dmarc is to prevent other people from impersonating you.
Google, Microsoft, Amazon and others send me summary reports of people spoofing my domains. I have dmarc set for them to accept the email, mark it spam (presumably) and send me a report. I really should and can tell them to reject the spam completely - another setting in dmarc but haven't yet out of laziness basically.
`p=reject`, ESPECIALLY for your personal email. `p=quarantine` is really only useful if you suspect your marketing department has set up some email blaster somewhere.
Realistically spoofed address (unauthenticated email) will be treated as spam and it’ll be implicitly quarantined or rejected as such by many well-known mail receivers. You can make this an explicit “reject” by publishing DMARC policy for your domain.
For example, gmail.com treats unauthenticated email as spam implicitly, regardless of DMARC policy.
SPF allows to say “these IPs are authorised to send emails as example.com”, where DMARC allows to say “I as domain owner recommend to quarantine emails that fail SPF and DKIM”, it also allows finer alignment (ie, matching between different “from” parameters) configuration and reporting by the receivers.
Of course, with absence of DNARC policies, receivers default to some internal defaults, or may ignore the policies altogether. But at least, the big ones send DMARC reports.
MAIL FROM: foo@example.net
RCPT TO: victim@example.com
DATA
From: service@paypal.co.uk
To: victim@example.com
Subject: We are updating our Terms of Service
[...]
SPF checks whether the sending host is allowed to send e-mail from example.net (the envelope sender).
The recipient sees service@paypal.co.uk (the From address on the inner message), because most ESPs do them the great disservice of not indicating that the sender identities are not aligned.
Adding a DMARC record to a domain requires that e-mail whose inner messages claim to be from that domain must have sender alignment to the envelope sender.
The above message would pass SPF (if the spammer owns example.net and has created SPF records for themselves) but would fail DMARC (paypal.co.uk's DMARC record exists, so alignment is required, and yet example.net != paypal.co.uk, so they are not aligned). In this case their DMARC policy says to reject the message, so (if the recipient is checking DMARC) it would either be rejected outright or it would land in Spam/Quarantine rather than Inbox.
Not always. An email has a valid SPF when its return path email’s domain permits the sending server’s IP. But that email may have a forged From: header (which causes an SPF mis-alignment), and the receiving server checks the DMARC of *the From header* domain to determine how to handle that mis-alignment.
The biggest benefit I saw in a small domain was greatly reduced backscatter spam. Before someone’d randomly make up a billion emails on my domain and send “from” them, and I’d get various out of office replies, etc (catch all) - that basically never happens anymore.
> What would be the benefit of setting up DMARC on top?
Some mail providers will junk your mail if you don't have a reject/quarantine DMARC policy because you're seen as enabling the spammers so everything out of your domain must be punished.
> participants will contribute engineering resources
If it works out as planned, we will see. Apart from this, I am not overwhelmed by the claim of this project. It favors centralization and corporate circles, exactly the opposite of what the hacker ethics promotes for good reasons.
Doesn't seem very inclusive. Seems to be another layer to centralize the inbound vulns, gather intelligence and handle them in secret.
It may also turn into another source of pressure. Maybe they manage to sort out the real vulns, but then they come in as high priority to the maintainers.
Many maintainers are already exhausted from their normal work, sans AI noise. Even if they supply fixes, it still requires review.
In best case they could reduce noise but the work is still there. The industry needs to generally fund OS projects to give them the agency to handle it on their own. That's is likely best for quality. If there is still need to filter AI noise then they can add that, but not as a secret opaque thing that controls it all.
You can even shorten that. This is some corporate hollo-bollers takes-your-time-and-gives-nothing-in-return fakery-roo.
> exactly the opposite of what the hacker ethics promotes for good reasons.
Yup. Seems kind of like those zombie plants in the movie "Invasion of the
Body Snatchers" (the first remake; though the original is also great, but
it was more about communism as threat, whereas the first remake added a bit
of alien horror motifes).
> Btw this was initially coded without AI, but I've used it for the recent clean up and features
Then it makes sense to update the submission title. To me it reads as if the project was written completely without the help of AI (which might be a quality badge to some), but it is not 100% true then.
Thanks! I get your point about AI, but I think it's fair to say it's almost 100% AI free. I worked on it for ~15 months, vs 1 week now with AI. Previous results were quite similar
I am interested in hand-crafted software, and it feels deceptive when you put "no AI" in the title only to reveal there was. If you try to minimise its impact after, one wonders, if the impact was so minimal, why it was necessary. If you worked on it for 15 months without generated code, vs. 1 week with, why not finish the job? What was the purpose of introducing generated code in the last week, and could you not have taken a little more time to do it by hand given you already invested so much time into it?
There are great Open Source projects doing fine with the cathedral style, just look at Sqlite and its siblings (Fossil, …).
So I do not see a problem with Ladybirds decision, in contrary, IMHO it strengthens the human aspect of software development and puts the brakes on AI free riders
I still don't see solutions on how a normal person can become a mantainer though.
If all relevant open source projects close up their contributions, you can't enter the project anymore from an external point of view.
Almost all open-source public figures started by being interested in a project and submitting PR to it, until eventually either joining the project as core mantainer or creating a separate open source project. The path is now closed, and I don't see a way in, outside of creating a popular open source yourself
> how a normal person can become a maintainer though.
Is the goal to produce high-quality software, or is the goal to produce an apprenticeship scheme for developers who are interested in the project but not so interested that they are willing to write an email to introduce themself or otherwise engage in normal human social interactions?
Normal people will still be able to get involved if they want to, just like normal people can get jobs. You learn about the organization you’re interested in joining, you try to meet some people and introduce yourself, you gain trust and prove your worth. It can be true that a pull request once embodied some of these tasks, but it is not true that being unable to submit a request means that these tasks are no longer possible to perform. It just means you’ll have to do them differently, just like the rest of humanity does when they want to get involved in an organization.
>Normal people will still be able to get involved if they want to,
there isn't much evidence that this is happening. When you eyeball the average age of maintainers on mailing lists these days for prominent open source projects like the linux kernel, it's been steadily creeping up, to somewhere in the 50s now I'd guess. There's a complete dearth of people in their 20s or even 30s in particular in positions of responsibility, there's no next generations of leaders.
That's fatal in the long run. You need to have an apprenticeship system or something like a vocational pipeline to engage people in a structured way so that you can produce talent and also be objective and systematic. Something like a guild system you have in the DACH region where companies survive centuries, and that's not because random people write mails, it's because there's a industry wide support system and training process.
Yes but that predates AI & projects rejecting pull requests, so I would argue this is a separate unrelated phenomenon. If anything, the fact that despite accepting PRs, most projects have little new blood, means that PRs were rarely a significant pathway for future maintainers.
The path is not closed; it must be earned through trust. It has always been this way. Also, note that "pull requests" are a GitHub invention; the concept is not native to Git or most other SCM systems. Before, you would have to submit your patch by email. It would be reviewed by the "maintainer" (or BDFL), who would then accept or reject it. If your contributions are accepted several times, you may be able to earn the rank of "maintainer."
Returning to the topic at hand, the challenge for new developers is to earn trust. I bet there are ways to do so aside from the muddy swamp of GitHub's (AI) bazaar.
In this case they seem to be firmly closing the path though
> There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks. External code can of course exist under the terms of the license, but we will not treat forks or patch dumps as a review queue for upstream Ladybird.
This does raise the question on how they are going to get new maintainers. The only thing I can think of is by active outreach to people contributing to adjacent projects that are still open. But that does not seem ideal to me as that will not yield people specifically interested and caring for the project you invite them to.
They don’t even have an alpha product yet. This used to be called vaporware but I’ll give them the benefit of the doubt that something will come in the future and they’re just focusing on fixing their own crappy code.
The amusing thing is that emailed patches and a listserv aren't actually all that different from github pull requests at the end of the day. In either case you're sending some code you wrote along to a group and asking them to look over it. The only real difference is the lack of a familiar web interface that's uniform across all projects and reduces friction to near zero, but emailing a patch hardly adds much friction in practice.
I think the primary difference is that it removes some of the incentive to status seek because there's no centralized network operator tracking contributions and displaying them on your profile for others to look at.
That said, the linked post explicitly says that Ladybird won't be accepting emailed patches, reviewing changes from downstream forks, or anything else. Hopefully that's not the case since entirely closing off the project would probably be an overreaction as well as jeopardize its future.
It’s really different because there’s no public signal between the email and the project itself. You can maybe search the log and see your patch, but there’s no central identity where you can brag about it. At most you can get a notice in a CONTRIBUTORS text file, or in the copyright header.
> Why would normal people even want to become an unpaid janitor for someone else's stuff?
Social validation. Or, to be slightly more generous, sort of a compulsory way to force someone more experienced to provide some mentorship, by compelling them to review your pull requests.
That’s the point here, though. The maintainers of Ladybird don’t want to be compelled to mentor people making throwaway contributions without a commitment to the project. It’s pretty frustrating to try to mentor an absentee mentee who isn’t actually ready to learn from you.
You make a strong point. Large parts of a decision like this have less to do with what you can get from the community, but what you have person-hours available to do with it. The core team is pretty small, and a lot of these automatically coded PRs are bound to be huge. They’re taking back their own time to focus on their own project.
Not by me, but by the mods. They also changed from "full of hallucinations" to "and most citations were hallucinated". Maybe a rep from "EY Global" filed a complain ;)
Well, I think the attitude is that costs are allowed to escalate faster and more steeply than the features delivered. From that perspective, semantic versioning is a handy tool for adjusting pricing strategies. IMHO, it (versioning) only makes sense for open-source projects, where you can clearly see the actual changes made with each version upgrade. Anything else is more than a little suspicious…
While all these models are nondeterministic a feature bump is still necessary as the same input can have wildly different output on a new model. For API users being able to pin a model is a necessity.
> Opus 4.7 and later use a new tokenizer compared to previous models, contributing to their improved performance on a wide range of tasks. This new tokenizer may use up to 35% more tokens for the same fixed text.
reply