Technical Reference Guide for Familiarity Instruction, Testing and Certification

1. Purpose of the Messaging Retention Environment

A regulated messaging environment exists to ensure that business communications that must be preserved for legal, regulatory, investigative, or corporate-governance purposes are reliably captured and retained.

The basic problem is straightforward:

A message is created → transported → captured → archived → retained → searched or produced when required.

An engineer working in this environment is concerned not simply with whether a message reaches its recipient, but also with questions such as:

• Was the message captured for archival purposes?
• Was the complete message preserved?
• Was it associated with the correct user?
• Was it stored for the correct retention period?
• Can compliance personnel retrieve it later?
• Can the organization prove that the capture system was operating?
• What happens if an archive destination or SMTP relay becomes unavailable?
• Can messages be recovered or replayed after a failure?
• Are unauthorized systems prevented from using the relay?
• Are monitoring and audit records sufficient to reconstruct what happened?

In financial services and other regulated industries, these questions may apply not only to email but also to communications generated by collaboration and messaging systems such as Microsoft Teams, Bloomberg, Symphony, and similar platforms.

A messaging engineer therefore works at the intersection of:

Windows infrastructure + SMTP + networking + automation + databases + archiving + compliance governance.

---

2. SMTP

What SMTP Is

SMTP stands for Simple Mail Transfer Protocol.

SMTP is the standard protocol used to transfer electronic mail between systems. An SMTP server can receive a message from one system and deliver or relay it to another.

A simplified path might look like:

Application → SMTP relay → corporate mail system → destination

In a compliance environment, another path might be:

Messaging system → SMTP capture/relay → archive ingestion system

The engineer needs to understand SMTP as a transport mechanism rather than merely as something used by an email client.

Basic SMTP Transaction

A normal SMTP conversation contains commands such as:

• `EHLO` or `HELO`
• `MAIL FROM`
• `RCPT TO`
• `DATA`
• `QUIT`

Conceptually:

1. The sending system connects to an SMTP server.

2. The SMTP server identifies itself.

3. The sender identifies the envelope sender.

4. One or more recipients are specified.

5. The message body and headers are transmitted.

6. The receiving system either accepts or rejects the message.

SMTP responses are normally represented by three-digit status codes.

Examples:

• 2xx — successful operation
• 4xx — temporary failure
• 5xx — permanent failure

A `451` response, for example, generally indicates that the sender may retry later.

A `550` response normally means the message has been permanently rejected for the reason stated by the receiving server.

Why SMTP Matters for Archiving

In a regulated environment, SMTP may be used to forward copies of messages into an archive.

A failure in this transport path can therefore create a compliance issue even when ordinary user email continues to work.

An engineer might investigate:

• messages accumulating in an SMTP queue;
• DNS resolution failures;
• unreachable archive destinations;
• connection timeouts;
• incorrect smart-host configuration;
• firewall changes;
• TLS negotiation problems;
• authentication failures;
• malformed messages;
• recipient rejection;
• insufficient disk space;
• SMTP service failure.

A useful troubleshooting sequence is:

Can the source send? → Can the relay receive? → Can the relay connect downstream? → Does the downstream system accept the message? → Does the archive successfully ingest it?

---

3. SMTP Forwarding and Relaying

What a Relay Does

An SMTP relay accepts mail from another system and forwards it toward another SMTP destination.

For example:

Application Server

↓

Windows SMTP Relay

↓

Proofpoint Archive Connector

The relay allows applications to send messages without every application needing to understand the complete messaging infrastructure.

Smart Hosts

A smart host is a designated SMTP server to which another SMTP server forwards messages instead of determining the final route itself.

For example, a Windows SMTP server might be configured to forward all outbound traffic to:

`archive-relay.company.example`

The SMTP service therefore acts as an intermediary.

Relay Restrictions

An SMTP server should not indiscriminately relay mail for any system that connects to it.

An unrestricted relay could become an open relay, allowing unauthorized parties to send mail through the organization's infrastructure.

Relay permission can therefore be restricted using factors such as:

• source IP addresses;
• networks or subnets;
• authentication;
• connector configuration.

An engineer should understand the difference between:

Connection permission — whether a system may connect.

and

Relay permission — whether the system may ask the server to forward a message somewhere else.

---

4. Windows IIS 6.0 SMTP Service

