This method, often described as spoofing, is the root cause of most of the phishing attacks globally. Phishing is an attack that tricks the user to click on a link or form inside an email and fill confidential information including passwords and other personal information. Phishing has resulted in over 100 billion dollars of collateral damage for corporations globally in the past decade, estimates by IBM.

To prevent spoofing, and also to ensure that Phishing is prevented, technologists have developed over the past few years several mechanisms and standards that protect email systems from attacks. These mechanisms also improve email security and delivery.

However, these mechanisms also act as a double-edged sword. Sometimes they result in false positives, and well-intentioned emails end up in spam boxes.

It gets even more complicated when you are running a multi-domain routing solution and understanding the underlying technologies, mechanisms and protocols are very important for a successful messaging platform implementation.

Let’s try to understand the basic building blocks first.

Domain Name – This is the fundamental identifier of an email. It’s the identifier after the ‘@’ symbol.

MX Record – A mail exchanger record (MX record) is the address of the mail server responsible for accepting email messages addressed to a domain, that's configured in the Domain Server management system. You can have one or more MX records, each pointing to a resource where a mail server exists. Multiple MX records help you load balance mail service and also provide redundancy.

Till a decade back, you only had to worry about MX records and whether they are pointed correctly, and whether servers are load balanced the right way.

But with phishing, spamming, spoofing and other modern attacks we need to now worry about other ideas too.

Central to these are three technologies which are DMARC, DKIM, and SPF which are essentially email authentication methods. Also important are ARC and BIMI, which also helps provide legitimacy to the email. A domain can list all the servers they send emails from via Sender Policy Framework (SPF). Imagine this to the page on a bank website that lists all the branches of the bank with their official telephone numbers. And you can always refer to this page, and verify whether a call from the bank is calling from an authorized number. Since SPF records list all the IP addresses of all the servers that are allowed to send emails on behalf of the domain, it’s a very good way to rule out a rogue mail server. While SPF does a good job of identifying whether the source is authentic or not, it still it’s not good enough to verify whether the email is authentic or not. Think of it this way. You verified that the number belongs to an authentic branch of the bank, but still you cannot be sure whether the person on the other line is a bona fide employee of the bank whom you can trust. In the real world of messaging frauds, hackers find ways to spoof incoming mail by manipulating the headers to change an IP address to match those found in the SPF record of the domain. This is tricky but a good hacker can achieve this very easily.

DKIM to the rescue

To prevent such IP spoofing, domain owners use DomainKeys Identified Mail (DKIM) to sign emails from the domain. This is a digital signature that uses cryptography and verifies that the email did indeed come from the domain. DKIM records store the domain’s public keys. Private Keys associated with the domain are sent as part of email headers. When an email is received, the recipient server can verify the sender’s public key against the private key sent via the message. The signed key sent is like a signature on a check leaf which a teller or a clerk can verify. It gives additional security to the SPF check. DMARC after SPF & DKIM is checked Domain-based Message Authentication Reporting and Conformance (DMARC) instructs a recipient server what to do after checking SPF and DKIM. A domain's DMARC policy can be set in several ways. You can quarantine emails, or even bounce them. A DMARC record can also send reports to domain administrators about DMARC activity, and parsing mail administrators can fine-tune policies, or understand security threats. DKIM, SPF, and DMARC records are always stored as DNS TXT records. A DNS TXT record stores text that a domain owner wants to associate with the domain. Since these records are textual it can convey a lot of information.

ARC and BIMI

While DMARC does a good job of handling emails that fail SPF and DKIM authentication, in cases of distribution lists and forwarded messages, there can be false positives. Authenticated Received Chain (ARC) is an email authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing. ARC is still not accepted by all mail service providers, as the ARC signing mechanism can be counterfeited too. But it does provide a mechanism for accepting emails that fail SPF and DKIM checks. Brand Indicator Message Identification (BIMI) is another standard that improves your brand visibility. Your BIMI record is a line of text that includes the URL of your brand logo Scalable Vector Graphics (SVG) file and can be again included as a DNS TXT record. Remember even BIMI can be counterfeited. Why manage these mechanisms? Netzary offers fully managed services for managing these mechanisms including analyzing and parsing DMARC messages and providing you insights into attempts of phishing and other security threats on your domain. If you are a customer of our Hybrid email services cutting across different mail services, you get this service free of cost.

