For me, as someone with their own mail server, these technologies mostly serve to inform me that Russian IP addresses are still trying to send email in the name of my domain for some stupid reason.
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.
The problems I noticed were, it doesn't matter what the SPF and DKIM look like. If Google or Microsoft refuse to relay your email based on secret internal factors then you're out of business.
Best, and often practically only, way to avoid this problem is to buy your email services from Google Microsoft duopoly.
It wouldn't shock me if an email services monopoly/duopoly would prefer email spam's only workaround to be signing up for their services, instead of fixing the root of the spam problem.
Workaround (?) Buy their services for 1 (one) year and then move to something good (?)
Microsoft seems to be the most common culprit.
Agree.
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.
I think they cannot be bothered. Their customers are more tied in than Google's and are not going to switch because a small proportion of emails are rejected.
More specifically they seem to rely IP reputation rather than domain reputation, and IPs do change hands, especially for smaller servers.
Yes, and they do that routinely.
This attitude is just FUD.
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.
MS flat out refuses to unblock our IP on their "outlook protection" racket despite many attempts through their self-service website.
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!
In my experience, MS and others give you a chance to correct the issue and if you don't do so in a timely manner (which requires qualified help), or it isn't corrected, then you get blackholed thereafter, and will remain that way up to years afterwards.
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.
>The literature is a way of adding cost to those that would send spam, it also adds cost in other ways.
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.
You are categorically mistaken and lack a true understanding of these things.
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.
>You are categorically mistaken and lack a true understanding of these things.
>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.
Thanks for the details! (It's not a residential IP, it's a VM at Hetzner.)
>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.
If its Hetzner, they have a bad mail reputation as a result of failing to address issues with their shared resources in a timely manner.
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.
I'm confused. How could CGNAT affect a static IP?
The ISP had set it up so Egress traffic on the static IP was shared and included other residential traffic, and Ingress may have been mirrored or segmented by MAC.
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.
> The IP doesn't change, so technically it's static. We never said it was exclusive.
That's a pretty wild take. Was there no alternative ISP?
Not in that particular locality, the only alternative was cellular with a cradlepoint at 10x spend for 1/2 the bandwidth, and connectivity issues in bad weather.
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.
> Russian IP addresses are still trying to send email in the name of my domain for some stupid reason
For what it's worth, I've started seeing cybersecurity insurers requiring riders and extra payments if you don't block Russian IPs.
But there are big problems with mapping from IPs to countries. My IPv6 is detected as Russian, though it is London-located tunnel exit point and I'm in the Netherlands.
If your HE tunnelbroker account's country is set to Russia, you'll show up as from Russia for Google since HE publishes a geofeed of ip range -> user account country for them.[1] You should be able to change it on the settings page.[2]
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
If it is a tunnel, then it might have been used by someone else before.
Those "London oblast" jokes don't come from nowhere.
Sounds like an issue with an outdated locally hosted IP2 Location database.
Google thinks it is in Russia too. And Cloudflare thinks the same.
If it's Hurricane Electrics tunnel I've had similiar issues, I think they use Russian blocks for their IPv6 tunnel since the abuse potential is so high and they don't want to deal with it so they just bundle all their shit with Russia and move on.
maybe you actually have a MITM proxy stealing all of your traffic and keystrokes
Sounds more like IP isn't a reliable factor to determine location. Not that this would be bad though.
Ive got a server hosting a number of things, amd monitoring setup for a lot of stats. Got tired of seeing blips because various countries were beating on my server, not a DoS, but enough requests to notice, and sometimes generate an alert. I blocked 7 countries, in full, and the impact was fantastic. No more 2gb of logs generated every day by countries that have no business accessing my server.
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.
I'm the CTO of a US-based insurance company. Apart from some reinsurers in London and Bermuda, and a couple contractors in Canada, we don't do business outside the US. We've blocked all countries except those, and it has cut down massively on the folks attacking us.
Lots of companies do this on their websites now using cloud flare or something similar. It’s practical. Still it’s frustrating as a user when you’re traveling over in Europe and can’t access your accounts to pay bills or whatnot.
Next time I travel overseas I'll have a VPN ready.
My bank had some technical problem that prevented access from overseas last time I traveled and I couldn't access my account (which was extremely inconvenient).
Most banks that will work with. For what ever reason the bank I now use knows most vpn providers and completely blocks all traffic from them so using a vpn is not an option either. The “vpn” I’ll have to use is tunneling back to my home ip. It’s actually quite frustrating.
Commercial VPNs are often blocked too. I found a p2p vpn to my home network + ssh socks5 proxy to work well.
Have you considered the additional cost of making it harder for your customers to do business with you, as well as the limited visibility that you set up for attacks that may become multi-stage in nature later?
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.
As someone who has whitelisted only US IP address space for my employer and blocked everything else I can attest that is DRASTICALLY reduces hostile traffic to us. I have an RDP honeypot that was blocking dozens of IPs every day before the whitelist and now it blocks 1 or 2 a day.
Kinda similar, but when I looked at the finances, I was surprised by how much money we're getting from places like the Cayman Islands, Switzerland, and the Emirates.
> I blocked 7 countries
Russia, China, Nigeria, Romania, North Korea, Iran and Belarus [1]?
[1] https://www.ox.ac.uk/news/2024-04-10-world-first-cybercrime-...
How/why did you pick these 7?
Using your link: Ukraine, USA, UK, Brazil, & India all rank higher than Iran and Belarus. US & Ukraine rank higher than Nigeria and Romania.
We (a US org) block all countries listed on the OFAC list
https://ofac.treasury.gov/sanctions-programs-and-country-inf...
Those countries likely have a higher chance of real traffic as well. If I’m doing business in Nigeria then obviously I can’t block it even if it ranks high on the threat level.
Yes, obviously you don't block the countries you plan to do business with. I got that much.
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.
Let me throw out a guess: Ukraine is a wartime ally, Brazil is the seventh largest country in the world, India is the first, and the UK speaks English and has a lot of connections to USA.
They're each also popular IT outsourcing destinations who aren't sanctioned. You may not do business in Ukraine or Brazil, but chances are one of your customers or contractors do, and blocking those IPs isn't usually in the first or second swipe. (If you're blocking the UK and India, you're probably blocking all foreign IPs.)
Romania!? I did a double-take, as it is a member of the European Union. I would think if their cyber-reputation was so terrible, there would be pressure from inside the EU to fix it.
They’re a small economy with lots of hostile traffic, so while in the EU and not sanctioned like the rest of the bunch, I’ve commonly seen them on the chopping block.
Pretty close tbh. Sub romania for brazil, and nigeria, for... i dont remember right now
just close the tcp sockets and you wont even notice them trying to connect and failing
do you also log everyone who looks at your house? it's a self inflicted problem
At least in the case of VPS my experience has been 99% failed ssh attempts. I just use nftables to rate limit those to 2 failed attempts per minute. Log size is quite modest and can easily filter out failed attempts when viewing.
Ok but you can’t block someone else using their own IPs to send email.
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.
As a non-email guy, I can tell you that if a system that boils down to having an (optionally certified?) key requires much more than just putting it into a folder with a domain name and running a service, it’s badly designed and has unnecessary complexity. Which will result into abusers having more expertise than legitimate users. The fact that you can “get” DMARC SPF DKIM wrong, while it’s basically a hard requirement for operation, is just screaming something important to the email software.
As a generalist admin, would you say the same about DBA operations or would you say that's just not my specialty?
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.
Frustration doesn't come naturally. It comes with shitty software design.
"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.
You are mistaken. Your reasoning is flawed because the heuristics you use are flawed, and the consequences of the heuristics are the reason you are frustrated.
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.
To summarize. His complaint is common tasks involving commonly used software that are fairly simple but the software remains obtuse for some reason.
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 read that right for the most part except you missed important nuance.
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.
Sure, I won't disagree that there exist plenty of unqualified people doing things wrong while pretending that they know what they're doing. That seems obvious enough in the general sense.
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.
Communication as a whole, not just email. The failures to address this, point to an inherent limitation of the systems we've built for computation. You'll have to revisit automata theory, and have some knowledge of why CPUs are able to do work at the lowest levels of abstraction.
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.
You’re just arrogant here imo, and I regret the time spent on elaborating. Your comment is straight from the 25 years ago when it was normal to read toxic lectures to lame noobs on forums and create software that has no last mile connection to reality. I’m glad that that era is long over except for a few remnants. Have a regular day.
You have willfully blinded yourself to opportunities that if taken to heart could have prevented yourself a world of suffering.
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.
In most organizations there is no point in a sysadmin to spend the effort in understanding how to set it up correctly as Marketing has got more authority on email. Marketing will simply demand changes to the config that they do not understand and there is nothing you can do to stop it as they will have the CEO on their side.
> Marketing will simply demand changes to the config that they do not understand and there is nothing you can do to stop it as they will have the CEO on their side.
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.
It's amusing to see this advice in this thread contrasted with the recent Troy Hunt phishing attack thread where folks are complaining about companies like Microsoft having dozens of varying domain names.
> […] about companies like Microsoft having dozens of varying domain names.
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.
This is email marketing 101, HN'ers are massively overstating how many domains are getting blacklisted because of "marketing".
Orgs like that will hire consultants like me when they can't figure out why their stuff isn't landing in the inbox. Then 3 months later their webdev will somehow delete the entire zone when adding their A record.
You mean like the time I had a salesperson demanding that we turn off Cloudflare across our entire domain because he'd read some random article somewhere saying we should?
The goal of sales isn't to block upto a 1/3 of world wide traffic. Turning off Cloudfare means more traffic and more sales are not blocked. Did you even read the article or did you dismiss it because it came from 'sales'.
Sales: "look, I turned this off and sales went way up"
Security: "We had to cancel every single one of those sales because they came from stolen credit cards. It's costing us more to deal with that then we are earning"
Accounting: "We're measuring a pretty big loss because security cancelled legitimate purchases together with fake ones and now clients are leaving."
Which is another reason to strictly enforce SPF and DKIM, in my book. Let marketing break those policies, that way I don't need to bother with reading your company's spam!
Marketing decides on DKIM and SPF ?
The problem I personally ran into as a one person IT department was that the VP of marketing had more power over me, as a manager, and that meant more to my supervisor (the CEO) than me fighting to do things as correctly as possible. I was seen as a roadblock or speed bump. So, they may not decide on DKIM and SPF, but if marketing isn’t happy then their negativity could cause push back that forces changes that may technically not be good for the company.
I’ve abandoned that role and have gone back to an IC role and I’m much happier for it.
As long as you're not breaking the law / hurting people, does the struggle really matter? The best way I've been able to make people listen to me is by just presenting them with options and results.
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.
In the end, for me personally, I give people respect for their roles and the benefit of the doubt that they're in the position for the right reasons. But when I don't get that kind of thing in return then it just pisses me off. What I realized along the way is that I don't want to be in charge of things like this, it's simply not for me, at the very least it isn't on that team. Maybe that will change with the right people but the whole thing soured me on management in general and I will avoid it like the plague.
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.
The biggest problem there is that it's a statistical gamble, and often times the damage isn't apparent for months or years later, which is plenty far enough removed from the decision that the manager isn't going to remember let alone realize "he told me so." And you reporting "I told you so" even in very easy, factual, and respectful professional language will typicall not be well received. There's also a decent chance that when the thing breaks or you get breached, you'll be blamed for it, or at least be on the defensive.
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.
Indirectly, yes. Since they don't understand the details, management just "wants it to work". So too many email admins just give up and make their sending policies as permissive as they can to account for whatever new service marketing is using at the time.
DMARC is required for BIMI, and marketing wants that logo to show up in the Gmail app next to your mail
even worse when you have even less control than that, if you run some type of hosting and are trying to convince non-technical clients (or even worse, non technical clients who think they are technical) to “please just add this record exactly as it says here to your domain” and they’re somehow unable to for months and months
> "please just add this record exactly as it says here to your domain" and they’re somehow unable to for months and months
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.
That’s a wild story, thanks for sharing - I find interfacing with external IT teams extraordinarily frustrating. I suspect it’s because businesses often don’t manage their IT teams well or have a good process to expedite business -> IT requests that really should be super easy and provide a lot of tangible value for the amount of comparative effort involved.
I’ve run into outright malicious stuff internally like this, but never externally - I would probably go apoplectic if I was your friend
to be fair here: for a lot of companies, if the mass mailing stops, the money-flow stops then that's no good for anyone... so the CEO will probably err on the side of money, presumably.
Why would properly configuring SPF, DKIM, and DMARC stop the mass mailing, though?
As someone who set these up, I can tell you, the answer is rather simple:
- 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.
> that Russian IP addresses are still trying to send email in the name of my domain for some stupid reason
You can set your policy to reject, that will deter the Russians from using your domain.
I used to have my policy set to reject, but then I found out some part of an Enterprise Outlook mail filtering chain was rewriting the mail I sent before checking the DKIM signature. I can't fix stupid, especially for other parties, so I changed the policy to quarantine instead.
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.