Change Log

• Add hourly SpamAssassin rule updates from the FSL rules repository
• Speed up reports where a summary table can be used
• New option to enable/disable forced sub-domain routing for a domain
• Change ‘Click Whitelisting’ page to display TTLs in seconds instead of minutes.
• Fix quarantine report links when displayed on Webmail clients that do not support the use of the HTML tag.
• Strip any accidental whitespace from report filters
• Fix SQL error when non-boolean operators are used on boolean fields
• Fix handling of ‘like’ operator when applied to the ‘Client IP Address’ field in the reports.
• Fix pager display when the ‘Back to report’ button is clicked from the Message Detail page.
• Add pager and ‘Back to Reports’ button to the bottom of the page in the Message Listing report.
• Fix the storage and display of comments in the Exception List editor.

MailScanner

• Allow MIME boundaries with leading spaces but not trailing spaces.
• Add missing dependency for unrar

ClamAV

• Upgraded to 0.97.8

Haraka

• Move sender_auth plugin run order as soon as possible after mail_from.is_resolvable
• If +one-domain-per-session is enabled – only enforce this if the domain cannot be linked to the connected system.
• Improve the greylisting algorithm where the IP address is being used as the host_id but the host can be linked to the sending domain.
• Always run MX records checks even if -mail-require-mx is set.
• Introduce a ‘strict’ mode for check_replyable plugin. The new default is to look up Reply-To, From and Sender headers in that order and to skip the rest as soon as an address is parsed. Strict mode checks all of the headers and they must all resolve to a valid MX.
• Fix incorrect SPF result when an exists: modifier is used and the lookup returns NXDOMAIN.
• Skip any SPF temporary failures if the sender can be authenticated to the connected host.
• Remove any whitespace from input before checking for MX
• check_replyable plugin updated to use the new address-rfc2822 module to parse e-mail addresses from Sender, From and Reply-To headers.
• Improve call-ahead mechanism return codes and error handling. Make sure QUIT is sent in response to 4xx errors received from upstream server before dropping the connection.
• Add X-Haraka-Relay and X-Haraka-RcptSummary headers as trace headers
• Improve concurrent rate-limiting by making concurrency limits process-wide by moving management of concurrency values into the master process.
• Minor fix to data.uribl plugin to check that returned DNS result is an array and not just an empty string.
• Improve handling of access-map DISCARD action when applied by a user-level rule with a multiple recipient message. Other recipients with conflicting actions will now be deferred to force the sender to retry the recipients with matching preferences again later.
• Allow for listening on multiple ports through the same daemon (e.g. port 25 and port 587)
• Move startup/shutdown log level to NOTICE (was INFO)
• Improve parsing of invalid UTF-8 and messages with broken character encodings
• Add new ‘Domain Info’ plugin that provides metadata and a ruleset to SpamAssassin to combat some new types of spam that use freshly registered domains (e.g. < 1 day old) along with looking for common signs of domain configuration used by spam domains.
• Improve async handling of connection timeouts
• Disable SMTP AUTH if -smtp-auth-enable set in smtpf.cf
• Add exponential delay for SMTP AUTH failures to prevent dictionary attacks (1, 2, 4, 8, 16, 32, 64 seconds)
• Add exponential delay for invalid recipients (1, 2, 4, 8, 16, 32, 64 seconds) for incoming domains that correctly reject invalid recipients at SMTP time.

The post BarricadeMX PLUS 2.1.10 Release Notes appeared first on Fort Systems Limited.

Domain .pw is the country code top-level domain for Palau. It was originally delegated to the Pacific island nation of Palau in 1997. It has since been re-delegated a number of times, most recently by Directi, a group of businesses operating registrars amongst other Internet-related services, who re-branded it as the Professional Web.  From March 25, 2013, domains under the .pw TLD are available to the general public.  These domains are sold at rock bottom prices which have apparently attracted droves of spammers.

Since we have yet to see a legitimate piece of mail for the .pw domain but have recently seen massive amounts of spam from this domain, we are recommending that you block mail form this domain as soon as practical. It’s quite simple to do:

BarricadeMX PLUS users should Use the web interface to navigate to: Setup  >> Access Map and add and save the entries:
key              value
from:pw       REJECT
body:pw      REJECT

BarricadeMX users should Use the web interface to navigate to the ACL tab  to add and save the entries:
key             value
from:pw      REJECT
body:pw     REJECT