Hence to improve your brand appeal, mail deliverability, overall security and business compliance pay attention to these pillars. Talk to us for a free consulting assignment to get your email platform on steroids.

S Ramdas is the founder of Netzary Infodynamics. You can reach him on ramdas@netzary.com

Caveat: In most cases when customers come to us with burgeoning AWS bills, we generally send them in two directions.

The first is to go multi-cloud or for a combination of cloud and on-premises, the original hybrid route.

Or step away from AWS completely. Mind you AWS is expensive. It's like buying a high-end Mercedes or a BMW car. However, if your need is the best performance, scalability and security, stay on with AWS.

I generally do not recommend a shift from AWS to Microsoft Azure or Google Cloud unless there's a service that makes a huge difference that's proprietary to those platforms. And there are a few.

Also if a customer has Enterprise Agreements signed with Microsoft, then there are several licensing benefits they must consider switching to Azure. Cost savings in Azure or GCP most of the time will hardly be worth the effort of moving out of AWS. The right move is to cost optimize.

I generally push customers to other cloud providers or compute models where the bills are halved. More on those in a later article.

So this is generally a guide for you to cut your bills by staying on with AWS.

Reduce Dependency on AWS Proprietary Technology

This is something I tell every customer irrespective of whichever cloud they opt. Do not invest heavily in any proprietary service. They will start very attractive, and extremely easy to set up. But then there's always a catch, and you will see the bills soaring very soon.

It's a very difficult choice to abandon them. Take for example AWS RDS. It takes a developer a few minutes to set up everything and maybe an hour to fine-tune it. In comparison, a solid MySQL/Postgres SQL cluster could take a few days to optimize, and you also need to plan backups and other housekeeping activities.

RDS is a great boon for someone looking at scaling fast, and who needs auto-scaling and scaling down using simple rules.

However, in many cases, a rethink in architecture helps. We have been successful in cutting down the bills on a bunch of RDS instances by 60 percent by moving them to a Percona cluster recently. No significant change in performance or durability.

Choose your plans wisely

I generally ask certain questions to my customers. These inclde Why cannot a dev cluster be on spot instances? Agreed it's not stable. And if it goes away you are not going to lose much. But then your CFO might start loving you.

Unless you have developers sitting up late at night and pushing code, dev clusters need not run 24x7. It’s worth scheduling on/off times for anything which is not in production. AWS does provide you with all schedulers needed.

If you see anything which can be remotely predictive, please consider a longer-term contract. It brings bills down drastically. Reserved Instances can end up being major savings. However, do read the next point.

Get the sizes right

Every cloud provider prices their products based on an amortization calculation on their hardware acquisitions. AWS price drops are also a result of these number crunching. However, not all instances with the same VCPU count and RAM are born equal. At the time of writing these AWS is running six different generations of Intel processors alone across their various instances. There are several instances from AMD's 4 generations of processors, and then there are ARM processors.

Also, some of the newer instances do not suffer from the noisy neighbor problem as much as older T2s do. Hence right-sizing instances, identifying processors used to create them and profiling your applications for the same is very important.

These permutations and combinations cannot be easily explained over an article. This requires proper consultation, and you will need to speak with experts before you freeze on these choices.

Observe and Determine

Observability is a recommended virtue for all modern application platforms. Observability is not about a bunch of AWS Cloudwatch entries that will further increase your bills. This is about choosing the right parameters to study whether it's an HTTP(S) response to a request by a front-end asset, or system loads of an instance.

You will need to observe and learn consistently, and that practice will further help you optimize workloads.

This should have been right on top of the list.

Scrutinize monthly bills with the devops or cloudops team

At Netzary we make it a practice to look at all cloud bills every quarter along with members of the DevOps team. And we have been able to identify assets that we do not use, or should have been killed, stopped or discontinued. We are moving the practice to monthly, and you should do that.

In AWS you will see unused EBS Volumes, unattached reserved IPs, and snapshots that should have been deleted months back. You are also likely to notice services that should have been unsubscribed long back. This is sometimes very boring work, which might test the patience of your engineers. However, this is something you should bring in as a practice.

Know that there's an option to generate credits

Let me share a confession shared by a senior AWS sales guy. AWS is equally paranoid about losing you as a customer because of higher bills, and they will be happy to give you the benefits for a reason.

The reason, however, is important and since any rebates or credits need system approval, and validation you will need some expertise to present it to your account managers.