What It Is

The Windows SMTP service historically shipped as part of Microsoft's IIS-related Windows components.

Despite the name IIS 6.0 Manager, the SMTP component can appear on later Windows Server systems as a legacy feature administered using the IIS 6 management console.

It is commonly used as a lightweight SMTP relay for applications and infrastructure systems.

Microsoft's documentation describes installation of the SMTP Server feature and administration of SMTP virtual servers through IIS management tools. The technology is legacy and deprecated, so an engineer supporting it should treat it as existing enterprise infrastructure rather than a preferred design for a new messaging system.

SMTP Virtual Server

A Windows SMTP installation contains an SMTP Virtual Server.

Important configuration areas include:

• IP binding;
• TCP port;
• connection restrictions;
• relay restrictions;
• authentication;
• outbound security;
• outbound connection settings;
• smart-host configuration;
• message limits;
• retry behavior;
• logging.

Pickup and Queue Directories

Windows SMTP uses filesystem directories as part of message processing.

Conceptually:

Pickup → Queue → Delivery

A program can sometimes create a properly formatted message file in a pickup directory. The SMTP service recognizes it and attempts delivery.

Messages awaiting transmission can remain in the queue.

For troubleshooting, queue growth is an important symptom.

If 50,000 messages suddenly appear in a queue directory, the engineer should not immediately delete them. The correct question is:

Why are they not being delivered?

Possible causes include:

• downstream server unavailable;
• DNS failure;
• firewall blockage;
• destination refusing connections;
• authentication failure;
• routing misconfiguration;
• TLS failure.

After correcting the underlying condition, queued messages may resume delivery.

---

5. Windows Server

Windows Server provides the operating environment for components such as:

• SMTP services;
• IIS;
• Python automation;
• scheduled tasks;
• monitoring agents;
• SQL clients;
• logging;
• certificates;
• network configuration.

A messaging engineer should be comfortable administering Windows services and investigating server-level problems.

Typical tasks include:

• starting and stopping services;
• reviewing Event Viewer;
• checking CPU and memory;
• monitoring filesystem capacity;
• configuring service accounts;
• installing certificates;
• examining Windows logs;
• configuring scheduled tasks;
• inspecting listening ports;
• checking processes;
• applying patches;
• validating system dependencies.

Useful PowerShell commands might include concepts such as:

`Get-Service`

`Get-Process`

`Get-NetTCPConnection`

`Test-NetConnection`

An engineer troubleshooting SMTP might use `Test-NetConnection` to determine whether a downstream server's TCP port 25 is reachable.

---

6. IIS

IIS stands for Internet Information Services and is Microsoft's Windows web-server platform. Microsoft describes IIS as a web server capable of hosting web applications and related services.

In this job, IIS knowledge may have two meanings.

First, the engineer may support conventional IIS-hosted applications, APIs, monitoring pages, or internal tools.

Second, the engineer may administer the legacy Windows SMTP service using the IIS 6.0 management interface.

These should not be confused.

For a conventional IIS web application, an engineer might manage:

• websites;
• bindings;
• TLS certificates;
• application pools;
• authentication;
• logging;
• filesystem permissions;
• service identities;
• application configuration.

A Python automation process might, for example, generate a compliance report and publish it to an internal site hosted under IIS.

---

7. Email Retention and Vaulting

Retention

Retention determines how long information must remain preserved.

Different classes of communication may require different retention periods.

A retention policy commonly specifies:

• what information is covered;
• who is covered;
• how long it must be retained;
• when the retention period begins;
• when information may be deleted;
• exceptions such as legal holds.

Vaulting

A vault is a repository used to preserve communications independently of an end user's ordinary mailbox.

The distinction is important.

Deleting a message from Outlook should not necessarily delete the organization's retained compliance copy.

The archive becomes an independent system of record.

Why Organizations Archive Communications

Common purposes include:

• regulatory compliance;
• investigations;
• litigation;
• eDiscovery;
• legal holds;
• internal investigations;
• supervision;
• corporate records management.

Proofpoint describes email archiving as preserving communications in a secure, indexed and retrievable format.

---

8. Capture

Capture refers to obtaining a reliable copy of a communication so that it can enter the retention system.

A capture mechanism may receive data from:

• SMTP journaling;
• messaging APIs;
• connectors;
• export feeds;
• collaboration systems;
• third-party messaging platforms.

