Next Generation SPAM Defense

• SecurityPlus
• Outbreak Protection
• Heuristic Analysis
• Bayesian Classification and Learning
• SPF/Sender ID verification
• DK and DKIM signing
• Spam Traps
• DNS Black lists References Internet-standard black lists,
  i.e. www.mail-abuse.com
• Tarpitting discourages suspect senders to multiple recipients
• PTR Reverse lookups on sending mail servers
• Sender ID Framework Support
• DomainKeys
• Detect Spoofed Email Addresses
• Private White Lists

Technical Highlights

• DNS Black List - this feature enables blacklist support effectively blocking the relaying of SPAM.
• Spam Filter / Heuristic Analysis – this feature drastically decreases the amount of spam that users receive. The spam filter analyzes each message that arrives at the mail server. The filtering watches for words, phrases, URLs, and other key fields in an email message that indicates the probability that the message is spam. Messages exceeding a certain threshold during the SMTP session, are bounced or deleted.
• Bayesion Learning - a statistical process used to analyze spam and non-spam messages in order to increase the reliability of spam recognition over time.
• SMTP Authentication - anyone attempting to send through the mail server must have an authenticated session.
• Relay Settings- this server does not relay mail for foreign domains. Sender's address must be valid if it claims to be from a local domain. Consequently, messages sent through the mail server must either originate from or be destined for a local account.
• Tarpitting - deliberately slows down a connection once a specified number of RCPT commands have been received from a message’s sender. This is to discourage spammers from trying to use the mail server to send unrequested bulk email (spam). The assumption behind this technique is that if takes spammers an inordinately long period of time to send each message then that will discourage them from trying to use the server to do so again in the future.
• Reverse Lookups - are performed on the domain passed in the HELO/EHLO and/or MAIL commands. When performing the lookups MDaemon will attempt to acquire all of the MX and A record IP addresses for the given domain. Then the IP of the mail server making the connection is compared to this list in an attempt to determine whether the sender might be forging their identity. Oftentimes the sending mail server’s IP address will not match any known MX or A records for a given domain and yet still be delivering the mail legitimately. The Reverse Lookup process does not exclude mail but it's important to include as much information as possible for Heuristic Analysis in determining the fate of messages containing the header.
  
  Similarly, reverse lookups are performed on pointer (PTR) records of incoming IP addresses. Additionally, mail from sources that identify themselves by using a domain that does not exist is not accepted.
• Content Filter - customized to take actions on certain messages based upon the content of headers or message body.
• Address Suppression - blanket policies are in place to protect against known spammers by refusing mail during the SMTP session.
• Host Screening - specifies the names of remote host IDs that will or will not be accepted. When an incoming SMTP connection specifies the name of the remote server in the EHLO or HELO parameter, it is compared to the list. If a match is made, the session is either allowed or disallowed.
• IP screening - connections from certain known IP addresses are banned from even connecting to the mail server. Connections from these IPs are flatly refused before an SMTP session can even be started.
• Dynamic screening - Dynamic screening prevents abuse by tracking the behavior of senders as they deliver mail.
• DomainKeys (DK) and DomainKeys Identified Mail (DKIM) are cryptographic email verification systems that can be utilized to prevent spoofing (forging another person’s email address in order to pose as a different message sender). Additionally, because most junk email (spam) messages contain spoofed addresses, DK/DKIM helps greatly in the reduction of spam even though the specifications weren’t specifically designed to be an anti-spam tool. DK/DKIM can also be used to ensure the integrity of incoming messages, or ensure that the message hasn’t been tampered with between the time it left the signing mail server and arrived at yours. In other words, with DK/DKIM cryptographic verification the receiving server can be certain that the arriving message is from the server that signed it, and that no one changed that message in any way.
  
  In order to ensure the validity and integrity of messages, DK/DKIM uses a public and private key-pairs system. An encrypted public key is published to the sending server’s DNS records and then each outgoing message is signed by the server using the corresponding encrypted private key. For incoming messages, when the receiving server sees that a message has been signed, it will retrieve the public key from the sending server’s DNS records and then compare that key with the message’s cryptographic signature to determine its validity. If the incoming message cannot be verified then the receiving server knows it contains a spoofed address or has been tampered with or changed. A failed message can then be rejected, or it can be accepted but have its spam score adjusted.
• SPF/Sender ID - MDaemon supports both Sender Policy Framework (SPF) and Sender ID Framework to help verify sending servers and protect against spoofing and phishing, which are two common types of email forgery in which the sender of the message attempts to make the message appear to be coming from someone else.
  
  Many domains publish MX records in the Domain Name System (DNS) to identify the locations permitted to receive mail for them, but this doesn’t identify the locations allowed to send mail for them. SPF is a means whereby domains can also publish sender records to identify those locations authorized to send messages. By performing an SPF lookup on incoming messages, MDaemon can attempt to determine whether or not the sending server is permitted to deliver mail for the purported sending domain, and consequently determine whether or not the sender’s address may have been forged or 'spoofed'. Sender ID is related to SPF, but it is more complex in order to more reliably determine the actual domain purported to have sent the message, and to reduce the likelihood of incorrect results.

Getting Started