Using the Neuron to send and receive e-mail

The TAG Neuron® supports multiple protocols, among them, both the XMPP Protocol and the SMTP protocol. In XMPP, clients have accounts on brokers, and connect to their broker to connect to the federated XMPP network. Addresses in XMPP are called Jabber IDs, or JIDs for short. The Bare JIDs look like e-mail addresses, in the form: ACCOUNT@DOMAIN. Once connected, the connection is assigned a Full JID, in the form ACCOUNT@DOMAIN/RESOURCE.

The account can also interact using the SMTP protocol. This means, the client can send and receive e-mail seamlessly using the same XMPP account. E-mail messages sent to the account gets forwarded as messages to the client. The client can send messages back. The Neuron converts the messages into e-mail messages and forwards them to the recipient using the SMTP protocol.

There are some differences between how SMTP works on the Neuron®, and if you are using a traditional SMTP Server:

• In order to be able to communicate with a client on the Neuron, you need a presence subscription. This is a requirement on XMPP. SMTP does not have such a feature, which is one of the reasons why e-mail is so ripe with spam. The Neuron enforces presence subscription on e-mail as well. It does this via a squence of e-mails that are sent to anyone trying to send e-mail to an account on the Neuron. The e-mails will contain links allowing the sender to request presence. Once the client has accepted the presence subscription, the sender of the e-mail gets notified that it is able to send e-mail to the indented recipient.

• Outgoing messages are accumulated for a short time before being sent. In XMPP, messages are sent instantaneously to the recipient. If you use a chat program and write multiple rows of text, you want all rows to get into the same e-mail message. For this reason, the Neuron accumulates outgoing text messages, and forwards them once there is a silence for a minute (or an hour has passed since the first row).

• Incoming e-mail messages are sent to the client encoded in multiple ways. First, the text of the message is extracted, and forwarded as Markdown, HTML and/or plain text, as appropriate. The original contents of the e-mail is also forwarded, but can only be processed by the client, if it understands a separate e-mail extensions. This means, you can e-mail to any XMPP client, using text content. But only XMPP clients understanding the e-mail extension will be able to receive more advanced concepts, such as embedded attachments, etc.

• Outgoing messages from XMPP clients are typically of a simpler nature: Plain text, HTML and/or Markdown. This is transformed into multi-formatted e-mail messages accordingly, before being sent.

Example

As an example, following is a short interaction between an e-mail client using a hotmail e-mailing address, and an XMPP client, using an XMPP address. No Mail Relay was used on the Neuron used in this example.

Sending first mail to XMPP client

First step, that will trigger the approval process (or white-listing process), is to send an e-mail to the XMPP client you want to interact with. The contents of this e-mail will be ignored; it can be anything. When the Neuron receives this e-mail, it will check the roster of the recipient to see if an approved presence subscription is available. If not, it will immediately return an e-mail stating this fact.

Sending a presence subscription request

The e-mail will contain a link the recipient can click on, that will send a presence subscription request to the intended recipient. The link is cryptographically protected with the associated e-mail, and the sender and receiver identities. The sender will also receive an e-mail confirmation that the presence subscription request was sent to the recipient.

Receiving presence subscription acceptance confirmation

If the recipient accepts the presence subscription request, a two new e-mails are sent to the original sender, confirming this fact, and instructing the sender that it is now allowed to send e-mails to the intended recipient. The first e-mail shows the sender has been added to the white-list (roster in XMPP). The second, that the presence subscription request has been accepted.

Testing e-mail <-> XMPP link

The e-mail sender should now be able to communicate with the XMPP recipient. Sending a simple test message to the recipient, will make the text in the e-mail appear as a chat message in the XMPP client. The XMPP client can respond using chat, just as if the sender was another XMPP-client.

The XMPP chat response is transformed into an e-mail and sent to the original sender.

Troubleshooting SMTP Communication

A lot of problems can occur in SMTP communication. The principle reason is lack of cybersecurity in the original specifications, and security added on-top, as people became aware of threats. There is often no clear indication as to why there are problems sending or receiving e-mail.

The principle resource for troubleshooting e-mail is SMTP communication logs. These are stored in the SMTP subfolder in the Neuron Program Data Folder. The SMTP folder contains subfolders with communication logs for different senders and recipients. Input logs (containing information about incoming messages) are stored separately from Output logs (containing information about outgoing messages). To distinguish the two, Input logs are suffixed with IN and Output logs are suffixed with OUT.