A capture system should aim for completeness.

For example, preserving only the visible email body while losing attachments or important metadata could make the archive incomplete.

Useful message metadata can include:

• sender;
• recipients;
• timestamp;
• subject;
• message identifier;
• headers;
• attachments;
• communication platform;
• user identity.

---

9. Proofpoint Enterprise Archive

Proofpoint Enterprise Archive is an archiving technology designed to preserve and search enterprise communications.

Proofpoint describes its archive platform as supporting collection, preservation, discovery, retention and disposition of electronically stored information across sources including email and collaboration communications.

For this position, Proofpoint experience refers specifically to archiving and retention, not primarily to Proofpoint's email security, DLP, encryption or fraud-defense products.

That distinction matters.

An archive engineer might work with:

• archive ingestion;
• message capture;
• user mapping;
• retention policies;
• searches;
• legal holds;
• message exports;
• connectors;
• ingestion errors;
• archive queues;
• data reconciliation.

Search and eDiscovery

An archive must make retained data searchable.

Authorized personnel may search by criteria such as:

• sender;
• recipient;
• keyword;
• date range;
• user;
• message type.

Search capability is particularly important for eDiscovery.

Proofpoint describes Enterprise Archive as addressing regulatory compliance, legal discovery and retained message access.

Legal Hold

A legal hold prevents relevant information from being disposed of even if its normal retention period has expired.

Example:

A company's normal retention policy might permit deletion after a defined period.

If litigation begins, communications associated with specified employees or subjects might be placed under legal hold.

Those records must remain preserved until the hold is released.

Ingestion Troubleshooting

Suppose the SMTP transport system shows that 100,000 messages were delivered to the archive connector, while the archive reports only 97,000 successful ingestions.

An engineer should investigate the discrepancy.

Questions include:

• Were messages rejected?
• Were some messages duplicated?
• Are messages waiting in a queue?
• Is a connector failing?
• Are user identities mapped correctly?
• Is an ingestion process delayed?
• Are there malformed messages?
• Was a configuration change made?

In regulated systems, reconciliation between expected and actual capture is extremely important.

---

10. Microsoft Teams

Microsoft Teams generates written electronic communications such as:

• one-to-one chats;
• group chats;
• channel messages;
• meeting-related communications.

These communications may fall under organizational retention or supervision requirements.

Microsoft Purview supports retention policies for Teams communications, although different Teams-associated content types may be retained through different Microsoft 365 workloads.

An engineer working on a broader compliance archive may need to ensure Teams information reaches the appropriate compliance platform.

This usually requires understanding:

source → connector/API → capture system → archive → retention policy

---

11. Bloomberg and Symphony Messaging

Financial institutions frequently use specialized communications platforms in addition to ordinary email.

Bloomberg messaging and Symphony are examples of communications systems that may need to participate in regulated retention programs.

A messaging engineer does not necessarily need to develop these platforms.

The engineering concern is often integration.

Questions include:

• How are messages exported?
• Which connector captures them?
• Which users are mapped to which enterprise identities?
• Are attachments captured?
• Is metadata preserved?
• What happens if the connector stops?
• Can missing communications be replayed?
• How is successful ingestion measured?

An engineer should think of each communications platform as another data source feeding the compliance archive.

---

12. Electronic Compliance and Retention Governance

Governance provides the rules determining what happens to information.

Technology implements those rules.

A governance framework may define:

• which employees are subject to retention;
• which communications are business records;
• required retention periods;
• who may access archived records;
• when records may be deleted;
• when legal holds override normal disposition;
• how changes must be approved;
• what audit evidence must be maintained.

A messaging engineer typically does not independently decide regulatory policy.

Instead:

Legal/Compliance defines requirements → Engineering implements controls → Operations monitors them → Audit verifies them.

---

13. Microsoft Purview

Microsoft Purview provides Microsoft 365 data-governance and compliance capabilities.

Its Data Lifecycle Management functions use retention policies to control how long information is preserved or when it may be deleted across Microsoft workloads.

Microsoft Purview Communication Compliance can also examine communications for defined regulatory or organizational policy conditions and route policy matches for review.

A messaging engineer might interact with Purview to:

• implement retention policies;
• understand Microsoft 365 retention behavior;
• investigate compliance workflows;
• coordinate third-party archive integrations;
• confirm which communications are captured;
• support audits.

Microsoft also supports importing certain third-party communications into Purview for retention and compliance workflows.

---

14. Python Automation

Python is useful in messaging operations because many repetitive operational tasks can be automated.

Examples include:

• querying SMTP queue statistics;
• parsing logs;
• checking archive ingestion counts;
• comparing message counts between systems;
• generating daily compliance reports;
• calling REST APIs;
• validating configuration;
• checking connectivity;
• querying SQL databases;
• sending alerts;
• detecting missing capture events.

Example Reconciliation Concept

Suppose the transport system says:

Messages sent to archive: 1,002,416

and the archive says:

Messages successfully ingested: 1,002,403

The difference is:

13 messages

A Python job could automatically compare those numbers and alert operations rather than relying on a person to manually check them.

A good automation process should:

1. collect data;

2. validate the data;

3. compare expected and actual results;

4. record what it found;

5. alert when thresholds are exceeded;

6. preserve sufficient logs for troubleshooting.

Automation in a regulated system should itself be auditable.

---

15. MS SQL

Microsoft SQL Server may store operational or application information associated with a messaging environment.

An engineer may use SQL to:

• retrieve message-processing statistics;
• query application state;
• investigate errors;
• correlate events;
• produce reports;
• support Python automation.

Basic SQL familiarity should include concepts such as:

`SELECT`

`WHERE`

`JOIN`

`GROUP BY`

`ORDER BY`

and aggregate functions such as:

`COUNT()`

For example, an engineer might group archive-ingestion records by hour to determine when a failure started.

Production database work should be performed carefully. Troubleshooting queries should generally avoid unnecessary changes to production data.

---

16. Firewall Rules and Network Fundamentals

A distributed messaging system depends on network connectivity.

An engineer should understand:

• IP addresses;
• DNS;
• TCP;
• ports;
• routing;
• firewalls;
• NAT;
• TLS;
• source and destination rules.

SMTP traditionally uses TCP port 25 for server-to-server transport.

Other SMTP submission scenarios may use ports such as 587, depending on architecture.

A firewall rule generally involves concepts such as:

source → destination → protocol → port → action

Example:

SMTP Relay A → Archive Gateway B → TCP 25 → Allow

If a previously functioning SMTP integration stops immediately after a firewall change, network connectivity should be investigated before changing the messaging application.

---

17. DNS

Messaging systems frequently depend on DNS to translate hostnames into IP addresses.

A configuration might identify a smart host by name:

`archive-relay.company.example`

If DNS resolution fails, the SMTP service may be unable to connect even though both systems themselves are healthy.

An engineer should be able to distinguish:

DNS problem

from

TCP connectivity problem

from

SMTP application problem.

---

18. TLS

TLS protects communications in transit.

SMTP systems may negotiate encrypted communications using TLS.

Troubleshooting TLS may involve:

• certificate expiration;
• certificate trust;
• hostname mismatch;
• unsupported TLS versions;
• cipher compatibility;
• configuration changes.

A TCP port being reachable does not prove that a successful SMTP/TLS session can occur.

---

19. Capacity Planning

Messaging infrastructure must be designed for both normal traffic and abnormal peaks.

Capacity considerations include:

• message volume;
• attachment size;
• messages per second;
• queue capacity;
• disk usage;
• database growth;
• archive ingestion rate;
• network bandwidth;
• recovery time.

For example:

If the organization generates 10 million communications per day, and an archive connector is unavailable for four hours, the recovery design must be able to buffer the affected traffic and later process the backlog.

A robust system must therefore account for both:

steady-state capacity

and

catch-up capacity after failure.

---

20. Operational Resilience

Operational resilience means designing a service so that failures do not immediately cause loss of required communications.

Useful mechanisms include:

• redundant servers;
• queues;
• retry logic;
• monitoring;
• backup destinations;
• durable storage;
• documented recovery procedures;
• capacity headroom.

For compliance systems, preserving messages is usually more important than processing them instantaneously.

A temporary delay may be acceptable.

Permanent loss may not be.

---

21. Monitoring

A messaging engineer should monitor the entire communication path.

Useful metrics include:

• messages received;
• messages forwarded;
• messages rejected;
• messages queued;
• delivery latency;
• connection failures;
• archive ingestion failures;
• CPU;
• memory;
• disk capacity;
• service state.

Monitoring should identify trends, not merely complete outages.

For example:

A queue increasing from:

100 → 1,000 → 10,000 → 50,000

may indicate a delivery problem even though the SMTP service itself still reports that it is running.

---

22. Logging

Logs provide the evidence necessary to reconstruct failures.

An engineer might correlate:

• SMTP logs;
• Windows Event Viewer;
• IIS logs;
• application logs;
• archive logs;
• database records;
• firewall logs.

Timestamps are critical.

A common troubleshooting technique is to identify one known message and trace it through every system.

For example:

10:03:14 source generated message

10:03:15 SMTP relay accepted message

10:03:16 relay connected to archive

10:03:16 archive acknowledged SMTP delivery

10:03:19 archive ingestion completed

This creates an end-to-end transaction history.

---

23. Change Management

Changes to regulated infrastructure must be controlled.

A typical change process includes:

1. define the proposed change;

2. document the reason;

3. assess risk;

4. define testing;

5. obtain approval;

6. implement the change;

7. validate results;

8. monitor;

9. maintain a rollback procedure.

Examples include:

• modifying SMTP smart hosts;
• changing firewall rules;
• installing certificates;
• changing retention policies;
• upgrading archive connectors;
• migrating servers.

A technically correct change can still be unacceptable if it is performed without required governance.

---

24. Migration

Messaging migrations are particularly sensitive because multiple systems may operate simultaneously during transition.

A migration might involve:

Old SMTP Relay → New SMTP Relay

or

Old Archive → New Archive

The engineer must ensure that communications are not lost during the transition.

A migration plan should consider:

• existing message backlog;
• routing changes;
• DNS;
• firewall access;
• credentials;
• certificates;
• user mapping;
• retention policies;
• historical data;
• rollback;
• reconciliation.

A migration should not be considered complete merely because users can send mail.

Compliance capture must also be verified.

---

25. CI/CD

CI/CD means Continuous Integration and Continuous Delivery/Deployment.

For messaging infrastructure, CI/CD might be used to deploy:

• Python utilities;
• configuration files;
• monitoring code;
• integration services;
• infrastructure automation.

A pipeline might:

1. retrieve source code;

2. run linting;

3. execute automated tests;

4. build a package;

5. deploy to a test environment;

6. perform validation;

7. promote an approved version.

The purpose is to make changes repeatable and reduce manual errors.

---

26. Automated Testing

Messaging systems can be tested automatically.

A synthetic test could:

1. generate a uniquely identified email;

2. submit it through SMTP;

3. verify relay acceptance;

4. verify archive ingestion;

5. search the archive for the identifier;

6. record the result.

Such a test validates the entire pipeline rather than merely confirming that individual services are running.

That distinction is important.

Service health does not necessarily equal business-process health.

---

27. ITIL

ITIL is a framework for managing IT services.

Relevant ideas include:

• incidents;
• problems;
• changes;
• service requests;
• configuration management;
• continual improvement.

An incident concerns restoring service.

A problem concerns identifying and addressing the underlying cause of one or more incidents.

Example:

SMTP delivery fails three times in one month.

Restarting the service may resolve each incident.

Determining that a recurring memory leak causes the failure is problem management.

---

28. COBIT

COBIT is an information-technology governance and control framework.

It emphasizes alignment between:

• organizational objectives;
• technology;
• risk;
• controls;
• accountability;
• measurement.

For a messaging engineer, COBIT familiarity mainly demonstrates understanding that infrastructure operates within a larger governance and control system.

---

29. NIST

NIST publishes widely used cybersecurity standards and frameworks.

Relevant security concepts include:

• identifying assets and risks;
• protecting systems;
• detecting abnormal conditions;
• responding to incidents;
• recovering from disruptions.

An engineer might apply these principles when protecting archive servers, credentials, network communications, administrative access and audit information.

---

30. SOX

SOX refers to the Sarbanes-Oxley Act.

In technology environments supporting financial reporting, SOX creates strong requirements around controls, accountability and evidence.

Technology teams may therefore need to demonstrate:

• authorized access;
• controlled changes;
• logging;
• separation of duties;
• documented procedures.

The important engineering lesson is that technical changes affecting regulated systems may themselves need to be auditable.