MailScanner Gold customers should add to the /etc/mail/access file:
from:pw               REJECT

And if you are a Mailscanner Gold customer who also uses Snertsoft’s milter-link application also add to the /etc/mail/access file:
milter-link-from:pw       REJECT
milter-link-body:pw      REJECT

And then all MailScanner Gold customers should run:
make -C /etc/mail

If any legitimate sender ever sends a mail to your site, they will immediately be informed their mail was rejected.

Questions to support@fsl.com please

The post Top Level .PW Domain source of spam outbreak appeared first on Fort Systems Limited.

•  A spam increase of 150% in February compared to January
•  A spam increase of 210% March (to date) compared to January

Not all of this is getting through our filters. We’re still catching most of the older types of spam at the same rates but we are now seeing two new types of spam.

Yahoo spam is not really new since Yahoo has been the major source of “freemail” spam for quite a while now. But now it looks like spammers are really starting to take advantage of Yahoo’s failure to crack down on account hacking and spammer owned accounts.

Spammers seem to be having a lot more success hacking Yahoo accounts and spamming their address books. These spam messages seem to come from an email address that you are familiar with (but not necessarily from Yahoo) and contain little or no text and a URL. Although the address may not be from Yahoo, the sending server is a Yahoo server,

The second type of Yahoo spam comes from a valid account at Yahoo that’s owned by a spammer. They also typically  contain little or no text and a URL. These spams are often Loan, Green Coffee or “buy something” types of scams.

These spam are more difficult to properly identify since:

• They somewhat resemble real emails
• They contain few, if any, obvious “spammy” words
• They are DKIM signed by Yahoo as vaild emails
• They use a multitude of shortened URLs that point to a spam payload
• They appear to be lower volume spam runs that take a while to hit the URI DNS BLACKLISTS

In addition to the increased Yahoo spam, the spammers are using a new technique. They register a large number of new domains and immediately start using them to spam. Typically they time the spam run to start just after the RBL’s that list new domains have just finished their daily download of new domains. This gives the spammer 24 hours before the rules that limit spam from newly registered domains know that they exist.

But we haven’t been idle. We have already updated your systems with some new rules specifically created to trap these new types of spams. We are also actively testing new tools to trap the newly minted domain spam and expect to be able to automatically update your systems with these tools in the near future.

Just before the spam volume was ratcheted up, we had already started work on automating the processing of all the spam you report. We are happy to report that this work will make it easier for us to react more quickly to new types of spam.

While we would like to share the details of this work with you, for obvious reasons, we’d prefer not to put that information in an email. We’ll be making more announcements as the results of our research and testing work are deployed to your production systems.

Please feel free to contact us if you have any ideas or concerns.

FSL Support Team

The post Increase in Spam Activity – Yahoo Major Source appeared first on Fort Systems Limited.

Our BarricadeMX products have supported greylisting since they were first released. From the beginning, our greylisting used custom modifications to make it more acceptable to businesses and to address some of the original method’s shortcomings.

As we have started working on what will become the 3rd version of the BarricadeMX SMTP engine; I started by looking back at support issues over the past few years to see what we could do better and decide what should and should not be present in the new version.

As part of that review process – I started looking again at greylisting; should we keep it or should it go? I had found a number of tickets where we had advised customers to whitelist servers because they didn’t handle greylisting at all. But was this reason enough to get rid of it completely? Is it still effective?

Read more here….

The post Greylisting…revisited appeared first on Fort Systems Limited.

Today I’m happy to tell you that we are now working on bringing the Haraka engine to our BarricadeMX customers. We will also be adding additional updates and features to BarricadeMX that are not yet part of BarricadeMX Plus. These improvements will include:

• A new web interface written in Node JS
• New High speed logging and reporting
• A new Bayesian classification engine

Along with many other new, advanced spam detection technologies. This upgrade should be available this spring.

We are also glad to announce that this major upgrade for BarricadeMX will be a “No Charge” upgrade for customers that are current on their maintenance contracts.

For those of you who don’t want to wait for the Haraka version of BarricadeMX or need the additional features provided by the new version of BarricadeMX Plus, we will be offering discounted upgrade pricing packages for upgrading from BarricadeMX to BarricadeMX Plus. Please contact robin@fsl.com for details, demos and pricing.

