I’d never suggest it.
Agreed. I’d put something more concrete on the agenda.
While I accept that along with spam enablers (bulk mailers et al) wisening up to the resend trick they’ve also traded in their old indiscriminant mailing practices to sell more targeted campaigns. If everyone really got different spam it would by some definitions no longer be spam, now would it? We decide what email we want and what we don’t want, not some corporation, government agency, coalition of service providers or internet task force. If we act in concert as a community we can make and enforce our own decisions. Anyone sending out legitimate emails would know to avoid using bulk email providers who allow spam or sell targeted email campaigns themselves. As such we’d be within our rights to identify and blacklist shady email practitioners wholesale. The internet’s formal overseers cannot do the same since it hinges on guilt by association which is easily overturned.
Accepted. I wasn’t aiming to burden you with the implementation as such. My plan was and for the time being remain to strike up a constructive conversation with David Schweikert with the intent of enabling his postgrey soltion with communal whitelist and greylist capabilities. I don’t want to approach him empty handed though. I’d like to be able to say to him that the you as MaiB maintainer have the support of the MiaB community to serve as anchor tenants for the new communal facilities. I’d also be saying that am able and willing to help design and implement the solution I am proposing to run as a distributed system so that the load isn’t on any central server but spread over the participating MiaB servers.
In light of the above, I’m not actually asking that you accept the change in the sense of taking resposibility for writing or even reviewing the code involved. What I am asking is that you consult or lend your support when I consult the MiaB community to test if they will be in favour of asserting such control over spamming practices and pracitioners as a community of self-hosting email providers and its users. If there is general consensus that it would be desirable, then I’d simply ask that you’d allow me to tell David that you’re committed to integrate the new version or derivative of postgrey into MiaB as it becomes available as first adopters.
Like you, and for the exact same reasons, I am not about to commit any of my time or attention to something unwanted or ineffective. It’s presumably easy enough to disable postgrey and unless someone makes a ignificant move the spam sourge will keep growing. But there are things we can do, like actively choosing to work together in communities like this. When I happen to be the one who spots the opportunity and knows how to make it happen my I will always aim towards wanting everyone to benefit from it. Don’t ask me too much or too soon about the economics of it all, because I believe that finances are only a problem when something costs too much to produce for what value it adds.
I’ve looked at dnswl.org. Their product is probably valid but from my perspective completely upside down. They’re compelled to (it’s impossible to say whether it’s their choices, circumstance or client base that compel them) to enable senders, including bulk email providers which in turn include nefarious bulk email providers to get whitelisted with the intent on getting emails from those providerfs through the defences people put up to reduce unsolicited email. I tend to read email headers of unsolicited emails to see why my filters did not reject it. Quite often I end up just shaking my head in disbelief because of how easily the DKIM-, SPF-, DMARC- and whatever else -based rules are getting defeated. Blatant stuff, yet by the time any one of those rules and weights are considered fit for general consumption they are utterly toothless. That’s the dilemma and it’s ever apparent in dnswl.org’s solution.
The opportunity we have, since we have the makings of a community of relatively like-minded email users in the sense that none of us are bulk email enablers and all of us are impacted by unsolicited email being sent from bulk email providers, is to take a much harsher and more direct approach to identifying and dealing with unsolicited email. Because we can agree to work together to shared objectives, and because we’re generally speaking “on-it” in the sense of each one of us more or less actively manage and support a number of users directly, the odd false negative or positive will soon be discovered and specifically addressed as users report on expected messages not arriving or spam received anyway. Unlike public facilities we’re not obliged to recognise every bulk email provider’s right to make a living selling targeted email campaigns.
As far as a workable (re)definition of spam is concerned, I will add this 2c’s worth of opinion into the mix. Legislation in most jurisdictions today require that emails sent to mailing lists offer an unsubscribe option, and by and large most do. One trouble is that fake emails usually breaks the unsubscribe link in one way or another. The bigger problem though are mailing lists that offer unsubscribe options what are not adhered to, meaning you unsubscribe but they keep sending like nothing happened. My 2c would be that within this community of email users I’m proposing we adopt a specific position. In general we’d let people vouch for email senders they consider legitimate. But if someone reports that such a provider fails to adhere to a request to unsubscribe, that becomes grounds for taking the provider off the whitelist.
Generally speaking I’m convinced that the existence of some insanely valuable email coming from a source you’ve never interacted with by way of a bulk email provider is pure myth. Not all email from people you’ve never heard from are spam. Not all email sent from well-known sources sending out millions of individually addressed mails each day is spam. But it’s highly probable that every email sent by servers being used for indiscriminate or targeted email campaigns are unwanted or at least deserving of landing in a junk mail folder.
If we end up go through with this idea, the result would be that email from your average individual or company would land in your inbox without delay and unmarked. If you get an email from a mailing list you don’t approve of, and either unsubscribe doesn’t work or you don’t even want to click on that link either in case it’s a trap, then you get to tell your email admin and they get to declare that email as unwanted. If enough people (we can decide on a number) call out emails coming from servers that clearly defeat all the protection we’ve put up as being unwanted, that entire server gets identified as a spam facilitator and either black- or greylisted.
Of course the question of gmail and the likes will come up. Will it be feasible and fair to consider all email sent from google as the same. Well, that remains to be seen, but I suspect the answer has to do with whether Google is able and willing to guard against people using their services to send bulk email. I believe they have the mechanisms for that in place but I haven’t personally seen evidence it getting engaged. I do check the both microsoft’s and google’s TLS reports from time to time though, and I’m yet to see any indication that some of the spam I get had been sent from either source. I’d say on that evidence it’s probably a fair initial assumption that whitelisting Google’s servers would open any flood gates for spam to rush through. If it happens, it seems both Google and Microsoft have prepared themselves to disallow their free or paid services from being abused for sending unsolicited bulk email. Neither is keen on giving away something they could charge for. The only worry is if either of them are complicit in sending unsolicited bulk email as a paid service, or more specifically if the servers involved with that can be identified as such without impacting free mail customers.
Anyway, this post has become far longer than I intended. Sorry. I’ll keep trying to shorten things in future but I did have a lot to get off my chest on this topic.