I'm sure regular airline passengers trip the metal detectors more often than terrorists, doesn't mean we should get rid of the metal detectors.
replies(1):
But sure, Linkedin emails are definitively not spam and their dark-patterns at adding you at n+1 emailing list doesn't get them banned from the big (or any?) provider.
I was dreading this step as I hadn't done it before but turned out to be a breeze thanks to that.
It makes sense that people whose business is sending email know how to set up email correctly. I'm mostly surprised at how many legitimate sysadmins struggle with getting the basics correct. Surely those dozens of DMARC emails you get that your sendgrid email has been refused because of a bad SPF signature should set in motion some kind of plan to ask if maybe marketing is using them legitimately?
Automated signatures are of limited value but I rarely see rejections based on SPF and DKIM that are a mistake. Things are probably worse for big organizations but as a small email server, technical rejections are usually the right call. The only exception is mailing lists, but the dozens of people who still use those can usually figure out how to add an exception for them.
We had/opted to acquire the services of a company "expert in email deliverability" (Return Path), who somehow provided detailed metrics of how our IPs were scored by MSFT. I always wondered why MSFT didn't provide those scores by themselves, and how a 3rd. party could have access to them.
Re. your comment... slow ramp-up is the only way, with constant monitoring of deliverability and consequent adjusting of recipients (i.e. removing those who do not open or hard-bounce). I did also wonder if paying that company perhaps gave us a headstart when adding new IPs...
The logic isn't even that bad. SPF and DKIM serve to prove to the email who the sender is. That doesn't mean much if the sender is a spammer. Verifying identity claims is only the first part in checking email for spam, the harder part is checking if that identity is someone you trust.
When you email Outlook or Google, you're better sending more than a few every single day, and the recipient better manually drag those emails from their spam folders to their inbox, or they're all being learned as spam.
I would imagine that on the corporate side, your employees could do the same. Beyond that, if you're sending spammy stuff, have unsubscribe headers and links in emails.
The domain is new and didn't send a single email until I tested it.
Edit: The domain is actually a bit old but was parked/inactive for a while, though the email was used only for receiving.
It's to stop midrange threats.
You need IT to list all of the reporting tools, customer service to tell you about their support system, marketing to tell you about their mailing list tool of the week, the sales guys to warn you they're using this new AI email enhancer, and somehow get that shady email forwarding service the CEO uses to give up their mail server IP addresses. Then you need to figure out how to get coverage for all of those tools and keep on top of them whenever something changes.
A lot of companies promise to do great things for you if you just enter the email address you'd like to send email from, and a lot of people gloss over the important details because those sound hard and when they tested the tool on their personal email it worked fine so that's probably unnecessary anyway! Managing email for a corporate domain can be like herding cats.
Those email services will usually have no trouble with replies to emails sent from their service, so if you get someone to email you first you'll save them the trouble of dragging your email from their spam folder to their inbox.
I wonder why it doesn't work this way.
You'd think spammers would've learned to avoid SPF domains at the very least but they haven't, so despite SPF/DMARC/DKIM failing to get anyone out the spam folder, the technology is still catching spam bots.
Most home and VPS IP ranges have negative rep.
—⁂—
1. I tried responding to a Chromium bug tracker message by email a couple of months ago, and it failed me:
> Unfortunately, your email to create/update an issue was not processed.
> Reason: SPF/DKIM check failed. Please ensure your domain supports SPF (https://support.google.com/a/answer/178723) and DKIM (https://support.google.com/a/answer/174124). If your domain does not support them, please use the Google Issue Tracker UI (https://issuetracker.google.com).
Trouble is, this is simply not true. My SPF and DKIM are fine. This makes me wonder whether the email ingestion system is simply broken for everyone.
—⁂—
2. I got involved in setting up a Google Workspace for someone a few months back, and the entire tool that their own documentation instructs you to use to check things, https://toolbox.googleapps.com/apps/checkmx/, has been laughably broken for years, sometimes not working at all, but mostly producing misleading nonsense results (e.g. claiming domains have no mail server set up when they do).
Then, to make it even more absurd, the feedback link they give you, https://toolbox.googleapps.com/apps/main/feedback?toolname=c..., iframes https://docs.google.com/a/google.com/forms/d/e/1FAIpQLSdnlp8..., but you haven’t been allowed to iframe such documents for I don’t know how long so it doesn’t load, and even if it did, it’s a private form that only Googlers, I suppose, can fill in. And there have been plenty of reports about all of this for years, and it’s still broken.
I’ve abandoned that role and have gone back to an IC role and I’m much happier for it.
The root problem is that we don't actually need to keep track of email server reputation. No one says to themselves "Huh, this is from a Gmail address, it must be legit". We really want to keep track of sender reputation. We need to be able to treat anonymous email differently than email from people we actually know. That implies that we have some work to do on the problem of identity. As it is, there is not even a way for a known email sender to securely introduce an unknown email sender. You know, the way that regular human people normally are able to transfer identities from one to the other.
If you do it this hacky way - we run this risk and this bad thing can happen etc. After a few times they see the consequence of their decisions people start paying attention to you. Do it a few more and now the company will have an "institutional knowledge" that you are usually right, and even if the manager leave, you still end up like the go-to guy on how to ship.
And sometimes the marketing people might end up being correct! I've once actually battled to "do the correct thing" (way back in the day it was a ruby on rails modeling I think) and the product owner was like - just do it this hacky way I don't care ... I did it the hacky way and you know what - it was the right call - we never changed it again and the business knowledge we got from it was actually valuable.
https://www.fastmail.help/hc/en-us/articles/360060591153-Man...
I configure my domain to use SPF, so now spammers can’t sign it properly.
However, the fact that an email passes SPF verification only ensures that it was authorised by the domain owner. It doesn’t say anything about whether the domain owner is a spammer.
That paragraph is incorrect. SPF/DKIM is not about reputation. The main purpose is preventing domain impersonation from unauthorized senders. E.g. mail servers will reject fake emails from "upofadown@microsoft.com" because you don't control any email servers that's whitelisted in microsoft.com DNS TXT records.
E.g. I was able to register a brand new .com address and then successfully send to gmail and MS Outlook accounts within minutes because I had proper SPF/DKIM in the DNS records for that new domain. That new domain had zero reputation and yet Gmail accepted it because SPF/DKIM was configured correctly -- and -- the underlying ip address of the server it came from had a good reputation.
If SPF/DKIM was truly about "reputation", it would mean I'd have to wait days or months for reputation history to build up before Gmail accepted it.
That's exactly what PGP's web of trust model is for. Someone you know, and trust, can sign and send you a public key of someone that they trust.
This new key will be automatically trusted in your trust store because it's signed by someone you already trust, although in a lesser trust level to account for the degree of separation. If you later verify that key out of band you can upgrade it to a higher trust level.
SPF/DKIM, as well as TLS etc., is just stupid shit we do because we're too lazy and/or incompetent to make web of trust work for us. It's not a technology problem, it's a human problem.
To be clear, I'm not necessarily a fan of DMARC, particularly how it was introduced. But it is very obvious that spammers will eventually do everything to not be flagged as spammers.
What DMARC gives you is that it makes it less likely that your phishing mail will come from contact@yourbank.com. It will rather come from contact@y0urbank.com or some other domain.
How much of an improvement that is and how many people will notice is certainly debatable. But that's what DMARC can give you. Nothing more, nothing less.
Not sending email to google helps.
No more, no less.
For spammers on other hand it's just a business, there will be no reprecussions like ever and we know quite a few big and legitemate companies who started their path with marketing spam sometimes using leaked email databases.
Then it checked the DKIM signature on the message it REWROTE ON ITS OWN and decided that the signature didn't match, and rejected my email.
Corporate email stacks are hell.
There is: gpg/pgp signature, but many people find it complicated, primarily because they are reluctant to read the documentation. And it’s popular to criticize it, especially here on HN, in favor of various half-baked alternatives.
Tin-foil hat time, but I've always thought there was nothing unintentional or "unfortunate" (from Google's perspective) about this.
I doubt Russian spammers will care about the difference to be honest. If they accept that their email will be delivered to spam folders, why would they care that the email gets silently dropped? In neither case anyone is going to fall for them.
We actually do. Is the server allowing anyone to sign up so that it's sending 99% spam, or does it have a lot of anti-spam measures so sign-ups can't be automated and it blocks accounts as soon as it detects them sending spam?
Or if we can't trust users to handle TOFU, then some token/unique address/whatever that we can exchange face to face to enable trusted communication.
Edit: Proof-of-work "email postage" schemes are similarly doomed - The botnet that zero-day'd your mail servers does not care how much electricity they use.
I'm pretty bitter about it all still, but it's a combination of a lot of things beyond this particular bit I shared. All I can say is I'm glad I am no longer in that role, it was slowly killing me.
In the early-to-mid '10s, before SPF/DKIM/DMARC became the law of the email land, one had to be much, much more careful with phishing emails, checking the wording, the logos, etc, because 9 out of 10 of them appeared to come from the actual domain the email purported to be from. In the past several years (I honestly don't know exactly when the change happened; I don't get a huge amount of phishing emails), it's shifted so that the first thing to check is the sender address. Usually that turns out to be some nonsense string @gmail.com or some long garbled domain.
Indeed. I am on a few mailing lists and many people on them host their own email. I use Gmail so that means visiting my spam inbox once a day to click "not spam" upward of a few dozen times. Day in and day out, same people end up in Googles spam folder. It's bullying and sabotage.
> No one says to themselves "Huh, this is from a Gmail address, it must be legit".
Indeed. I get a shit load of spam from google addresses so reputation is not there.
> We really want to keep track of sender reputation.
This is the hard part but I do think it's something to think about. I should be able to get an email from a known sender every time without $emailprovider making that decision for me. Some sort of attached signature or key that is proof of sender identity so I can route that right into my inbox.
That's what kills a lot of these "perfect" implementations.
HN members tend to be nerds, and we don't really have an issue with setting stuff up (many HN IDs, for instance, have Keybase auths).
Most non-HN types have no patience for that stuff. Security needs to be made accessible and easy-to-use, before the vast majority of folks will implement it. That's the single biggest conundrum, IMNSHO.
Having key signing parties for the entire world wide web does not seem scalable to me.
Could I, as a trained programmer, use PGP and GPG? I'm sure I could if I spent some time reading about it. Could my 90 year old grandmother, who is otherwise quite comfortable with email and whatsapp? No, not to any meaningful extent.
Marketing should get their own (sub)domain for sending their missives, that way the primary corporate domain's reputation is not harmed.
Unless you want to run the risk of outgoing e-mails from Finance / Accounts Receivable to be sent to other companies' Junk folder.
Over the years, I have administered a few dozen small to medium domains (depending on the domain 10s to 10,000s emails per month) and the only thing that has ever affected delivery is the reputation of the sending IP address of the mail server (and ensuring DKIM/SPF alignment in more recent years).
we by far don't enforce them strict enough, because if we where people would make sure to get it right
it's all a question about effort/turnout
if you make it so that most times you mails still somehow end up with the user even if you mess them up there is much less insensitive for companies to fix their mail or force their provider to fix it
so IMHO if all of SPF,DKIM and DMARC are not correct setup mails should just be directly discarded and not even delivered to spam
while being more flexible was reasonable when this tech was new, that was 10 years ago. If being flexible mean that you also will sometime deliver outright cyber attacks like spear phishing and similar to your user and everyone had 10 years to fix their systems then there is really no reason to still be flexible.
Also "scammers get it right so it's useless" is such a huge red hearing argument, yes they do get it right _for their domains_. It sill makes it harder (and if strictly enforced impossible, except if you give them permissions to do that*) for them to impersonate your domains.
And yes that doesn't fix scammers from using their own domains, but it also was never intended to do so. Doing so is a very different problem one which probably needs some form of reputation system which isn't something you can just solve technically as it touches on a lot of subtle social political issues. Also given that all of the huge mail vendors have insensitive to use their "intern proprietary obscure" reputation system I don't expect there to be a technical solution provided/adopted tbh.
(and yes SPF/DKIM/DMARC are all tech wise quite "meh", but we are kinda stuck with them, through that never was the issue IMHO, the issue is missing insensitive to bring the adoption up and missing insensitive for large mail providers to enforce it strictly)
EDIT: PS: In one point they are fully right so, that is, with how things are you can't give SPF/DKIM/DMARC a large weight for calculating reputation. Also they where always only meant to tell you if someone can't be trusted, but never if someone can be trusted.
I just left a couple of comments regarding the use of "strtok". Its use is straightforward, just RTFM. Those were the golden days when people were less reluctant to read documentation. You could not even install Linux back then without an installation guide of some sort. You still need it for Gentoo, perhaps even Arch or Void. Are they wrong? No, just different target audience. If you do not want to become a "power user", that is fine.
My grandma can barely handle the TV controller. So what? I am really against dumbing things down, called "ease-of-access" or whatever they call it these days.
I agree on that, however, that GPG / PGP signatures should be more visible and whatnot, just add some visual feedback (verified? legit?, etc.), and some e-mail service providers actually do this.
For what it's worth, I've started seeing cybersecurity insurers requiring riders and extra payments if you don't block Russian IPs.
The simplest solution to that would be an "only show me emails from people in my address book" filter. That would mostly echo how we treat user trust on all other platforms. Genuinely surprised this doesn't exist in most email clients (or does it and I have just overlooked it so far?)
Of course that's only a partial solution and wouldn't work for accounts where you expect unsolicited mails from people you don't know. I'd see it more as a "low-hanging fruit" solution. You could also expand the heuristic, e.g. also consider previous conversations, mailing lists, etc.
(Interestingly, the "introduce a friend" functionality would come for free: You can already send contact details as a VCard in an attachment. When receiving such a mail, some email clients will show a button to quickly add the contact to the address book.)
Nobody wants to solve the problem of spam, this is just theater to put another tax on the smaller players in the Internet industry business.
* https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...
* https://datatracker.ietf.org/wg/dkim/about/
* https://blog.redsift.com/email/dkim/first-look-at-dkim2-the-...
The recently-held IETF 122 had a session on it:
DMARC is nice though. It won't stop spam. It won't stop spoofing. But you will know that someone somewhere is spamming people using your domain name. How awesome. :)
This little bit of wisdom gets passed around all the time, but it's actually not true. You can send email from a brand new domain to Google and Microsoft and whoever just fine. What you can't do is send email from a brand new domain, and a brand new email server--or an email server on a VPS, or an email server on a residential IP. Residential IP blocks are almost completely blocked, because of unsecured devices being used to send spam, and VPS blocks have the same problem. You can get around this by using a mail relay, or building your domains reputation on a server that already has a good reputation.
There's a difference between one and dozens, and even between one dozen and dozens.
Most companies are not of Microsoft's size either: just having news.example.com would probably be sufficient for a lot places.
Unless you own a global business, i see no reason to even allow other countries access. The potential for attacks is too great, especially from some very specific countries.
Russia, China, Nigeria, Romania, North Korea, Iran and Belarus [1]?
[1] https://www.ox.ac.uk/news/2024-04-10-world-first-cybercrime-...
Doors and locks are there to make theft harder, more overt, loud, etc, and by no means validate when it's legit to be a vile thief.
Likewise, all spam is spam. The use of tools to make it more difficult for spammers to be spammers, is the same as having doors and locks. It makes it more difficult.
edit: What I said was, you clained they tried to justify it. So no worries, I was not implicating you.
Web of trust scales better than that, though. It gives you confidence in keys you haven't seen yet because they are signed by other keys that you do trust. The key signing parties strengthen the web of trust, making it more likely a potential correspondent will receive a key signed by someone they trust and therefore potentially not needing to verify it personally.
It all depends how much confidence you want to have for each key. At the end of the day there is no substitute for verifying each key personally if you want to be completely sure. PGP give you the option to hold keys with a lower level of confidence for e.g. less sensitive communications.
The important point from the above is it was worth the effort to learn. The only person I know who is a strong advocate of PGP was a missionary to Romania before the iron curtain fell - he had strong reason to hide what he was saying from government level actors and even today still is willing for extra effort to protect himself. For most of us though our threat profile isn't (or doesn't seem to be) that high and so learning how to use the tool isn't worth it.
Theft is theft, but for monkey brains there is huge difference between stealing someone wallet from a pocket vs picking dropped wallet and not returning it. So my point is that doors and locks work not because it's good technical measures, but due to how average Joe percieve social construct about them.
And for grey area activities online there is no such social construct because there is no percieved connection between bunch of email addresses and real people. Also in some countries it's totally legal to send you tons of physical mail spam.
SPF/DKIM is literally how you establish sender identity instead of relying on the IP address of the email server so it is ironic to claim that they have anything to do with server reputation while lamenting a lack of sender reputation mechanisms.
Currently, SPF/DKIM are mostly used to prevent fraud, but they also provide the best tool we have to build sender based reputation systems.
It probably makes sense to leave the US out of the list, assuming the CableNinja is in North America.
The rest seems pretty arbitrarily chosen, though. JumpCrisscross gave no additional context to why they left out Ukraine, Brazil, India, UK, when picking countries from the list they linked. They have higher cybercrime index ranks.
Whether they have a higher chance of "real" traffic is highly dependent on the business in question.
I'm sure there is some amount of thought behind the choice, beyond just using the index, which is why I'm asking.
It should not be used to imply anything else, none of these have anything to do with spam, that's reputation (and yes, having DKIM set-up boosts your reputation but it is not sufficient) and should be "built" up by the domains sending the emails.
This is how email-as-infra works, you're sending from a shared pool of their ips and they sign your emails with DKIM and you'll have SPF set up as well on your own.
I run my own email server. Most spam crap cannot pass spf/dkim. Although this post has caused me to sit up and notice that the trendline is moving in the unfortunate direction, where I'd say 3 years ago the ones that pass were about 1/4, today it feels like 40-60% pass. The amount of mail I get that I expect, passes spf/dkim at around 90-95%
I suspect the delta between their any my results are the very restrictive sender rules I have prior to accept. In addition any_address@domain goes to my default mailbox, so I'm also probably selecting for laziness a bit more than most.
I also publish an email address without obfuscation on my site, which is getting very little spam, (near zero) which makes me wonder if most spam has given up on scraping the Internet for emails these days.
The more effort you have to put in to use them to send mail, the more likely spammers don't use them, and the more likely their ip space has a positive or at least non-negative reputation for sending mail.
Complicated doesn't mean bad. I'm not claiming that PGP or GPG are bad technologies because they are complicated to use.
> My grandma can barely handle the TV controller. So what? I am really against dumbing things down, called "ease-of-access" or whatever they call it these days.
The "so what" is simple: PGP is not the right anti-spam solution for your grandma, or mine, or any users like them. This is the context of this conversation: is PGP a good-enough answer for how to establish identity for email in the interest of anti-spam and anti-scam efforts? And the answer is a clear and resounding no, not for the vast majority of users of email.
This, again, doesn't mean that PGP/GPG are bad technologies - they are very good for certain use cases and certain users.
Of course, even with hard fail spf and dmarc, I still see some bounces from spam where some server accepted the mail to deliver it elsewhere and the next server denies it, so the first server sends me a bounce.
The other option, of course, is to design a trustless system, like BitCoin, but that has its own problems.
And all that just for the privilege of being able to send email to some gmail accounts. Trying to get email to properly encrypt is pulling teeth and yet I still get hundreds of thousands of spam a month on my gmail account.
Any time I have to set up an email server on a new system I just kind of die a little.
https://ofac.treasury.gov/sanctions-programs-and-country-inf...
Web scraping gets you a lot of fake emails, company sinkholes, and other low reward stuff. Paying $20 for 100k confirmed real emails with names? That’s gold.
I put this initial system in place expecting to have to augment it later with a more traditional content-based filter, but this simple heuristic works so well I've never felt the need to implement that additional step.
I actually think this would work fine. Imagine a quarantine inbox for new emailers that the user must scan and approve/block. This is exactly what hey has implemented.
IP reputation, proof-of-work, and various fee-for-receipt schemes are trying to solve spam in the same way: by charging low-volume users a trifle to send messages at a "normal" rate, which adds up to become more expensive when you start bulk mailing. The problem is that these schemes have to assume that there is a single market-clearing price[0] for sending messages that is both low enough to not inconvenience legitimate users and high enough to make bulk messaging uneconomic.
Such a concept goes against how communications networks actually function. The amount of communications resources the average person uses is so low that it's not worth billing for them. Sending any sort of data isn't free, but it's "cheap as free[1]". Any communications technology that bets against this will fail in the marketplace. People are not going to go back to, say, buying (virtual) stamps at 73 cents[2] a piece to send mail with. Hell, the $10/GB I pay with Google Fi is already enough to make me cringe every time I actively use my data plan.
On the other side, charging a fee for misbehavior legitimizes that misbehavior; if the fee is less than the value of the misbehavior then you are just imposing a cost of business. Spammers need to send lots of mail because the rate at which people fall for your scam is comically low. But when you do hook a sucker in, they yield a huge return.
So what we have here is that legitimate users would balk at per-message rates that wouldn't even be close to what would make spammers flinch. Which is, again, the same problem that SPF/DKIM/DMARC have. People whose job it is to send garbage e-mail for a living have a far higher tolerance for Internet bureaucracy bullshit[3] than people who use e-mail to get their real work done or to talk to friends and family.
[0] Getting your IP banned for spamming or having to burn energy brute-forcing a hash can be considered a price.
[1] Buy all our playsets and toys!
[2] Current price of USPS letter postage
[3] In the Graeberian sense
Now that said, I've worked with a lot of IT/engineering people who are pretty obstructionist to normal business operations and sometimes need to be told, "yeah, we're accepting the risk, move forward with the plan." Sometimes it's for good reasons, other times it's just our normal humanity asserting itself in different ways. It's a hard problem for sure.
Add a filter looking for the word "Unsubscribe" and automatically put them in "Promotional" category or something similar. Also apply the filter to existing emails, and let it run for a minute.
Try it now! And comment if it reduced your inbox to like 2% of what it was :)
I've been self-hosting mail for me and my family for about 20 years and don't send nearly enough mail to have a "reputation" with anybody. Still, I don't have any problems with deliverability of mail.
I get emails that literally say "This is an email advertisement". These are presumably being blasted out to tons of mailboxes. How does a model not notice this?
https://en.wikipedia.org/wiki/Greylisting_(email)
95% of spammers never retry.
But if you have a regular decent size of emails coming from your domain, that is more likely to be spam than if you have a small number of intermittent emails coming from a domain.
My server sends 451 after DATA, and keeps a copy of greylisted message, as marked-as-read entry in separate folder. Those are deleted after few hours, or moved out after a successful delivery retry.
* WHOIS is effectively destroyed.
* Companies like Cloudflare actively protect known spammers & scammers, and have made abuse reporting time consuming and error prone.
* Consolidation of most email to several large players means filtering them causes problems.
* Large delivery companies such as Sendgrid, Salesforce and Google basically do nothing about reported abuse.
Yes, most spammers these days that set up their own domains have tools to make sure DKIM, SPF and DMARC are all good, but consider that we can't know anything about these spammers: TLS certificates no longer contain contact information, large providers don't provide useful WHOIS, don't forward abuse complaints, have no clue what an SOA record is, and so on.
The way things should work is that we get a spam, we see the network from which the spam came through WHOIS, we forward the spam to their abuse address or the address they list in WHOIS, and we're done.
The way things work is that they don't have working information in WHOIS, they ignore the abuse complaints, they act like they don't know what to do with it, or they reply with a form email saying to go and use a web page where it takes time and work to paste in each part of a spam.
I blame the large companies who do this. Make reporting abuse difficult and you'll get much less reported abuse.
It is correct that SPF/DKIM does not really avoid spam, because spammers are not stupid and can read these standards like anyone else. However, before SPF/DKIM, I remember that I got a ton of phishing mails with FROM containing "support@paypal.com" or similar. Then came Bayes spam filtering, and that would move legitimate mail from Paypal to spam, because obviously, the phishing mails are quite similar.
This problem has pretty much vanished, because Paypal clearly denotes which IP addresses are allowed to send mails from that domain via SPF and the client can verify the mail via DKIM. For instance, Spamassassin makes sure that mails with correct DKIM and from paypal.com get a massively reduced spam score so that your Bayes filter will not move it to spam. This is hardcoded for a lot of domains (see *welcomelist_dkim.cf).
I ran into this helping a friend whose biz emails to gmail recipients were getting dropped; the IT dept of the umbrella corp wouldn't respond. Same to me when I sent the correct DMARC, SPF etc.
(My friend's biz was his own but it shared some resources with a larger corp.)
I eventually realized that the (wrong) DMARC reporting domain wasn't even registered. I did what you'd expect and I soon had DMARC reports for subsidiaries of the umbrella corp. My friend passed that up to the CEO and suddenly IT was responsive.
In the end, it turned out that IT was deliberately blocking his biz emails to his biz family members. After 10 years they suddenly decided that email to family+gmail was risky and that they were going to gaslight my friend about it. Because reasons.
If I recall, SPF limits the number of domains you can enumerate in your DNS records.
I suppose the moral of the story is that it's possible to do billions of dollars in business a year without having textbook-perfect mail infrastructure. Hell, I ran a mail server with bad MX records, a missing PTR record, and a mismatched HELO header and the world kept spinning (when I was a literal child with nobody to tell me better - I've since learned the error of my ways).
I’ve run into outright malicious stuff internally like this, but never externally - I would probably go apoplectic if I was your friend
If that's not it, you an see which database maps your IPv6 range to Russia and contact them to ask them to change it.[3]
Of course, if you have accounts with a Russian addresses, then things will revert.
[1] https://tunnelbroker.net/export/google
A fresh, plain setup on office 365 doesn't fail, but however their security department reconfigured things causes it to fail.
I've never been on the configuration side of M365 email like that, only basic cheap tier stuff and only briefly. I can't say what they're doing, but the same settings sending to practically any other email provider or even other 365 tenants works perfectly fine.
Usually I will just disable the iCloud hide-my-email I used for a site, but sometimes there are legitimate emails mixed in with the stream of crap. I opted out of marketing emails from my credit card company, and now they instead send me emails asking me to re-evaluate my email preferences...
It would be nice to see more done to fix this, but I guess it doesn't make anyone money. I guess I'll just have to use AI to filter signal from noise.
I've been successfully using VPSes to send emails for 20 years.
Require a fee to deliver email. If the email is deemed legitimate by the recipient then refund the fee.
> No, they will happily pay money to spam you
It's a question of price. They can't spam at scale at high enough price.
The issue here generally boils down to the defining difference between a generalist Admin and a Messaging Admin. The generalist can follow instructions, and nearly all the instructions out there stop at the point where SPF/DKIM/DMARC are successfully implemented. A generalist worth their salt will then fill in the gaps if they can', and knows this isn't where you stop when you want mail deliverability. There's a higher bar.
If you follow instructions written by non-professionals blindly you don't ever reach the point where you get to quality work.
Google, Microsoft, and the other large ESPs don't refuse to relay your email based on secret internal factors. This is what the non-professional people say to falsely justify why they can't do something.
Google and Microsoft publish the internal factors they use in the form of whitepapers at the industry working group. Its not ready made, and there are a lot of them, and they may not release their specific implementation details, but the metrics are there and often are based in weighted form (reputation-based systems).
If you follow them correctly, and set up the appropriate reporting accounts, and maintain those accounts, you won't have these problems. You generally only have problems once you've violated guidelines continuously, which happens when you rely on, or are unable to discern between qualified and unqualified help.
The factors are published at https://www.m3aawg.org/
Every professional that specializes in email or messaging that I know of is well aware of this.
People don't have the same vitriol when it comes to comparing Generalist Admins to DBAs, and this is the same with any specialized niche.
If you need email and messaging to work in a complex environment, you hire a person that specializes in it.
How is DKIM "deeply flawed"?
The reasoning you provide doesn't differentiate, and speaks more of frustration which naturally comes with any area you aren't steeped in, or knowledgeable about.
You never see or collect the information by blocking everything at the outset.
In a world where you can proxy past these blocks fairly trivially, that's information you don't have for attribution later.
Defense in depth, or layered defenses are a best approach, but not if they blind you equally.
Unless I pay extra for Premium DNS, my DKIM is set wrong because their Web Hosting DNS does not oet me set it correctly.
Our IP is the same for the last ... ~5 years now? Is it because we did not buy a /24? is it because we are so small they have no real reputation data? who knows!
There is very little interaction from them, they assume you'll be professional enough to read the published literature and act accordingly.
The literature is a way of adding cost to those that would send spam, it also adds cost in other ways.
If I had to guess without knowing more, assuming you've correctly configured yourself locally (which may not actually be the case), I'd say it could be because of your ISP.
In recent years, with the depletion and exhaustion of IPv4 address space, many ISPs have moved towards CGNAT, where multiple customers share the same IP transparently. The ISP may do this without you knowing, but you'd have to have constructive knowledge in some fine print.
Subsequently by extension, they share the same reputation characteristics for that portion as others on the same network. Residential IP blocks get heavily punished or outright blocked on both sides.
There isn't this problem with IPv6 (no CGNAT and its complications).
I've seen this a few times now; even when the business purchased the business tier service for a static IP. In the client's case there was fine print that mattered that they didn't read in their service/purchase agreement.
The telltale sign that this might be your problem usually requires discussions with your ISP, but if you can't get to a qualified person on the line (from the backend/T2 team) you can run a test.
Have your networking guys check the traffic outbound and inbound (from public facing node) with a connection/packets that uses decrementing TTLs with either ICMP or TCP packets to get a path that aggregates each hop. Tracert or equivalent.
See if it is appearing to be routed through bogon network address space before it hits the wider network.
There are reserved addressing for CGNAT, and if the traffic is being routed across those address ranges this may be a large portion of your problem. This is just one of many things someone that specializes in messaging knows a thing or two about.
Graduated vendor responses occur with messaging, when you have little sound reputation at the start, getting everything right matters. Commercial places warm their domains and IP addresses up slowly over the span of a month. If you send to a provider like gmail, you need to click open those emails as mail that never gets read affects reputation per the whitepaper (m3aawg).
If you don't follow the practices the industry publishes, they don't relay the traffic.
> who knows!
I should know because I've worked in this area for quite a long time. It really is not black magick, and it is a specialized niche for a reason.
"I don't know" is not a problem, you learn and you know, no frustration.
The problem is "I spent N hours/days on a thing that everyone does and which is a 99.99% of use cases and boils down to just having a keyfile in a proper(?) location and this knowledge doesn't translate effing nowhere".
would you say the same about DBA operations or would you say that's just not my specialty
It depends on the absurdity of the complexity of setting something up, not on operations themselves. Getting some results is absurdly complex -- not naturally complex and not necessarily very complex, just much more complex than the nature of the result itself.
For example, that's how you were supposed to install openvpn before angristan scripts: https://www.digitalocean.com/community/tutorials/how-to-set-... . To save someone a click, it's 50 pages "installation tutorial" with around 50 commands and a dozen of config files. And guess what, it uses "easyrsa" package to "set up RSA PKI easily". So it's not how openvpn meant to be installed, but an "easy" way.
If you set DMARC to report, you’ll get notices from remote email systems when they receive noncompliant emails with your domain in the Envelope From field. Those reports are where you’ll see Russian IP addresses show up when they are trying to spoof your emails.
But there is no way to block them because neither the senders nor receivers are on your infrastructure. The best you can do is set a reject DMARC policy and hope everyone follows it.
There are critical tools that you clearly have not learned, and likely were never taught. Tools that have been around since the time of the Greeks.
This is evident in your use of poorly defined language running you indirectly in a circular path (trauma/torture loop).
There is irreducible complexity in software. Domain knowledge is needed to use complex software for purpose.
The script you say makes assumptive choices for you. What will you do now that RSA has practically become broken at small key sizes, and instead you need to use a different algorithm?
Do you know how to transition this without starting from scratch, or have you become corrupted by dependency, on someone who provided that for you that did have that knowledge? Are you helpless to do anything but wait.
If you want to correct the underlying reason for your troubles, I'd suggest going over the associated material covered in a Trivium based curricula.
It will require unlearning bad heuristics and re-learning good heuristics. It requires a lot of effort and constant attention until you've got your thought processes fixed and these provide the basics for rational thought.
You should have been taught these things in school.
Logic (Aristotle), Philosophy (metaphysical objectivity, identity and its requirements), Argumentation, Descartes Method, and Kant with regards to A priori knowledge, reasoning, and argumentation.
Small things with an outsized bigger impact.
If you can't understand what is written in the whitepapers, you have no hope of following the conformant requirements.
Software reduces to practice the requirements of business logic, which is described in those whitepapers.
Sometimes its irreducible, and you have to approximate, and they won't hand this ready-made to people that aren't willing to put the time cost and professional skill needed to do so correctly.
You have to offer tribute, in the form of expertise, and time to benefit from these systems. As you have to do for any other specialized career.
Spam by definition is mass messaging. If the price per message is higher than the expected return per message, it becomes pointless.
I don’t understand why Microsoft are so bad at this?
They have access to a large percentage of all email traffic to train domain reputation, and spam detection models on yet seem to be notorious for both false positives and false negatives.
Google’s spam filters are far more accurate.
It is an oversimplified way of evaluating of consequences of overwhelming control the two monopolists have over access of small providers to email services. And it leads to wrong conclusions at least in respect to the range of its influence. Yes, it makes difficult life for the small amateur spammers as strongly as for beginner administrators and service providers.
However while for the determined spammers to hire experts isn't a problem for small entrepreneurs and for non-profit personal activities it is a blocking barrier.
Of course, they can use the services of established providers with all the limitations and other disadvantages of such solutions or accept slavery joining millions of users and firms accepting full and unlimited control of MS and Google (to their undisguised satisfaction).
About the consequences of sudden and totally unexpected interruption of email services without giving reasons we all can read often enough.
- spammers have 1 system to set up in order to spam. They get it right.
- company admins have dozens of projects, of which this is a tiny one, with zero ROI to the bottom line (if people don't consider how critical security is). So they delay.
- companies often have dozens of systems integrated, when I set up DMARC/DKIM the first time for my company, a bunch of email tools broke, we had to do a bunch of leg work, took us a month end-to-end. The value was recognized when we almost lost 20k to a "ceo emails you" scam. But until then it wasn't a priority.
- we didn't even have a full IT, i just stepped in because I cared enough.
- my current company has a dedicated security team. These holes are plugged VERY quickly.
More specifically they seem to rely IP reputation rather than domain reputation, and IPs do change hands, especially for smaller servers.
Your response is that he ought to read the standards and implement things himself. That the frustration is due to a skill issue, not to deficiencies in the software.
Or do I misunderstand?
I feel like the only thing missing here is the recommendation to do it all in assembler. To "build character" or something.
I suppose that technically you're correct, in the sense that if he were more skilled he likely wouldn't be as frustrated. Such an observation hardly invalidates the complaint about poorly designed software though.
There's nothing wrong with someone who wants to roll their own but most people most of the time want an out of the box solution. It's inevitable given the level of complexity involved in the modern tech stack. Building all of it from scratch by yourself simply isn't realistic.
You mistake the environment you are in, and where it is going, which will threaten your ability to survive at some point as you are helplessly dependent on an environment that will cease to exist in the near future.
This was neither toxic, nor arrogant, just the facts and advice provided in good will and faith, something that is vanishing along with tolerance, and those facts should frighten you because they have detrimental outcomes as a consequence for you.
You didn't want to hear it because of indoctrination, and an inability to to comprehend. As a result, you have only yourself to blame for the choices you've made and what predictably comes next. Struggle and frustration.
Those that can't help themselves won't be helped by others. Those that cannot learn and adapt doom themselves by their own choices. Darwin's fitness.
A time is coming where the blind in their unpredictable and crazy behavior may be given a final mercy that can't be taken back, for the good of all because these people are a detriment to all if left alone. Historically, this is well known and it wasn't until modern times that we had the resources to care for such illness in seeming perpetuity.
Until things change, you've made it clear the only path for you is to struggle on needlessly, without any help, and let it distort you in a spiral of madness until you succumb to your self-fulfilling prophecy and break moreso than you already have.
Slapping goodwill and advice down falsely believing its toxic, when in fact its just unpleasant/harsh truths you weren't strong enough or willing to face speaks greatly to the character and outcomes you will face.
There are people who happen to know more than you do, about a great many things; because you were given a poor foundation purposefully. Its not arrogance to want to give people the opportunities that an education they should have been given as a child provides. The alternative is delusional adult children running amok destroying the pillars of their own survival.
You tread forward down the path those malevolent people laid for you, deceived, and never straying; biting any hand that offers help. Its sad because its preventable and needless.
I'll pray you revisit this when you get tired of the madness you put yourself through.
It was unclear, and the ISP wasn't giving us much, it took months to track down and some really clever networking tests. The Network Engineer really came through there in collecting the info we needed to have a discussion with the ISP. I mention it to save others the headache, and labor involved.
Going IPv6 native corrected a whole host of issues.
That's a pretty wild take. Was there no alternative ISP?
You are warned before you are outright banned. It shows up in the logs if you actually set that up properly.
It only appears like they cut you off because you ignore the things professionals pay attention to. Allowing an amateur to create and impose a problem and loss for other business is beyond stupid.
If you lack the expertise and context, you have no business dictating how things ought to be, and rabble rousing is vile.
>If you don't follow the practices the industry publishes, they don't relay the traffic.
They are sending us email, we forward it, Gmail throttles it because it looks like spam, and then they don't accept the bounce for example :)
> I should know because I've worked in this area for quite a long time. It really is not black magick, and it is a specialized niche for a reason.
It's not black magic, it's abuse of market power.
You have to understand the tasks themselves are not and cannot ever be simple because of the adversarial nature imposed by bad actors.
You can point at a small component piece and say that's a simple task, but taken in the full real working context its not at all simple because there were other requirements that were ignored when viewed in isolation that are crucial to continued function in a useful way.
The frustration is due to a skill issue, anyone that could set a system up without issue would, and there would be no frustration if that were the case.
Importantly also, this isn't a software problem, its a problem that cannot ever be completely solved by software. There are problems that computation simply cannot solve directly. This is one of them. Its touched on in Automata theory under the Limits of Computation.
Anytime you have two different underlying states whose structure is identical when examined (a single state that cannot be differentiated) it falls into one of these type of problems. Reputation systems are a form of approximation for hidden state systems used to differentiate in such cases by skewing it so those that those who abuse the system are limited and quarantined, whereas those that don't can use the system. The hidden states are required to make these systems work and retain usefulness.
The alternative is no communication at all because resources a limited, and the SNR doesn't allow differentiation putting that cost on every reader who will stop using such systems because it makes them useless and the cost is unreasonable.
The requirements and cost that result from implementation of the whitepapers requirements keep the systems useful. Not everyone should be running their own server largely because they aren't appropriately qualified to fulfill their responsibilities and obligations in doing so, and as a result of that lack of expertise cause issues for other businesses imposing cost when they are allowed to do so.
The alternative, having no requirements is having no messaging at all. You literally can't have it both ways.
The complexity involved is why Messaging and Email Systems are their own subspecialty within IT.
> Building all of it from scratch by yourself simply isn't realistic
You don't build it all from scratch. You configure the software someone else built from scratch appropriately to meet the implicit requirements to interoperate or you don't, and the consequence of failure is mail doesn't get accepted for those recipients at that provider.
As I said, non-professionals writing tutorials making it seem like this is simple, and people blaming their own ignorance on others; is where all the hardship is coming from.
It isn't simple at all, if it were an average child could do it.
I can tell you from experience, nearly every single postfix stack that I've walked onto the job and seen at a small business, lacked critical functionality in their configuration with only a single exception in a decade. That's thousands of instances that required standing up new infrastructure correctly, and they didn't have issues after that.
In nearly all of those cases a non-professional got hired, lied about their experience, and then set them up for failure and they got what they paid for, but didn't know it at the time.
It could have been set up correctly if the people were qualified, but they weren't and it wasn't, and its an ongoing cost because requirements change over time, when they change you change, or your system stops working.
Things like auditing and logging, rate limiting, alerting, migration, features like list-unsubscribe, and many other requirements... etc.
Most cases, people stop the configuration at the point where an email technically goes out and they call it a day, up until calamity strikes because they didn't pay attention to important things.
There are people who pay for the advice and are told months in advance if you keep doing this you'll wake up one day unexpectedly and find no email can go out, and they don't stop. They have to learn it the hard way.
Imposter syndrome is a thing in the industry, but there are also a lot of imposters pretending to be professionals as well.
I'll also agree that there are systems which exist that for whatever reason can't realistically be simplified.
However, on what basis do you claim that email - or rather email anti-abuse - qualifies as such?
> The alternative, having no requirements is having no messaging at all. You literally can't have it both ways.
You seem to be implying that the usefulness of the system derives from or otherwise depends on the difficulty of configuring it. However it doesn't seem to me that you've provided evidence of that. On the contrary, isn't the entire point of a reputation system that it avoids such gatekeeping by depending on historical behavior rather than some arbitrary barrier to entry?
I would make my own claim. That there exist software implementations that are far more complex than they realistically need to be, often because the thing being implemented has evolved over time and the resources or motivation or whatever needed to re-engineer and rewrite the implementation aren't available.
I would also claim that sometimes software has shitty UX for no better reason than the person developing it doesn't understand the needs of (some subset of) the people using it.
When configuring a network node to exchange messages in a really quite primitive protocol requires professional expertise to do correctly I'd say that's a clear indication that something is very wrong somewhere in the stack. Where exactly is certainly up for debate but a well behaved entity should not find it difficult to self host such basic functionality.
>If you lack the expertise and context, you have no business dictating how things ought to be, and rabble rousing is vile.
Your response seems to be typical for persons who are right because they are right - no args related to the content you respond to and ad personam args instead.
Boiling it down, it comes down to system properties that are preserved, and Von-Neumann Architecture acts as a DFA. Computers act on a single state at any one time, moving only ever one edge on a abstract state graph at each operation.
People generally are considered NFAs that can operate on multiple states and decompose states, and have a wider range of problems in the types of problems we can solve.
This is abstract but the gist is, the computer follows an abstract rail of decisions that is really quite dumb, but necessarily so, and it doesn't halt or runaway except with bugs, because we preserve properties limiting the math to areas where it cannot have the problems except outside the working environment (i.e. power loss, hardware failure etc).
There's a reduction to an abstract algebra system inherent in the architecture by preserving certain properties in the design. You first run across this paradigm in first year EE (Systems and Signals) and a course is available on OCW if you haven't taken that, detailed knowledge is not needed though unless you plan on designing these hardware systems.
Any time you have an underlying state that is both true and false given the same state (the message), and in adversarial environments the property requirements for computation are broken. This can naturally occurs in any communication system, and the hoops we have to jump through that we add on in the form of requirements is defining a way to differentiate that hidden state indirectly by the presence of the requirements which good actors follow more closely than bad actors. This is decomposing the state in structure from an NFA type problem to a series of DFA type problems as I'm sure you might recall from your Compiler Design Courses (if you've taken them), or learned from the Dragon Book.
Any message sent must be sent in an identical structure. Any bad actor will adapt to ensure their messages get sent through flooding and raising the noise floor. Any good actor will adapt in a number of ways sometimes by no longer using a system that doesn't provide benefit. You can only operate on the same state.
If you can only process and interact with the message structure itself. No computation system will ever be able to skew what is sent or received so that only the legitimate messages are sent, and the illegitimate ones aren't. Everything goes through the same point. With everything going through, the noise floor is so high nothing gets through, and communication is the sharing of meaning/signal between two parties, people adapt and abandon the system for systems that work.
The core issue is a fundamental computer science issue.
When a computer hardware system first boots up, the bringup stage in hardware sets up the constraints needed to do work. Ask yourself what about the design of computers today prevents the classic unsolved computer science problems and you'll find this staring back. Halting and Decidability (usually).
There are impossible to solve problems, because we've proven that math is incomplete, which impacts on decideability.
Computers work on specific principles, and when you don't understand or know how those work you can easily jump to magical conclusions that simply do not work or have a basis in reality.
A very simple example of this same problem demonstrates this. You are given two spreadsheets without distinct (unique) names. You have 10,000 rows of employees, and you have a list to deactivate 400 people's accounts in an hour, the list of people to be deactivated is by name. You have a script to do all that's necessary for that for individual accounts given a specific account, but some of those people's names are identical to others, and they are different people. The first match you happen to see is the CEO.
How do you solve this?
If you pass the names to automation blindly, you'll deactivate people's accounts that should not be deactivated and you get fired. If you don't in the time period alotted, your fired. How do you solve this?
The only possible way to solve this given the constraints is you ask for a list that includes a unique identifier for the people that need to be deactivated, and a matching list to work from and then the automation can work.
If you just did it blindly, the computer would do it blindly. It has no way to know otherwise. The function is a deactivation so it would deactivate every item passed to it, ending in... you are fired.
There is no other way that does not result in you being fired. Fuzzy matching doesn't work because without the identifier you know that one of those two or three needs to be deactivated but you don't know which, and getting it wrong ends in you being fired. This type of problem is called decidability.
You get the same types of this subtle problem all over automation in different forms. Like in Linux with ldd's output, which is why it fails silently when passed to any automation. The overloaded null state means two different things, and its undecidable when it flattens, and if you examine it carefully it breaks regular expressions. Why? That property isn't preserved.
You are used to dealing with the top of the stack where these properties are preserved, unless you or others break them with a bug.
So it seems, to me, that SPF is working exactly as it ought to. Just to be clear, this isn't pure theory or ignorant preference on my part, I've set up SPF for trusted forwarders before.
They serve to authenticate that the sender is somewhat connected to the person who controls that sending domain.
In the end once the letter has left your server, it is _not_ up to you to decide what they do with it. We already have ARC to basically bypass SPF when DKIM is missing. Letters _will_ be forwarded.
SPF is obsolete and weak in other ways as well. A mere IP address is not the proper way to authenticate or authorize anything.
Maybe so! But if I create the SPF record, it should be enforced. If I don't want it enforced, then I wouldn't have created it! I think, though, where we're converging is that, if you have DKIM at all, then you shouldn't even use SPF. Supporting both in DMARC was a hack.
Nevertheless, I think a lot of time and effort is getting expended to slap security on top of the email system of the 1980s but the practical reality is that email cannot possibly work like it did in the 1980s and we need to stop pretending like it can. If I send an email to a mailing list, it shouldn't be passed off as mine when forwarded. Just as hubs have been replaced with switches in Ethernet, so too should blind repeaters be replaced with smart forwarders (this analogy is not perfect). An email coming from a mailing list is a product of the mailing list, not the original sender. It's not like we don't have the Reply-To header! Moreover, internal forwarders for things like spam filtering and virus scanning and corporate domain forests are internal infrastructure problems that shouldn't be treated as something which the sender has to prepare for. Maybe that's too idealistic, but it's not like I'm dying on the hill that we should have rolled out global S/MIME!
As regards DKIM and length extension, I'm not aware of any way to force it off. Yes, its use may be down to "badly configured" servers (ironically, the whole point of it was to handle forwarders), but nearly everything wrong with email is down to "badly configured" servers in the first place!
I think it's actually the exact opposite, it should be possible to keep origin information intact. This lets everyone verify that it's "x through mailing list y" instead of "mailing list y saying it was x". It's a massive difference and lets the mailing list operate separate from the reputation of the content (from some other domain).
> Moreover, internal forwarders for things like spam filtering and virus scanning and corporate domain forests are internal infrastructure problems that shouldn't be treated as something which the sender has to prepare for.
And it isn't. But wanting it to be more difficult is simply not viable.
With DKIM2 coming, that kind-of combines DKIM and ARC, SPF will become even more useless and a hindrance. And signatures will be much more resilient to forwarding even with (some) modifications. This is what the industry wants, not the opposite.
> Maybe that's too idealistic, but it's not like I'm dying on the hill that we should have rolled out global S/MIME!
S/MIME is being revived as well right now. So who knows how it'll go, maybe that's an another thing we'll be getting.
> As regards DKIM and length extension, I'm not aware of any way to force it off.
Just don't use the length tag, then it's off.
They had at one point a persistent downgrade in mail reputation to the point where it was almost impossible to keep a working mail server with them that would be accepted by any major ESP.
They weren't particularly receptive to addressing support issues where their systems were breaking guidelines/RFCs impacting reputation, at least when I spoke with them about one of my servers a year or so back (which I promptly migrated to another provider).
From what I understand, there were egregious issues. Some of the rumors included source address validation not being done allowing DDOS and spoofing originating from these shared servers on the network block, issues with published PTR records, and a few other things. All of which heavily contribute to mail deliver-ability issues.
> They are sending us email, we forward it, Gmail throttles it because it looks like spam and then they don't accept the bounce for example.
If you are acting as a relay and forwarding mail from Google, to another Google recipient, you need to follow the mandatory guidelines.
https://support.google.com/a/answer/81126?hl=en
Naive relaying or forwarding can/will clobber headers, modifying the from header will also set off reputation issues. If you forward you need to be using ARC headers. The milter is a total pain to set up, validate, and get working.
High volume sending also has stringent requirements. You can read all about it at that link.
It was buried in the fine print related to IPv4 exhaustion.
The CFO I was working with was as flabbergasted as I after we'd found out, but I've seen it a few times now, even when there is another option because of a duopoly in an area.