We are also looking for sites that would like to participate in the Beta testing of BarricadeMX so please send an email to support@fsl.com if you are interested participating in the Beta program.

As always, we very much appreciate your business and look forward to bringing you the very best anti-spam products available.

Best regards,

FortAntispam Support Team

The post BarricadeMX Updates Coming Soon. appeared first on Fort Systems Limited.

Here is what we’ve been working on:

1. BarricadeMX PLUS gets new SMTP level filtering application.  This is huge. We’ve completely rewritten the Level One filter and it’s awesome. Get more details below.
2. New Website.  Check out our new look at www.fsl.com.  As always, your comments and suggestions are welcome.
3. Monthly Tech & Admin Live Forum.  Do you have questions or just need some help and would like to be able to talk to us live? We are listening and starting in October you will be able to sign up for a web conference where you can bring your questions, concerns and any new ideas to share with us.  Keep an eye on our website for the date and how to register for the event. I will also send out a reminder before the event.

BarricadeMX PLUS gets new Level One Filtering Replacement

As you all know, spam and security is a moving target.  Our commitment has always been to be on top of spam and virus security solutions to ensure our customers have the most reliable, accurate anti-spam and anti-virus software available. Our current filtering application, smtpf, did the job diligently for many years, but the time has to come for a modern replacement.

Our criteria for the toolkit required to rebuild our software included:

• A Rapid development language
• Event based, single thread multi-process model
• Excellent performance
• Highly Scalable
• Easy to extend and prototype new features

Our search turned up a new Event Driven Service Oriented Architecture and a new programming language Node.js that supported it. Node.js is a relatively new programming language built on the Google v8 JavaScript runtime engine which is used by Google Chrome.  In a recent test, a single Node.js server gracefully handled over 1,000,000 concurrent connections.

We were also very impressed by a new open source project Haraka, a new SMTP email server written in Node.js.  Even in its early stages of development it was clear that Node.js with Haraka was very fast, highly scalable and could provide the ideal base toolkit for improving BarricadeMX, so we started contributing to the project by adding improvements and fixing existing bugs.

We then spent some time looking at old support tickets and using our experience of the existing product to work out where we could make the biggest improvements.  A year later we’re now running Haraka in production on our own mail systems and several other beta sites. Haraka replaces the smtpf application that provides external Simple Mail Transfer Protocol (SMTP) services and Level One spam, malware and virus filtering for our BarricadeMX Plus software.

Haraka’s performance and features are impressive. A short list of the improvements we’ve seen so far includes:

• Substantial improvements in speed and capacity.
• Built in support for HAProxy, an open-source high performance TCP/HTTP Load Balancer which allows for massive scalability and flexibility
• Improved resilience; Haraka has a master process which starts one Haraka child process per CPU and will restart any failed child process to ensure there are no service interruptions.
• Simplified and improved logging
• Much improved foreign language detection.
• Improved administration/troubleshooting; handling information written to X-Haraka-* message headers
• Improved DNS list handling.  All lists are periodically tested to make sure they are working and are disabled if not to prevent timeouts from impacting message flow.
• Improved connection handling; connection pools are used for SMTP recipient verification and message forwarding.
• Improved rate-limiting; connections are tar-pitted when connection rate limits are exceeded to prevent excessive re-connections from a host.
• Built-in alerting for outbound message scans; notifies admin on suspicious activity (rate limiting, from domain with no MX, from domain not local or sending a message cannot be replied to).
• Improved recipient verification; should remove the need to ever clear a recipient from the cache again.
• Simplified greylisting
• SQLite shared cache database is replaced by Redis for improved speed and scalability
• Greatly improved watermarking functionality
• Additional checks for messages with valid envelope containing From/Reply-To headers that cannot be replied to.
• New ‘sender authentification’ functionality allows stricter restrictions (e.g. rejection of servers with no rDNS or where their IP address appears within the rDNS and strict EHLO/HELO checking) but allows messages through when the from domain can be matched in some way to the IP address or rDNS name of the connected host (e.g. by SPF, DNS checks or nearby checks).

The other good news is that Haraka is a complete drop-in replacement for the smtpf application.  Haraka uses the same configuration files and web interface as smtpf. There is nothing new to learn – just enjoy a substantially improved application.

And this is just the first in a series of improvements we’re working on. Over the next six months you can expect us to release several other major updates to our Fort anti-spam software family. All I can say at this time is these updates will result in a virtually spam free email experience.

