DEV Community: Azeem Javed

My SMTP relay broke DKIM twice. Here's how I found both bugs.

Azeem Javed — Thu, 29 Oct 2026 23:01:15 +0000

I run several small sites on one Ubuntu VPS. Mail goes out through Postfix, gets signed by OpenDKIM, and then leaves through a shared SMTP relay (Hostinger, which sends onward via MailChannels). I don't send directly from the VPS because a fresh IP has no sending reputation.

DKIM looked fine on paper. opendkim-testkey said key OK. The mail log showed DKIM-Signature field added. And Google's DMARC reports still said dkim=fail.

It turned out to be two separate bugs, with the same cause: the relay changes the message after I sign it.

Bug 1: the body changed

The first failure came from website contact forms. Their emails had long lines and were sent as 8bit. On the way out, the relay re-wrapped those long lines. The body changed, so the body hash (bh=) no longer matched, so DKIM failed.

Fix: send the body as quoted-printable. QP lines are already short (76 characters), so the relay has nothing to re-wrap. In PHP:

$qpBody = quoted_printable_encode(str_replace(["\r\n", "\n"], ["\n", "\r\n"], $body));
// header: Content-Transfer-Encoding: quoted-printable

After that, some domains passed. One still failed.

Bug 2: a header changed

This one was harder, because the body hash was now correct. In Gmail's Show original, the bh= in my DKIM signature matched the bh= in Google's own ARC signature. So the body arrived untouched, and the problem had to be a signed header.

My signature had h=From:To:Subject:Date:From. I compared the headers I sent with the ones Gmail received:

Sent: Date: Thu, 29 Oct 2026 22:17:14 -0000
Received: Date: Thu, 29 Oct 2026 22:17:14 +0000 (UTC)

Same time, different text. The relay had removed my Date header and added its own, in its own format. And Date is a signed header, so one changed character breaks the signature.

Why only some emails? My website forms (PHP mail()) never set a Date header. Postfix adds one in exactly the format the relay uses, so the relay's rewrite produced identical text. Only my Python scripts set their own Date with email.utils.formatdate(), which writes -0000. That's a valid date, just not the same string.

How I proved it

I sent test emails to a Gmail inbox and checked Show original on each:

Test	Date header	DKIM
A	own, `-0000`	FAIL
B	own, `+0000`	FAIL
C	none (Postfix adds it)	PASS

Even a "correct-looking" +0000 failed, because the relay also appends (UTC).

The fix

Don't set a Date header in scripts that send through the relay. Let Postfix add it. Postfix writes it in the same format the relay produces, so the signed text survives.

The other option is to stop signing Date in OpenDKIM (SignHeaders). I didn't, because Date is one of the headers the DKIM spec recommends signing.

What I'd check first next time

Read the DMARC aggregate reports. They tell you which selector and which source IP failed.
In Show original, compare your bh= with the receiver's ARC bh=. If they match, the body is fine and a header changed.
Diff the headers you sent against the headers received. Any signed header that differs is your bug.
Remember that a relay can rewrite both the body and the headers.

Mail still got delivered the whole time, because my DMARC policy was p=none. But a failing signature is exactly the kind of thing that quietly moves you into spam, and I'd rather find it from a report than from a client who never got my reply.

I'm Azeem. I build and fix web systems (WooCommerce, Stripe, AI features) at jeemmo.com.

How I stop an LLM from hallucinating in production (RAG + entity-match + MCP)

Azeem Javed — Sat, 12 Sep 2026 12:24:40 +0000

How do you make an LLM answer questions about real-world entities — companies, people, records — without it confidently making things up?

I build Verivello, a live AI agent that answers questions about any UK company from official registers (Companies House, HM Land Registry, FCA, The Gazette, sanctions lists). In that domain, a wrong director or ownership figure is worse than no answer at all. So "don't hallucinate" isn't a nice-to-have — it's the whole product.

Here's the system design I use to keep an LLM grounded in production. No prompt-magic, no fine-tuning. Just architecture.

The problem

LLMs are fluent, and fluency reads as confidence. Ask a model "who is the director of Acme Ltd?" and it will happily produce a plausible name — whether or not it actually knows. For casual use that's fine. For anything a business acts on, it's a liability.

The usual first instinct is "add RAG." Retrieval-augmented generation helps, but on its own it isn't enough: retrieval can pull the wrong record, and the model can still paraphrase it into something subtly false. Grounding is a pipeline, not a single step.

The system at a glance

flowchart TD
    U[User question] --> C[Classifier: intent + entity]
    C --> R[Engine router]
    R --> T[Tool / function-calling loop]
    T --> M[MCP tool servers]
    M --> S1[Companies House]
    M --> S2[Land Registry]
    M --> S3[FCA / ICO]
    M --> S4[Gazette / Sanctions]
    S1 & S2 & S3 & S4 --> V[Grounding layer:<br/>verbatim output + entity-match]
    V --> A[Streamed, source-cited answer]
    A --> U