AWS has a bunch of very smart people, and they will consider so many aspects before they let you go. Of course, for all that you need to be a reasonably heavy customer for them. And that number differs from market to market.

In a market like India where we operate, that number can be as low as $ 20,000 a month to work with you to ensure your bills are lowered.

They will also analyze your bills to check and see how easy it will be for you to let go. If you are locked into many services, then your credits may not be as high as they would be. Because they know it’s tough for you to switch.

Migrate to Kubernetes

I assume if your bills are high, you are running multiple servers. In case the number of servers you run is more than 5, you must consider Kubernetes and containerization. AWS has one of the best-managed Kubernetes platforms. Immediate savings may not be much, but down the line when you expand and grow you will see benefits. If you see yourselves growing, this move will help you cut down the future bills.

Rethink Multizone architectures

For top reliability and availability, every AWS Best practices guide recommends multizone deployment. This indeed ensures the results, but be warned, this comes at a cost especially when you are running complex workloads.

We learned this by burning our fingers. A recent deployment AWS Kubernetes cluster saw bills scaling with multizone availability enabled. AWS bills you for traffic as well as API calls between zones, and this can hurt your pockets.

Before you enable multizone availability, consider the use case and see the cost implications. If you still are not sure, do talk to an expert.

Analyze the lesser-known costs

AWS like other cloud providers does not advertise certain details on cost. For example, take AWS S3. Apart from the storage costs and bandwidth costs, there are minor costs around various web request methods such as POST, PUT, GET etc.

Few developers consider these aspects, but architects need to look at these details carefully before approving the service or rollout.

Some of these are not easy to do. In case you need any help please feel to drop a line to info@netzary.com. Our first round of consulting is always on the house.

Also do check our website on these services. We doS provide a wide range of development and managed services

S Ramdas is the CEO of Netzary Infodynamics.

Netzary has been supporting customers on Kubernetes for the past 2 years, and we see Kubernetes as one of the most important pieces of infrastructure software that has emerged in the past decade.

I am presenting the salient points we covered in the webinar on the real business impact of Kubernetes.

What is Kubernetes?

Kubernetes is defined as per the Kubernetes web site as a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation.

At the beginning of the web revolution to be precise during the dot com boom and burst of early years of the millennium the idea of virtualization was still alien. We used to run cluster of machines each running an operating system with applications talking to each other to handle larger traffic. Late nineties most websites did not even have functional databases, and were essentially a bunch of web pages designed in Macromedia’s (later acquired by Adobe) Dreamweaver and Microsoft’s FrontPage software. Then databases emerged and we started splitting workloads into app servers and database servers, with middleware thrown in with emergence of applications such as JBoss.

However server utilization patterns were still a question mark. You either ran servers which were under utilized or where over utilized.

However with emergence of virtualization, the idea of virtual private servers emerged, and you could compartmentalize a server into multiple virtual machines, and this drastically improved CPU utilization and other resources. With multi core architectures emerging and with Intel and AMD shipping every year a processor with more cores inside than the year before, costs of computing also reduced.

VMs vs Containers

While VMS compartmentalized hardware into smaller pieces, and server utilization improved drastically, there was still room for improvement. Emergence of containers that can host applications emerged in the early part of last decade. Containers enables you to separate your applications from your infrastructure so you can deliver software quickly. Docker perhaps the world’s most popular containerization technology captured the imagination of developers and soon there was a container revolution. However, a platform which would manage containers and orchestrate them across a myriad of virtual machines or servers was missing. With Google open sourcing Kubernetes which was based on Googles 15 years of running web infrastructure.

With Kubernetes you can literally deploy and launch hundreds of containers in reasonably configured hardware, and keep spinning up more containers across a network and even across different cloud platforms as workloads increase.

While a physical server can take several hours and even days to fix and replace, VMs can be spun off from another hardware in a few minutes to a few hours depending on the size and resources needed. Containers being of smaller sizes and lesser resources can be spun off in seconds if they crash.

Hence for applications that require both scalability and uptime Kubernetes is a big boon. Over a period of time you are able to also plan your infrastructure and utilize the resources better with Kubernetes.

In the next article, I will talk about the type of applications that you need to target for a Kubernetes deployment.

The whole presentation is available for download from our website from this link

S Ramdas is the Founder-CEO ofNetzary Infodynamics