But the best news is that the Haraka Beta is over.  Next week you will receive a notification that our YUM repositories have been updated to replace smtpf with Haraka and as usual there is no charge for the update if your site is current on maintenance. You can just sit back and enjoy the improvements. If you are not on Support & Maintenance with us, please contact us at info@fsl.com and we will be happy to sign you up.

If you are using BarricadeMX standard version, do not worry, we didn’t forget about you!  We will be releasing an update to your version soon. We’ll keep you posted on furtehr developments.

Please contact support@fsl.com if you need assistance or have any questions.

Best regards,

Fort Support Team
www.fsl.com
support@fsl.com
202.595.7760
–

The post Fort Systems Announces New Filtering Application for BarricadeMX Plus appeared first on Fort Systems Limited.

This is Part 5 of a five-part series on understanding how email works.  This is based on a presentation I gave at Florida State University to a graduate level class for Computer Systems Administrators.

In part 5 of a series of blogs and videos in understanding email, I’ll explain how to manually send email and explain to you how forged emails are created.  This may help you in troubleshooting email issues.  To watch the video presentation with screen shots, check Fort’s YouTube channel.

Email Message Format
All email messages have three distinct parts – the envelope, the header and the body.

Envelope

• The envelope always contains on the From: and To: Addresses. The actual recipient must be specified in the Envelope and does not have to match any From: addresses that might appear in the Header or Body of the message.

Header

• The header which contains the Reply to: and From: email addresses, the Received headers and other Administrative data. We’ll look at a typical header next.

Body

• The Body is the final part of the message. The Body is typically what you see when you open the the email message.

The Header of a message typically contains the subject, data, to, return-path and delivered-to, followed by the Received headers. These received headers show the path the message took to get to its destination and the time each mail relay received the message.

The Received headers are followed by administrative data that can be useful when trying to troubleshoot email formatting or delivery problems.

Depending on the actual MTA (mail transfer agent) that participated in relaying the message, the format and content of the headers can vary but these basic elements should always be shown.

In the actual body of the message, the look and feel of the message can also vary greatly, from plain text content to flashy HTML.  But remember that it’s better to use simple formatting and colors when creating emails since simple formats and colors more often arrive intact in the recipient’s mailbox.

How to Detect Forged Emails and how Forged Emails are Created
I’m going explain to you how to manually send an email and at the same time, show you how easy it is to forge an email.

What I’ll now show is a copy of the conversation I had with the MTA process on an email server that delivered my forged email. The grey text is the system prompt on the mac terminal. The red text is what I typed to create a connection with an email server and send an email.

The blue text blocks are the responses from the email server. While I used a mac terminal, a windows cmd shell or a terminal on a Linux system would work just as well. In fact any system terminal that can access telnet session would also work.

The first line I typed initiated a telnet session, connected to port 25 on the email server. Then mail server replied, showing that I’ve connected, the IP address that I’m connecting from and a 220 code that tells me that it’s to Proceed to the next step in the protocol. Notice that as we proceed, the mail server always starts it’s reply with 3 digit code.

While there are many possible codes, they all fall into 3 groups:

1. Codes starting with 2 or 3 mean OK and continue
2. Codes starting with 4 mean there has been a temporary failure of the delivery but please try again later
3. Codes starting with 5 indicate there has been a permanent failure, do not try to send the message again.

So I respond to the connection with what’s commonly called the HELO response; HELO followed by the named of the domain that I intend to send email for, in this case northpole.com. I can get away with forging email that appears to come from the northpole since nortpole.com does not publish authoritative SPF records.

After receiving next 250 response I send the senders email address, note the format: mail from:<emailaddress>. Email addresses must be sent in exactly this format or you will get an error.

After the sender’s address has been accepted, I send the recipient’s email address.

After the recipient’s address has been accepted, I send the DATA command. This tells the receiving server that I next intend to send the body of the message.

When I receive the 354 code, I send the body of the message. When I finish transmitting the message I send a period on a line by itself to signify that I have finished sending the data. Note that the header of the message is created and sent automatically.

After I receive the next 250 code, I know the message has been accepted for delivery so send the quit command which allows the email server to close the connection.

Now know how to manually send an email and just how easy it is to forge an email.  Remember that anything other than the sender’s IP address and published PTR record can be forged.

