Our hosted anti spam solution blocks phishing, spyware and viruses from email before they reach your network thus protecting your email server and also preventing spam messages reaching your desktop software like Outlook, Entourage or Outlook Express.

YES!!

profilter supports SMTP, POP and IMAP protocols so will work with all major mail servers.

This includes but not limited to:

  Microsoft Ecxhange
  Novell GroupWise
  Lotus Notes
  Mercury Mail
  Any many more...

No additional hardware or software needs to be installed or managed locally. The spam messages are blocked on the Internet saving you downloading your junk emails first.

This in turn lowers your bandwith usage and risk of virus infection. Plus with no additional services/apps running locally this saves you CPU resources and further memory overheads

No!!

profilter is a realtime service which means that messages are processed automatically as soon as they come in.

When profilter is not able to deliver email to the destination server, the email will be queued up to 5 days.  If you have gone into a disaster recovery mode and want us to store your email longer then simply lets us know by contacting the support helpdesk.

proFilter licensing is a 1:1 relationship with the number of mailboxes on the downstream server for that domain.

For example, If you had seperate mailboxes for User1, User2, User3 and a Info mailbox, that's 4 mailboxes so you would need a profilter5 package.

Yes, profilter will allow you to add & remove profilter-users up to the maximum of your license count.

If you find your domain is still receiving emails for a non-existent user and its just unwanted emails then that email address can be added to the spam-trap (A special user for letting profilter know this is unwanted emails).

If that email address does have real emails you still want then you either need to alias the address to another profilter-user or add the email address as an additional user license.

If you no longer want to use the profilter service you can cancel at anytime from within the secure clients area.

In the Secure Clients Area select the menu 'My Services'. Find the desired service you wish to cancel and select it. Then click on the button 'Request Cancellation'.

You will also need to remove the MX record from within your domain names DNS settings, please see the setup section or the support pages for additional information on setup and removal of the proFilter service.

MTA-STS (Mail Transfer Agent - Strict Transport Security) is a protocol designed to enhance email security by enforcing strict encryption policies for inbound email delivery.

It works by allowing domain owners to publish a policy specifying the security standards that receiving email servers must adhere to when communicating with their domain's mail servers. These standards typically include requirements for Transport Layer Security (TLS) encryption and certificate validation.

By implementing MTA-STS, domain owners can mitigate the risk of man-in-the-middle attacks and other forms of interception by ensuring that all email exchanges with their domain are encrypted and authenticated. This helps prevent unauthorised access to sensitive information contained within email communications.

MTA-STS, or Mail Transfer Agent - Strict Transport Security, serves several key functions to enhance email security:

• Enforces Encryption: MTA-STS mandates the use of Transport Layer Security (TLS) encryption for email communication between mail servers. This ensures that messages exchanged between sender and recipient domains are encrypted, mitigating the risk of interception and unauthorised access.
• Validates Certificates: MTA-STS requires that receiving mail servers validate the SSL/TLS certificates presented by sending servers. This validation helps prevent man-in-the-middle attacks, where an attacker intercepts and potentially alters email traffic between servers.
• Establish Secure Channels: By enforcing TLS encryption and certificate validation, MTA-STS helps establish secure communication channels between email servers. This protects sensitive information transmitted via email from being exposed to unauthorised parties.
• Prevents Downgrade Attacks: MTA-STS policies specify the minimum acceptable TLS version and cryptographic algorithms for secure communication. This prevents attackers from downgrading the encryption level to weaker protocols, strengthening the overall security of email exchanges.
• Enhances Trust: Implementing MTA-STS demonstrates a commitment to email security by domain owners. It instills confidence in recipients that communications originating from these domains are transmitted securely, reducing the likelihood of phishing attacks and other forms of email fraud.

MTA-STS plays a crucial role in bolstering the security of email infrastructure by enforcing encryption standards and mitigating potential vulnerabilities in email transmission protocols.

Setting up MTA-STS involves several steps:

• Generate SSL/TLS Certificate: Obtain a valid SSL/TLS certificate for your mail server.
• Configure TLS on Mail Server: Ensure that your mail server is properly configured to support TLS encryption.
• Create MTA-STS Policy: Write a MTA-STS policy file detailing the TLS requirements for inbound email delivery.
• Publish Policy File: Host the policy file on a publicly accessible (HTTPS only) web server.
• Add DNS TXT Record: Create the necessary DNS records to support MTA-STS.

If you're using profilter for your inbound email delivery then all profilter clusters are already configured to support SSL/TLS communications.

We've created a detailed knowledage base article on the setting up of MTA-STS

Direct link to the KB Article is here.

MTA-STS (Mail Transfer Agent Strict Transport Security) is a mechanism designed to enhance the security of inbound email communication by enforcing secure connections between mail servers.

It works by specifying policies in the Domain Name System (DNS) records of a domain, indicating if encrypted connections using specific protocols, such as Transport Layer Security (TLS), should be accepted by the mail server.

The implementation of MTA-STS requires the publishing of several DNS records. Please see the KB article titled, "How do I setup MTA-STS@quot; for the DNS records required.

An MTA-STS (Mail Transfer Agent Strict Transport Security) record is a type of DNS (Domain Name System) record used to implement MTA-STS policy for a domain.

The MTA-STS DNS records point to a public location where the MTA-STS policy is published.

To implement MTA-STS two DNS records are required. A DNS A or AAAA record called mta-sts and a DNS TXT record called _mta-sts. For more information please see the setup guide.

MTA-STS (Mail Transfer Agent Strict Transport Security) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) are both mechanisms aimed at enhancing email security, but they serve different purposes and operate at different layers of the email infrastructure.

MTA-STS primarily focuses on securing the transport layer of email communications. It ensures that email exchanges between mail servers occur over encrypted connections, typically using protocols like Transport Layer Security (TLS).

On the other hand, DMARC is a policy framework that focuses on authenticating emails and combatting email spoofing and phishing attacks. DMARC enables domain owners to authenticate their emails using techniques like SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), and it provides instructions to email receivers on how to handle emails that fail authentication.

TLS-RPT (Transport Layer Security - RePorTing) is a protocol designed to improve the security of email communication by providing feedback to domain owners about issues encountered during the establishment of TLS-encrypted connections between email servers.

If you're going to implement MTA-STS then its a good ideal to implement TLS-RPT so you can problem solve any delivery issues that are caused by having a strict security delivery policy.

TLS Reporting is a valuable tool for domain owners to monitor and improve the security of their email communication by receiving feedback on TLS connection attempts made to their domains. Here's a brief overview of TLS-RPT:

• Feedback Mechanism: TLS-RPT allows email servers to report back to domain owners any problems encountered when attempting to establish Transport Layer Security (TLS) connections. These reports provide valuable insight into potential security vulnerabilities and misconfigurations.
• Diagnostic Information: TLS-RPT reports typically include diagnostic information such as error codes, encryption protocol versions, and certificate validation failures encountered during the TLS handshake process.
• Policy Discovery: In addition to reporting errors, TLS-RPT enables domain owners to discover which email servers are attempting to connect to their domain using TLS encryption. This helps domain owners assess the effectiveness of their TLS policies and identify any unauthorised or insecure connections.
• Enhanced Security: By providing feedback on TLS connection attempts, TLS-RPT enables domain owners to identify and address security weaknesses in their email infrastructure, ultimately enhancing the overall security posture of their domains.

We've created a detailed knowledage base article on the setting up of TLS-RPT

Direct link to the KB Article is here.