Two rules in that grounding layer do most of the anti-hallucination work.

Rule 1 — Verbatim tool output, not model memory

The model is never allowed to recall a fact about an entity. Every fact in an answer must come from a tool call whose raw output is passed through unchanged. The model's job is to explain and cite retrieved records — not to know them.

Concretely:

Tools return structured records (JSON), and that JSON is placed in context verbatim.
The system prompt instructs the model to answer only from provided records and to cite them.
If a fact isn't in the retrieved records, the model must not supply it.

This one rule kills the most common failure mode: the model "filling in" a field from training data.

Rule 2 — Entity-match verification

This is the rule most people miss. Name-search APIs happily return a record for a query — often the wrong one. Search "Smith Consulting" and you might get any of dozens. If you feed that straight into context, you've grounded the model in the wrong company. Now it's confidently wrong with a citation, which is worse.

So before any record is allowed into the grounded context, it's re-verified against the entity the user actually asked about. Illustrative shape (not production code):

// Reject records that don't actually match the entity the user asked about.
function verifyMatch(query, record) {
  // Strongest signal: exact identifier match.
  if (query.companyNumber && record.companyNumber) {
    return query.companyNumber === record.companyNumber;
  }
  // Otherwise: normalised name + a corroborating signal.
  const a = normalise(record.name);
  const b = normalise(query.name);
  return a === b || (similarity(a, b) >= 0.92 && sameIncorporationYear(query, record));
}

// Only verified records are allowed into the grounded context.
const grounded = toolResults.filter(r => verifyMatch(query, r));

Mismatches are dropped, not shown. The model only ever sees records that provably belong to the queried entity.

The golden rule — fail closed

If nothing verifies, the agent says so. No verified record → an honest "I don't know," never a plausible guess.

This is a product decision as much as an engineering one. In due diligence, a confident wrong answer is the expensive failure mode — far more costly than an honest gap. So the whole pipeline is built to fail closed: when in doubt, refuse.

Why MCP for the tool layer

Each data source is exposed as a typed Model Context Protocol (MCP) tool server. That gives a few real benefits:

Isolation & testability — each source is an independent server with a typed schema, unit-testable on its own.
Reuse — the same tool servers work across clients (Claude Code, Claude Desktop, the product itself).
A clean boundary — the model requests what it needs; the tool layer owns how it's fetched and verified.

I open-sourced a small, keyless example of this pattern — an MCP server exposing UK public-data tools, with unit tests + CI — here: github.com/cavitnation/mcp-uk-tools.

Takeaways

If you're wiring an LLM up to real data, grounding is a pipeline:

Verbatim tool output — the model explains and cites; it never recalls.
Entity-match verification — prove each record belongs to the queried entity before using it.
Fail closed — no verified record, no answer.
MCP tool servers — a clean, testable, reusable boundary between model and data.

That's the difference between a demo and something a business can actually trust to act.

I wrote up the full architecture (with the diagram, no product code) here: github.com/cavitnation/verivello-architecture. I build production AI and backend systems like this for clients at jeemmo.com — happy to talk shop in the comments.

Hi DEV — I build backend-heavy web apps

Azeem Javed — Tue, 08 Sep 2026 10:38:02 +0000

I'm Azeem — I build backend-heavy web apps solo as Jeemmo, since 2011, for UK / EU / US clients.

What I do: custom web apps, real-time features (WebSockets), Stripe / payment integrations, rescuing old PHP, and making slow WooCommerce stores fast.

Stack: PHP / Laravel, Node.js, Python, MySQL, Redis.

A few things I've built:

ArchStudent — content platform for architecture students
Quran Roshni — fast, ad-free Quran reader (~30 languages)
World Hot Springs — data-pipeline world directory
GoodPing — free network tools + uptime monitoring

You can see more of what I build at jeemmo.com.

Are coders still getting hired now that AI can write code?

Azeem Javed — Fri, 31 Oct 2025 21:49:12 +0000

Wordpress theme development - version update function

Azeem Javed — Sat, 03 Jun 2023 12:00:31 +0000

Hello,

how to add wordpress theme update function in source files? do i need to add a code in function.php ?

is there any standard code to add? what other files i need to add update functionality code?

i want to do this.
1- I will take wordpress standard theme files from underscores.me and make it as version 1.0
2- Make some fancy work on it, i will make Landing Pages/sub pages.
3- Make theme documentation for users to read and install.
4- upload on envato market.

So after 2-3 months if i upgrade my theme as in version 1.1
so how i noptify this to my envato users? where i need to add code in my theme for this function?

I know i can take api token generate from envato api website and update this in envato plugin in my wordpress dashboard.

is there anyone doing the same job or have done it?

Please guide
Best Regards