If you publish SPF records for your domain, at least many sites will be able to detect and reject the forged messages that pretend to come from your email servers.

The post Understanding Email, 5 of 5 – Manually Sending Email & How Forged Emails Occur appeared first on Fort Systems Limited.

In part 4 of a 5 part series of blogs and videos in understanding email, I’ll explain how email applications use Domain Name Service or DNS.  To watch the video presentation, check YouTube.

How DNS Came About

Domain Name Service more commonly referred to as DNS provides the underpinnings for the Internet.  So it should come as no surprise that if DNS fails, email delivery fails.

Since the first computers weren’t networked. They didn’t need names or numbers.

And the early networks used different competing network schemes so the alos used different naming schemes.  All of the different schemes had one thing in common – the addresses that the system on the network used to identify and route data were based on numbers.  Computers like numbers, but we find names a lot easier to remember and use.

Early networks used a hosts.txt file that mapped the computer name to it’s network number. That hosts file was virtually identical to the hosts files that are used by computers today, except that the original hosts file had the name and address of every computer on the network – and every computer downloaded this file every night.

In the early 80s there were over 10,000 hosts in the hosts.txt fuel and the process became unsustainable. So in 1983, Jon Postel and Paul Mockapetris invented the Domain Name System and wrote the first application that provided DNS services.

In 1985, the The Berkeley Internet Name Domain or BIND Server was released. By the time BIND was ported to the Windows NT platform , BIND and DNS along with the numbering scheme it supported had become the glues that held the internet to together.  That scheme is still in use today, but we’re running out of numbers.

The original numbering scheme, designated IPv4 was a 32 bit numbering scheme which allowed for over 80 million unique addresses. This seemed like a LOT in 1980 but on February 3, 2011  the last batch of five top level address blocks were assigned to the Regional Internet Registries, officially depleting the global pool of completely fresh blocks of addresses.

The solution to this problem is the IPv6 numbering scheme. – a 128 bit addressing scheme. This will allow allow everyone alive today to have a little over 4.8×10²⁸ personal IPv6 addresses addresses.

What DNS provided was a structure of top level domains like .com .net and .gov to which  additional levels could be added to create domain names like microsoft.com and sub-domians like  cs.berkly.edu. They form the human friendly network name space consisting of a tree of domain names.  This hierarchal structure along with the BIND application, allows for each domain to maintain and publish the hostname to number mapping for the systems they control and for these records to be almost instantly available to anyone with access to the network.

DNS records types used by email applications.

A DNS type A record maps a Fully Qualified Domain Name, commonly referred to as a FQDN to an IP Address.

A DNS type PTR record maps an IP Address to a FQDN.

A DNS type MX or Mail eXchanger record maps a Domain Name to a list of hosts that will accept email for that domain – along with a number that shows the order in which the delivery to the host should be attempted. This is the record that makes email delivery to individual mailboxes possible. Your Mail Server sends the message to the mail server for the recipient’s domain and that server knows how to deliver the email to the right electronic mail box.

Two other types of DNS records are use by mail deliver systems to help detect spam and forged emails:

An SPF record is a TXT or text record that a site administrator can create to specify exactly which servers are allowed to send email for a domain.

A special type of PTR record has been created to allow anti-spam systems to quickly check the reputation of a IP address, hostname or a URI and see it is in use by a spammer or other criminally controlled site.

How email applications use DNS to deliver and filter email

A DNS lookup of the Fully Qualified Domain Name returns the IP address.

A DNS lookup of the IP address returns the Fully Qualified Domain Name.

A DNS lookup of the Domain for a Type MX record returns a list of the hosts that will accept email for the domain and a number that indicates which is the preferred server.

A DNS lookup of the Domain for a Type TXT record typically returns the SPF record if one exists.

And a lookup for a of a specially formatted A record against a DNS Real-Time Black list returns an IP address that is a code which indicates if the data is listed in the RBL.

When your mail hub starts to send your email the first thing it does is to look up the MX records for the recipient’s domain. Once it has this information, it tries to establishes a network connection to the preferred MX server.

Once the connection is made, the receiving MTA has the IP address of the sender. This IP address is about the only thing in the email transfer transaction that cannot be forged. The receiving MTA immediately does a DNS PTR lookup to get the Hostname of the connecting server. Since the receiving server now has the senders IP address, it may now check the DNS SPF record to see if the connecting server is authorized to send mail for domain of the sender. (Note: Publishing SPF records is not required but I strongly suggest that every domain that sends email publish SPF records. It the only way to prevent a scammer from forging emails that appear to come from your domain. )