---

31. PCI

PCI DSS is the Payment Card Industry Data Security Standard.

Although an email archiving system is not necessarily a payment-processing system, familiarity with PCI demonstrates knowledge of controlled environments involving:

• access restrictions;
• network segmentation;
• secure configuration;
• monitoring;
• vulnerability management;
• protection of sensitive information.

---

32. Escalation Engineering

A senior messaging engineer is expected to handle failures that have moved beyond ordinary operations support.

Good escalation work begins by establishing facts.

Useful questions include:

• When did the problem start?
• What changed?
• Which systems are affected?
• Is the problem complete or intermittent?
• Is mail queued or lost?
• Can the issue be reproduced?
• What do the logs show?
• Is downstream connectivity available?
• What is the compliance impact?

The engineer should avoid making several uncontrolled changes simultaneously.

Changing DNS, SMTP configuration, firewall rules and archive settings at the same time can make the problem harder to understand.

---

33. Stakeholder Communication

Technical skill alone is insufficient in a regulated messaging environment.

During a significant incident, different stakeholders need different information.

Operations may need:

• queue size;
• affected servers;
• recovery actions.

Compliance may need:

• whether communications are being preserved;
• whether anything may have been lost;
• whether reconciliation will be required.

Leadership may need:

• business impact;
• regulatory exposure;
• current risk;
• recovery status;
• next milestone.

A useful status report separates:

Known facts

from

suspected causes

from

actions being taken.

---

34. Example End-to-End Architecture

A simplified regulated communications architecture could look like:

Employee communication

↓

Exchange / Teams / Bloomberg / Symphony

↓

Capture mechanism or connector

↓

Windows SMTP relay or integration service

↓

Proofpoint Enterprise Archive

↓

Retention and governance policies

↓

Compliance search / supervision / eDiscovery

↓

Legal, Compliance or Investigations

Supporting these components are:

Windows Server

IIS

Python

MS SQL

DNS

Firewalls

TLS

Monitoring

Logging

Change Management

The messaging engineer's responsibility is largely to ensure that information moves reliably through this chain and remains retrievable according to policy.

---

35. Core Troubleshooting Model

A useful mental model for almost any problem in this environment is:

Source

Was the communication generated?

Capture

Was the communication copied into the compliance pipeline?

Transport

Was SMTP or another connector able to transfer it?

Network

Could the systems communicate?

Destination

Did the archive receive it?

Ingestion

Did the archive successfully process and index it?

Governance

Was the correct retention policy applied?

Retrieval

Can authorized personnel find the communication later?

This sequence prevents troubleshooting from becoming random.

---

36. Core Principles to Remember

A messaging retention engineer should understand several principles particularly well.

Delivery and retention are different.

A user receiving an email does not prove that the compliance archive captured it.

Running services do not prove end-to-end health.

Every Windows service may show "Running" while messages accumulate in a queue.

Queues protect against temporary failure.

Their purpose is often to prevent transient outages from becoming data loss.

Reconciliation proves completeness.

Comparing what should have been archived with what actually arrived is one of the strongest ways to detect silent failures.

Retention is policy-driven.

Engineers implement retention requirements; legal and compliance organizations generally define them.

Legal hold overrides normal disposal.

Information relevant to litigation or investigation may need to remain preserved beyond its normal lifecycle.

Regulated infrastructure requires evidence.

Logs, monitoring records, approvals, test results and change records are part of the system's operational integrity.

Automation should improve repeatability without removing accountability.

A Python script can automate thousands of operations, but its actions should remain understandable, testable and auditable.

---

37. Practical Familiarity Expected of the Engineer

Someone familiar with this environment should be able to explain what happens when:

• an SMTP server cannot reach its smart host;
• a firewall blocks TCP port 25;
• an SMTP queue begins growing;
• DNS resolution fails;
• an archive connector goes offline;
• an archive receives fewer messages than the transport system sent;
• a TLS certificate expires;
• a message must be located for an investigation;
• a legal hold is applied;
• a retention policy changes;
• a server migration is performed;
• a messaging source such as Teams is added;
• a Python reconciliation job finds missing records;
• production infrastructure must be changed under formal change control.

The engineer does not merely memorize product names.

The engineer understands how the components depend on one another and how to prove that the entire communications-retention chain is working correctly.