When troubleshooting incoming logs, you need to know from where the message will be received. This can be learned from DNS SPF entries. When troubleshooting outgoing logs, you need to know to where the message will be sent. This can be learned from DNS MX entries. There are tools online for finding out both. You can also use the Script engine on the Neuron to get the relevant DNS records.

Also, you need to ensure the DNS has been configured correctly for the Neuron, especially those related to Sender Policy Framework SPF (TXT records) and Mail Exchange (MX records).

#tutorial, #neuron, #smtp, #email, #mail, #xmpp

HTTP Proxy

The TAG Neuron® now (from build 2026-05-12) has a new API: A generic HTTP Proxy at /HttpProxy. It allows clients to use the broker as a proxy to access resources on the Internet. This can be useful in multiple cases, for instance in environments where access to certain resources are limited, but the Neuron has free access. One such example is accessing HTTP-only resources from a smart phone environment, which requires use of HTTPS, and the remote web server does not have HTTPS enabled. (This is the case for certain ICAO Certificate Revocation Lists for example.)

Authentication

The HTTP Proxy resource requires authentication. The reason for this restriction is to avoid the broker to become a point for third parties to commit cyber-crime. The resource supports multiple form of authentication: Normal WWW-Authenticate is supported, mTLS (for brokers where this is enabled), or JWT Bearer tokens. Session login is also supported. This makes it possible to integrate the resource in web pages hosted by the Neuron.

JWT Bearer tokens is usedful in environments based on XMPP, where access to HTTP-based resources is required, but restricted by the operating system, such as the Neuro-Access smart phone app.

Since the app, in this case, has an XMPP connection to the broker, it can get a JWT token from the broker by using the HttpxClient class (HTTP over XMPP) in the Waher.Networking.XMPP.HTTPX library. Calling the GetJwtToken method returns a JWT token that can be used to make HTTP requests to the broker, authenticated as the XMPP account.

Redirecting HTTP links

If using InternetContent in the Waher.Content library to access content on the Internet, you can redirect HTTP-only links to a custom resource by providing an event handler to the WebGetter.HttpUriEventHandler event. Take the opportunity to provide a new URI in the event arguments, redirecting the request to the HTTP proxy resource of the Nueron to which the client is connected using XMPP. You also need to add the Bearer token to the Request headers available in the event arguments. The URI itself is then URI encoded and added as a sub-path to the /HttpProxy/ resource.

Example

The first step is to get a JWT token from the Neuron, identifying the XMPP connection the client has. We use the HttpxClient method GetJwtTokenAsync method, providing the number of seconds we want the token to be valid:

string Token = await this.httpxClient.GetJwtTokenAsync(60);

We then create an event handler to reroute HTTP-only requests to the HTTP proxy on the Neuron to which the client is using, using HTTPS. Creating an event handler for this purpose is simple (replacing DOMAIN in the example with the domain of the Neuron). We also need to add the Bearer JWT token by using an Authorization header:

private static void ViaProxy(object Sender, HttpUriEventArgs e)
{
	e.Uri = new Uri("https://DOMAIN/HttpProxy/" + WebUtility.UrlEncode(e.Uri.ToString()));
	e.Request.Headers.Add("Authorization", "Bearer " + Token);
}

We need to assign the event handler to the event:

WebGetter.HttpUriEventHandler += ViaProxy;

Later, when we do not need to redirect HTTP requests any longer, we need to unregister it:

WebGetter.HttpUriEventHandler -= ViaProxy;

While the event handler is registered, any access to web resources using HTTP, by using the static InternetContent class, will be seamlessly redirected to the HTTP proxy. Example:

ContentResponse Response = await InternetContent.GetAsync(
	new Uri("http://example.org/"),
	new KeyValuePair<string, string>("Accept", HtmlCodec.DefaultContentType));

#new, #features, #api, #security, #neuron

Age-verification without leaking birth date

This article describes the process of how to create a Legal Identity that can be used to demonstrate you have reached a certain age, without having to disclose your actual birth date. This is an important mechanism to protect the integrity of personal information, especially if the person is a child.

Creating a Preview ID application

