This is also talked about in the article, is your experience to the contrary?
Which is why I’d consider it “hard” to run my own mail server. The complexity of running a daemon with a config file isn’t the issue, nor is it that any individual task of SPF/DKIM/etc is complex. It’s that I generally want to put 0% of my time into making sure my emails are being received, and I’m receiving other peoples’ emails.
If you have your own ASN and your information is registered with reputable parties in lawful countries, you might not have much to worry about. If you are using a cheap cloud VPS service whose network is registered to a Romanian holding company, nobody will deliver your mail.
The problem with this idea is that spammers don't use their own computer, they borrow other people's computers to send the spam. It also heavily penalizes people who legitimately need to send bulk email.
Aka spammers.
These have a lot of iffy issues.
* Since they're going to be generated by the ecommerce service, it may not be running on the same server or IP block as your main mail infrastructure, so you might have to specially configure around that.
* The content-- hundreds of messages a day, at seemingly scattershot recipients and highly templated-- screams spammy nto the wrong algorithm.
Yeah, there's services like Mandrill, but the whole ecosystem feels broken. It's not serving mailers. It's not serving the recipients very well. It seems designed to please a small, delicate, vocal audience. The people so upset at the prospect of false negatives (spam in the inbox) that they rally around providers who are prone to aggressive false positives. Who are these people and what makes them tick?
I could see this backlash in a situation where it's high risk or cost, but users can manage their own filters in any half-decent mail system, and frankly, clicking through a few pieces of spam a week is not a big deal-- arguably far less a hassle than spending an hour on the phone to get a tracking number that a spam filer ate.
I work for an email marketing provider (opinions my own, obviously), and I was extremely surprised how many people genuinely want to receive lots of commercial bulk marketing email. And by "want to" I don't mean "don't mark as spam", I mean "continually sign up for different marketing newsletters, and consistently use links in newsletters/marketing emails to make purchases from multiple companies". It's an alien phenomenon to me, and it may be a minority of bulk email, but it definitely is useful to a lot of people. Maybe it's their equivalent of coupon-clipping-based shopping, or maybe they just like learning about things to buy in that format? I have no idea.
That aside, the last thing an email marketing platform wants to do is send spam. Every time someone marks an email such a provider sends as spam, the reputation of their sending addresses is damaged, and therefore their ability to deliver mail to aforementioned people who want to receive them (and therefore the ability of the marketing platform to make money by facilitating that kind of desired email) is jeopardized.
TL;dr there's bulk marketing email and then there's spam, and surprisingly little overlap (and overlapping incentives) between the people who send each.
I have a couple of broad categories for these filters like car stuff, computer stuff, other-hobby-related-stuff and of course clothing, and just take a look at the appropriate one when I need or want something. Takes virtually no time, and saves a lot of money.
Of course I'm not gonna lie, I do end up buying things that I wouldn't have bought otherwise by doing this. But some of those things are pretty cool, too. :) I do have a few more cheap ARM boards of various types than I can probably use, though.
> Hashcash was proposed in 1997 by Adam Back[1] and described more formally in Back's paper "Hashcash - A Denial of Service Counter-Measure".[2]
The quantity-above-quality model in the spam industry probably lead to low-quality or vague list criteria. Broad demographic groups and domains. A lot of third party data of questionable legitimacy. If you've been running the list a long time, some "email address foo@bar.com clicked on campaigns A and B" data. You might be able to say on a large scale "List A is likely to convert better than B", but it still comes down to spray-and-pray at the individual address level.
If you went to a spammer with a few "sucker lists" of 100k emails each, and told him "you can only send 1k per day", will he have the data to triage his list to get a decent return on it anymore?
This would also snowball over time. Without being able to do high-volume campaigns initially, they'd have a harder time building up the knowledge they can use to manage their lists, and the quality would decline over time.
Wouldn't this be a good task for an open-source package to handle? If you'd just updated the package regularly, your mail would always be sent according to the rules. No need for any third-party handling your mail.
Some of the "rules" for reliable outgoing email delivery cannot be encoded inside the source code files of a github repo, or email setup bash script, or a Docker image, or a EC2 virtual image, etc.
An example of an unspecified "rule" outside the boundaries of a local machine holding the email server is recovering from an unexpected blacklisting of ip addresses. Example.[1] A preconfigured Docker image of Dovecot isn't going to magically ask Amazon support staff why the ip address is blacklisted and/or move the server to a different ISP etc. If a bad actor (that you are unaware of and have no control over) happens to share your ip address block and sends out spam which then causes Gmail/Hotmail/Yahoo to reject your server's emails, there's no open-source programming code that can detect and fix those problems happening outside of your control.
Or put another way, if HonestJoeBlow could download a constantly updated Docker image that has the so-called "correct rules" for sent emails to always be accepted by Gmail, it would mean the DishonestSpammers could also download that same Docker image to get their emails delivered.
The issue is that "trust" in the email ecosystem is an emergent property among participants and therefore, it can't all be embedded inside email server configs, or in a DIY blog article trying to explain the exact 12 steps to make email delivery work perfectly with all receivers. Eventually, something can break (because a receiver changes their idea of "trust" and "spam") and it requires troubleshooting & debugging to get email delivery working again.
A tldr would be: You can't put "sender reputation" into a downloadable software package.
[1] https://forums.aws.amazon.com/message.jspa?messageID=724690