One of the biggest challenges has been the steep learning curve associated with some of the frameworks. However once mastered developers seem to become more productive and hence able to deliver better.

Also this is helping us take the microservices path, and hence ensure code reusability, and cost gains.

However, this approach is not the best fit to every project. Every app we write doesn't need vast scalability or performance gains that the decoupled approach offers.

Also decent JS talent is expensive which is making our bids less competitive in a very competitive market.

Most of our backend development happens in Pythonic frameworks such as Django, Flask and Fast API. We have a decent Python team which has real world experience of building software for many verticals.

The team is reduced today to writing APIs using Django Rest Framework or pure play Python.

Why did the Reactive Frameworks emerge?

A decade back, we were all happy using Jquery to do web magic. It solved a major problem which was inter browser compatibility. With Internet Explorer dying a natural death, and with Firefox and Chrome becoming the industry standards, the need of just a DOM manipulator was reduced.

Emergence of front end JS frameworks such as Angular, React, Vue among a host of others changed the game. One they used components to build parts of the UI experience increasing ability to reuse components to build a rich UI system. They also targeted the virtual DOM which increased performance.

Most importantly they could take advantage of the rich and diverse JS tool ecosystem which has changed the way you build and deploy front end code. Also with Javascript moving to ES6 standards which have more modern programming concepts. This in turn has attracted more developers to the ecosystem.

However Javascript still remains a fairly terse language compared to Python or Ruby. This is a personal opinion and not to attract any language trolls or fanatics. In addition, programming polyglots are rare in our industry, though most developers claim themselves to be one. Most developers once they reach proficiency in one language, find getting out of their comfort zones difficult. Again, there are exceptions.

How does HTMX and Turbo Hotwire change equations?

Well it does reduce your dependence on Javascript quite a lot if you are already familiar with or proficient with backend frameworks.

They give you access to Ajax, Server Side Events, CSS Transformations, even sockets and data binding basically by manipulating attributes.

Overall reduction of JS code in a project reduces considerably. There’s at least one public presentation of how it has reduced the overall code base by 67% without any compromise in performance compared to a React web application.

I am yet to try Hotwire, but first few days on a new project with HTMX has been very rewarding. Early estimates are a saving of at least 50% in terms of actual code in the project. Right now, the time projected to close the project remains the same to accommodate the learning. And the learning is not steep, compared to any of the reactive frameworks.

We are yet to hear about any major projects abandoning React or Angular and using one of these technologies except for work done by Basecamp with Hotwire.

But I see no reason why HTMX or Hotwire or other Hyper script powered approaches will not be preferred over a Decoupled approach of maintaining two distinct pieces of code unless you are targeting a million plus users.

Our estimates are that we can reduce development time by 30-40% by the next project by relying on HTMX and a sprinkle of vanilla JS, and raise the bar in performance too.

Will this create a dent in Reactive JS frameworks?

No. I don’t think the traction for them will disappear. Considerable amount of money has been invested globally by customers and developers in skills and technology to power these projects. Also the world is moving to edge computing, and JS bundles running from edge servers or CDNs promise a lot. In addition serverless computing is getting cheaper, and could become mainstream in a couple of years.

But a lot of development work is actually building internal tools for enterprises big and small. This is the sweet spot which HTMX will fit in perfectly. My experience so far, which is less than a dozen hours, is good enough to validate that the technology is good enough for Single Page Applications. I still need to figure out the best approach for building a PWA using what’s available.

Low maintenance.

Python projects are comparatively low maintenance compared to work in other languages. Syntactically it’s easier to maintain Python code. Except for a sprinkling of JS code mostly to hook up APIs with Full Calendar our JS code base is less than 100 lines so far in the current project. It might have been 1500 lines of JS/JSX/React code otherwise.

So if your next project is not intended to be the next big thing, or is a prototype for the next big thing, then look at HTMX or Turbo Hotwire. A few hours of learning curve, and you would be writing code.

References

There's a nice youtube channel with a number ofuseful videos on HTMX by bugbuytes.

There's an ebookon hooking up Hotwire and Django with a companion website. I have not read it. But the content looks promising.

The official HTMX webite

The official Hotwire website

A Youtube video of of a presentation from David Gulliot on how they reduced 67% of code base by replacing React with HTMX presented in Django Eurocon.

The article is authored by S Ramdas, who is the founder-CEO of Netzary Infodynamics