Did You Send This - for module phone SMS/Voice

This article is a comprehensive 2025 update to the original 2006 post: “Did you send this - another weapon against spam?”

Applying DYST to Mobile Communication

The original DYST idea could theoretically be adapted by Google and Apple, who could implement it unilaterally for mobile calls and messages. Rather than relying on telecommunication carriers, they could use their existing TCP/IP infrastructure for verification. An app on the sending device would get a temporary token from an Apple/Google server, and the receiving device would check that token with the same central server before alerting the user.

DYST supporting phone or (iOS or Android)

Here is a sequence diagram illustrating the back-channel exchange for a genuine call

If Bob is in the address book, then <bobs phone numb> is replaced with Bob’s name

Here is a sequence diagram illustrating the back-channel exchange for a genuine Apple/Google “Messages” (not SMS)

Apple launched the iPhone with iMessage (for other iPhone users). Google did the same for Android uses, and these days Rich Communication Services (RCS) allows both to interoperate. In the diagram above the teleco’s systems are not shown because they are not involved for the routing of “smart” (non SMS) messages.

Here is a sequence diagram illustrating the back-channel exchange for a fake call

The sequence diagram for messages would look very similar.

Smartphone supporting RCS but not yet supporting DYST (older iOS or Android version perhaps)

Legit call via RCS (no DYST)

Legit message via RCS (no DYST)

Fake caller ID call via RCS (no DYST)

Phone not supporting RCS nor DYST (much older iOS or Android version perhaps)

Legit call via SMS (no RCS, no DYST)

Legit message via SMS (no RCS, no DYST)

Fake caller ID call via SMS (no RCS, no DYST)

Of course a text reply of “No” would be inferred for anyting other that ‘Y’, y, YES, 是, 对, हाँ (haan), sí, oui, نعم, হ্যাঁ , da, sim, ہاں, ya, ja, はい, ndiyo, हो , అవును , evet, vâng / dạ

This system could be enhanced with network intelligence. For IP-based messages, the receiving service’s backend (e.g., Apple’s servers) could perform a traceroute back to the sender’s IP. This wouldn’t reveal the user’s precise location but would identify the network path. A path from a reputable mobile carrier like O2 in the UK would contribute to a “low-probability spammer” score, whereas a path from a data center known for fraudulent activity would raise suspicion, all without exposing the sender’s private location.

A user could configure their device to “block all unverified calls”, “warn”, or perform no checks. However, limitations of this solution would including the risk of blocking legitimate calls if the verification service has an outage and the small delay the check adds to every communication. To counter denial-of-service attacks where bad actors flood users with fake verification messages to create fatigue and distrust, the system would rely on server-side intelligence from the central servers to detect and rate-limit anomalous floods of verification requests.

A challenge remains communication with “legacy users” on older devices. While most phones would handle the fallback SMS correctly, older feature phones (“dumbphones”) in particular might display the verification message as multiple confusing parts or silently drop it due to full inboxes, undermining the system. To build trust for this fallback, a logical conclusion would be for participating companies to form a “Spam Alliance”, complete with a website listing members, and brand the message with this neutral alliance name.

The telcos’ resistance would likely be because their large customers, such as call centers using VoIP, would face significant hurdles. Much of their software may be old and difficult to update to support a new verification protocol. A call center vendor might even configure their system to automatically answer “yes” to all challenges, legitimate or not. This would necessitate another layer of defense, led by the Spam Alliance, to apply reputation scoring to the responders themselves. If an endpoint blindly says “yes” to everything, its attestations would eventually be deemed untrustworthy.

Finally, it is instructive to look at the history of DMARC, SPF, and DKIM for email. These technologies did not eliminate spam, but they largely solved the problem of direct domain spoofing. Similarly, a DYST-like system for voice and SMS would not be a silver bullet for all unwanted communication, but it could effectively end caller-ID spoofing of legitimate numbers, forcing bad actors onto more easily traceable and blockable channels.

Example DYST Messages

As RCS (Rich Communication Services) supports rich cards and suggested actions, the user experience for a DYST-style verification could be significantly improved over a plain SMS fallback.

Challenge (JSON payload) to claimed originator who has a DYST-enabled Smartphone

When the claimed originator’s Smartphone is DYST-enabled, the verification happens silently in the background between the originating service’s server and the handset. This interaction uses a JSON payload, and the handset automatically answers the challenge without user intervention.

Recieving handset sends this JSON payload to the DYST-enabled handset of the claimed originator:

{
  "dyst_challenge": {
    "protocol_version": "1.0",
    "challenge_id": "dyst-challenge-12345",
    "timestamp": "2025-11-29T10:30:00Z",
    "originator_id": "+14155550110",
    "recipient_id": "+12025550148",
    "communication_type": "voice_call",
    "communication_id": "call-abc-789",
    "message_digest": "sha256:abcdef12345...",
    "ttl_seconds": 30
  }
}

Claimed originators DYST-enabled handset responds silently:

{
  "dyst_response": {
    "challenge_id": "dyst-challenge-12345",
    "status": "confirmed",
  }
}

Or if they had not placed the voice call (someone else faked caller ID):

{
  "dyst_response": {
    "challenge_id": "dyst-challenge-12345",
    "status": "denied",
  }
}

Challenge RCS message to claimed originator who has a Smartphone that’s not DYST enabled (a fallback)

This is what the person making the call would receive on their device if the recipient doesn’t recognize them. It’s designed to be simple and quick.

Spam Alliance Verification ✓
---------------------------------------
🛡️ Did you just try to contact `+1-202-555-0148`?

To connect your call, please confirm it was you.

[ ✅ Yes, that was me ]  [ ❌ No, not me ]
---------------------------------------
<small>Sent by the Spam Alliance. [Learn More]</small>

Challenge SMS message to claimed originator with a non-RCS phone

If the originator’s phone does not support RCS (e.g., a “dumbphone”), the system must fall back to plain SMS. This experience is the most basic and relies on the user to manually reply.

Spam Alliance: Did you just try to contact +1-202-555-0148? To connect, reply YES to this message.

Language Selection for a Global DYST System

For a global anti-spam system to be effective, it must communicate with users in their native language. The DYST system would handle this differently depending on the originator’s device capabilities.

1. First-Class (DYST-enabled Handset)

This is the simplest scenario. The silent JSON payload exchanged between the services is machine-readable and language-agnostic. If the originator’s handset needs to display any notification related to the verification, it uses its own local OS language setting to do so. No language information needs to be transmitted in the challenge itself.

2. RCS Fallback (non-DYST Smartphone)

When falling back to a user-facing RCS message, the system must send the challenge in the correct language. This would be solved by having the originator’s device report its language preference (e.g., ‘es-MX’ for Mexican Spanish) as part of its standard RCS capabilities. The Spam Alliance’s service would then deliver a pre-translated, interactive message in that specific language.

3. SMS Fallback (non-RCS phone)

This is the most challenging scenario. Like the RCS fallback, the system would attempt to determine the device’s language. However, without the rich capabilities of an RCS client, this may not be possible. As a last resort, the system would have to make an educated guess based on the phone number’s country code, which is less reliable but better than defaulting to a single language like English.

← Previous Archive Next →

Published

November 30^th, 2025

Reads:

Paul Hammant's Blog: Did You Send This - for module phone SMS/Voice