The first step is to create a Preview Legal Identity application containing sufficient personal information so that the age can be verified. This application will have to contain sensitive personal information, including birth date. But creating a Preview application ensures the data is not stored in a searchable database or logs. Instead it is stored in encrypted form, and only during the process to validate the information. Once the preview application has been validated, a new application can be created, containing a subset of the sensitive information, and once that is completed, the sensitive information will be removed.

The personal data necessary to include in the Preview application is:

Property	Description
BDAY	Birth Day
BMONTH	Borth Month
BYEAR	Birth Year
AGEABOVE	Age above the stated number of years

Creating real ID application

Once the Preview application has been approved, a new, real ID application is made. This new application has to have a reference to the Preview application, and should only contain a subset of the properties. At a minimum, the following properties should be included:

Property	Description
PREVIEW	Reference to the earlier Preview application.
AGEABOVE	Age above the stated number of years

Once this application has been approved, the sensitive personal information will be removed as the preview application is deleted.

Proving your age

Proving your age is as simple as performing a Quick Login with the new identity. If property filters are used, include the AGEABOVE property. As the new identity contains a reduced set of information, and no birth-date (if it was removed in the second step above), only the AGEABOVE property is received, together with proof the Neuron has validated the claim.

How to set AGEABOVE

The AGEABOVE property should not be set to the age of the user, as that can leak personal information. Instead, it should be set to a legal limit required for one or more specific purposes. If there’s an age requirement in a country for a particular purpose, that age should be encoded in the AGEABOVE property. The property will be accepted if the personal information provided in the preview can be validated, and the age of the person deduced is at or above the indicated number.

As there are different age limits for different purposes and countries (for instance, 13, 15, 16, 17, 18, 20 and 21 are common limits), the site that tests the age of a user should not expect the number to be a specific value. Instead, it should expect the number to be at least a specific number. If there’s an age requirement for a service of 16 years of age, identities with any number for AGEABOVE greater or equal to 16 should be accepted as proof ther person is at least 16 years old.

Ensuring you have reached a certain age to create an identity

The AGEABOVE property can also be used to ensure the user of the app attempting to create an identity, has reached a certain age. Adding the property ensures the identity attempted to be created only gets approved, if the person actually has reached the age.

If the person has not reached the corresponding age, the property will become invalid, and an error with error code AgeNotReached will be logged on the application.

#new, #neuron, #features, #id, #security, #privacy

Validating Electronic Travel Documents & ICAO PKI Certificates

When validating electronic Travel Documents, applications need to validate against corresponding issuer certificates not managed by the operating system. To do that, the application needs to get access to these certificates somehow, and build custom X.509 chains during validation. To avoid having such an application to embed the entire list of all these issuer certificates, a list which also get regularly updated, a new repository and package is available that publishes these certificates on Neurons where the package gets installed. Applications can easily check with the corresponding neuron and download the required certificates, based on the Authority Key Identifiers available in the Electronic Travel Document certificates.

Information about the ICAO PKI Certificate package
Package	IcaoPkiCertificates.package
Installation key	vAa0l/iFHVogQYUzm+Zs6qPsw+7lYrnyFn4MNAGA7+Gso442gJJMKjknHqka/YjM6gZZSS65HL8Adbfba1067a1a27163b905869469d6f0d
More information	https://github.com/Trust-Anchor-Group/IcaoPkiCertificates

#features, #id, #kyc, #neuron, #api, #repository, #package, #new

Remote Login API

Since Build 2025-12-30, extended in Build 2025-12-31, a new API called the Remote Login API is available on the TAG Neuron®. It is a complement to the Quick Login API, in the following ways:

• The Quick Login API is initiated by the client itself, for instance, by scanning a QR-code, clicking a link or logging in to a web site, for instance.

• The Remote Login API on the other hand, is initiated by a remote service, that wants to use the digital identity of the user in a second (or multi) factor authentication process (2FA, or MFA).

• The Quick Login API allows anonymous access (on the HTTP resource level), while the Remote Login API requires authorized access. This authorized access can be granted using WWW-Authenticate or Mutual TLS (mTLS). Mutual TLS is recommended, as it avoids the use of passwords. In both cases, the administrator of the Neuron providing access to the API needs to create a corresponding user and grant the user the corresponding privileges. (See the API documentation for details.)

#new, #api, #neuron, #security, #id