Once the message is accepted, most sites apply some type of spam filtering and most spam filtering applications today, run checks that employ DNS checks against Real Time Blacklists. It’s not unusual for an anti-spam application to make 20 to 40 separate DNS queries while processing a single message. In fact when mail delivery slows down, the first thing to check is the speed of the DNS queries.

More detailed information on creating and using SPF or Sender Policy Framework Records please visit the Openspf.org website.

And for a detailed explanation of how DNS Real-time Blacklists work, please see the Wikipedia entry for DNSBL.

The post Understanding Email Part 4 of 5 – Domain Name Service appeared first on Fort Systems Limited.

This is Part 3 of a five part series on understanding how email works.  This is based on a presentation I gave at Florida State University to a graduate level class for Computer Systems Administrators.  This presentation is about email protocols.

There are four main email protocols:

• POP: the Post O ffice Protocol
• IMAP:  the Internet Message Access Protocol
• SMTP: Simple Mail Transfer Protocol
• MAPI: the Messaging Application Programming Interface as defined by Microsoft

POP and IMAP are used to transfer email from a mail hub to a client mail tool while the SMTP protocol is used to transfer mail from a client mail to a mail hub and between mail hubs on the internet.  MAPI is used to transfer mail and other data between Microsoft’s Outlook email Client and Microsoft Exchange servers.  Note that Exchange servers also support POP, IMAP and SMTP Protocols to allow them to transfer email to non-Microsoft email clients and mail servers.

The first RFC to define how a MUA or client mail tool could retrieve and modify emails from a central mail Store or email server was POP. the Post Office Protocol. the first POP RFC was released in  1984 and, with modifications, POP is still in use today.

But the Internet Message Access Protocol, released in 1988 and updated many time ssince, provides more features than POP. The main advantage IMAP has over POP is that IMAP allows many devices, like your phone, computer and tablet to share the same view of a central Mail Store, so IMAP it should probably be the protocol to select if you need to synchronize email across multiple devices.

POP and IMAP are the protocols commonly used to fetch mail from your email server to your email client on your computer or mobile device. But SMTP is the protocol most often used to send mail that you have composed on your email client to your email server, and then from your email server to the recipient’s email server.

In fact while there are several possible protocols that can be used to send or fetch email between  mail clients and mail servers,  the Simple Mail Transfer Protocol is always used to send mail from mailhub to mailhub if the message travels across the Internet. It is the SMTP protocol that made universal email exchange possible.

As English is the universal language for pilots and air controllers SMTP is the  universal language for Internet postmasters and email traffic.

The SMTP Protocol was first defined by RFC 821 in 1982, before the Internet as we know it even existed. Currently RFC 2821 defines the basic protocol for the Internet electronic mail transport, while RFC 5321 consolidates, updates, and clarifies many earlier RFCs.  It also covers the SMTP extension mechanisms and best practices for the contemporary Internet.

And finally there are Microsoft’s MAPI protocols. If you use Microsoft Outlook as your email client and Outlook is configured to use Microsoft Exchange for it’s email server, Outlook and Exchange are transferring data using Microsoft’s Messaging Application Programing Interface. Also any third party application that works with Exchange or Outlook will use MAPI Protocols to connect. But even the Exchange Server typically uses the SMTP Protocol to transfer email to external sites.

More information on these protocols can easily be obtained by searching for the protocol name in Wikipedia. And the RFCs can be found by searching Google for the RFC nomber. The RFCs are actually fairly easy to understand, even without advanced technical computer skills.

The post Understanding Email Part 3 of 5 – Email Protocols appeared first on Fort Systems Limited.

This is Part 2 of a five part series on understanding how email works.  In Part 2, I’ll review email applications.  You can also watch our video blog to learn more.

The average user thinks that email is as simple ‘I send mail from my computer to your computer.’ But the reality of what happens is a little more complex.

The email process begins with a sender and the application they use to create and send the email. The technical name for this application is a Mail User Agent or MUA – also commonly called a Mailtool.

After the sender created the message, The MUA then uses a Protocol to forward the email to a Mail Hub. A Protocol is simply an agreed upon methodology to accomplish a task. The most commonly used Protocol for sending email is the Simple Mail Transfer Protocol or SMTP.

The Mailhub is simply a computer that can both store and forward emails. To forward the mail onto the recipient the MailHub uses an application known as the MTA or MailTransport agent.

The MTA also uses the SMTP protocol to forward the email on, possibly directly to the recipient, if they use the same mail hub or though gateways and the Internet to the recipients mailhub where the message is stored.  The message is finally delivered when the recipients MUA contacts their mailhub and retrieves their messages using POP, IMAP or MAPI protocols.

So to quickly review Applications and Protocols, the sender of an email uses an Application known as the MUA, or Mail User Agent, to create and send an email off to a Mailhub.

The Mailhub uses an application known as the MTA, or Mail transport Agent, to receive, store (if necessary) and then forward the email to the next hop on the way to its final destination, the recipients mailbox.

The Internet Protocol Request For Comments, more commonly referred to as RFCs, are the protocols that enable each computer on the Internet to communicate with other computers by exchanging of packets of digital information. The protocols that enable email to be exchanged across the internet are:

POP: the Post Office Protocol
IMAP:  the Internet Message Access Protocol
MAPI: the Messaging Application Programming Interface as defined by Microsoft

The most commonly used email Client and Server Applications:

Microsoft Outlook is the most commonly used email client with over a 25% market share. Outlook supports POP, IMAP or MAPI protocols can be used to connect to a Microsoft Exchange mail server or any mail Server that support’s POP Or IMAP – and that will cover almost any other email server. It’s a very powerful email client but with the power comes complexity and higher support requirements.

Thunderbird is a free, open source, cross-platform email and news client developed by the Mozilla Foundation. The basic version is not a personal information manager, although the Mozilla Lightning extension adds PIM functionality. In fact many additional features are available via other extensions. Power email users and users who read email on a variety of devices and operating systems should definitely consider using Thunderbird as their email client.

Apple Mail provides a completely integrated mail client for Mac OS users. It’s definitely the mail client of choice for most Apple users.  However it does lack some of the more advance features and extensions of Thunderbird.

Webmail clients are the most popular email clients. Hotmail, Gmail and Yahoo are the used by over 28% of all email users and provide some advantages over traditional email clients:

• Typically they are free services
• Accessible from any computer or mobile device
• Simple to use
• Reliable
• Automatically backed up

So for a user with simple email needs, Webmail might well be their first choice.

But the workhorses of the Internet are the Email Servers. It’s been estimated that over 90% of all traffic on the internet today is email – so some of the busiest servers on the Internet are email servers.

And while there are many Mail Transport Applications, the largest percentage of email servers today are powered by Sendmail written by Eric Allman in the early 1980s.

While Sendmail supports a variety of mail transfer protocols, almost all email traffic today is sent using the SMTP or ESMTP the Extended Simple Mail Transport Protocol.  Sendmail is often considered to be a complex and difficult to configure application but it is a very flexible and extendable program as evidenced by it +30 year run as the leading MTA on the Internet.

Postfix is a free and open-source mail transfer agent. It is a popular and easier-to-administer alternative to the widely-used Sendmail. Originally written in 1997 by Wietse Venema while working at IBM. Postfix continues  to be actively developed an improved by its creator and other contributors.

Exim was written in 1995 by Philip Hazel for use in the University of Cambridge Computing Service’s e-mail systems. It is a free, fast, flexible and highly configurable MTA and provides a good alternative to Sendmail complexities and Postfix’s simple configuration but limited flexibility.

And last but not least, is the Microsoft’s Exchange Server. Exchange is the server side of a collaborative client–server application developed by Microsoft. It’s used primarily by enterprises, which employ Microsoft’s infrastructure products.

Exchange’s major features consist of email, calendaring, contacts and tasks that work with Microsoft Outlook on a PCs Macs. It also features wireless synchronization of email, calendar and contacts with major mobile devices as well as web browser-based access to its information and message store. It’s a very complete but relatively expensive and complex application that requires an experienced support team.

So while it’s been estimated that over 90% of all traffic on the internet today is email, unfortunately over 90% of that email traffic is spam, malware or phishing scams. This mean that 80% of all internet traffic is unwanted and dangerous junk – So be careful out there.

The post Understanding Email Part 2 of 5 – Email Applications appeared first on Fort Systems Limited.