Google in partnership with the University of Michigan and the University of Illinois, has published the results of a multi-year study that measured how email security has evolved since 2013. Although Gmail was the foundation of the research, insights from the study are believed to be applicable to email more broadly.

The study also notes several new security challenges:

Regions of the Internet were found to be actively preventing message encryption by tampering with requests to initiate SSL connections. "To mitigate this attack, we are working closely with partners through the industry association M3AAWG to strengthen 'opportunistic TLS' using technologies that we pioneered with Chrome to protect websites against interception."

Group also uncovered malicious DNS servers publishing bogus routing information to email servers looking for Gmail. "These nefarious servers are like telephone directories that intentionally list misleading phone numbers for a given name. While this type of attack is rare, it's very concerning as it could allow attackers to censor or alter messages before they are relayed to the email recipient."

This seems to be one of the greatest mysteries to new postmasters. It can be confusing as the messages go to the SMTP MAIL FROM address, which can be different from, or the same as the from header. If you're reading this article, we would first suggest reviewing the article, "How to check an SMTP connection with a manual telnet session” as it covers the basics of the SMTP dialog.

The key to understanding bounces (sometimes referred to as DSNs, Delivery Status Notifications or NDRs, Non-Delivery Reports) is that they should always be sent to the SMTP MAIL FROM address. Some mail platforms may not adhere to this rule, but most do, so we'll focus on the majority of what you're likely to see. From review of the above mentioned post, there is the following sample SMTP session:

==================START SESSION==================
telnet mail.port25.com 25
Trying 69.63.149.30…
Connected to mail.port25.com (69.63.149.30).
Escape character is '^]'.
220 mail.port25.com (PowerMTA(TM) v4.0) ESMTP service ready
EHLO server.example.com
250-mail.port25.com says hello
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250-8BITMIME
250-XACK
250-XMRG
250-SIZE 54525952
250-VERP
250 DSN
MAIL FROM: <support@port25.com>
250 2.1.0 MAIL ok
RCPT TO: <support@port25.com>
250 2.1.5 <support@port25.com> ok
DATA
354 send message
From: "John Smith" <jsmith@port25.com>
To: "Jane Doe" <jdoe@port25.com>
Subject: test message sent from manual telnet session
Date: Wed, 11 May 2011 16:19:57 -0400

Hello World,
This is a test message sent from a manual telnet session.

Yours truly,
SMTP administrator

.
250 2.6.0 message received
QUIT
221 2.0.0 mail.port25.com says goodbye
====================END SESSION==================

In the above example there are two from addresses:

MAIL FROM: <support@port25.com>

And:

From: "John Smith" <jsmith@port25.com>

It is the former, the MAIL FROM address, to which bounces are sent. The latter, the 'from:' header, is part of the body of the message and is what shows in the email client as the sender of the message.

Of course, one might ask, how do I check the message to see where the bounces would be sent? This is easily done by checking the full headers of the message. Here are some examples of well known email clients and how to check the headers (assuming you are already viewing the given email in question:

• Yahoo – Click More -> View Full Header
• Gmail – Click the dropdown arrow next to the reply button -> Show original
• Hotmail – Click Actions -> View message source
• Outlook desktop client – Right click on the message and select Message Options
• Mac Mail – Command+Shift+H or View Menu -> Message -> All Headers

Once you have the headers in front of you, they should look something like the following:

From "Scott Habicht" Fri Nov 14 19:57:42 2014
Return-Path: <support@port25.com>
Received: by mail.port25.com id hcpfbm11u8kk for <example@yahoo.com>; Fri, 14 Nov 2014 14:57:47 -0500 (envelope-from <support@port25.com>)
From: "Scott Habicht" <support@port25.com>
To: <example@yahoo.com>
Subject: testing headers
Date: Fri, 14 Nov 2014 14:57:42 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=" — -=_NextPart_000_0075_01D0001B.57BC7570″
Content-Language: en-us
Content-Length: 2066

In the above example, it is very easy to the see the From: header, but what happened to the SMTP MAIL FROM address? Well, it is now shown as the Return-Path header:

The top entry was added by Yahoo:

Return-Path: <support@port25.com>

The Return-Path header represents the SMTP MAIL FROM address, where bounces would be sent. From section 4.4. "Trace Information" of RFC 5321:

"When the delivery SMTP server makes the "final delivery" of a
message, it inserts a return-path line at the beginning of the mail
data. This use of return-path is required; mail systems MUST support
it. The return-path line preserves the information in the <reverse-
path> from the MAIL command. Here, final delivery means the message
has left the SMTP environment. Normally, this would mean it had been
delivered to the destination user or an associated mail drop, but in
some cases it may be further processed and transmitted by another
mail system."

It is important to note that the Return-Path header should NOT be added by the application that creates the email as they would be ignored. The Return-Path header should only be added by a given SMTP server.

Additional reading: http://en.wikipedia.org/wiki/Bounce_address

Discover PowerMTA™ — Port25's flagship product, PowerMTA™, has a global footprint with more than 4,500 installations in over 51 countries.  Visit the Port25 Solutions, Inc. website for a full-featured trial evaluation copy of PowerMTA.

Within the digital messaging industry, an opportunity will sometimes arise for an email marketing manager to send a re-activation campaign to dormant email addresses, in order to galvanize subscribers who don't respond to your messaging.

From a deliverability perspective, some people feel that putting such a reactivation campaign on a shared IP address is OK. However, others feel that a dedicated IP is more effective, because it does not involve sharing IP space with your other, more reputable senders. In a shared environment, the cursory damage that might occur includes junking or blocking by ISPs due to old addresses that turn into recycled spam traps. Hitting a spam trap is not fun for any deliverability administrator and could have time-based ramifications for your more active senders.

To us, it's not so much about shared vs dedicated, but more about volume and how long the inactive subscribers have been dormant. For example, if a client has a small number of inactive subscribers (say 100) that haven't opened in 6+ months, then sending them a nicely crafted email saying, "this is our last communication" and throwing in an incentive to get them to engage should cause minimal fallout in a shared IP scenario.

Now, it's an entirely different situation if you have 200,000 subscribers that haven't had any activity in over a year. In that case, I would recommend taking a small control group and continuing to send to them as normal, probably on your dedicated IP. Remember that cadence matters to ISPs. Then, take a small random sample of the reactivation campaign and send an incentivized email. This email constitutes the true reactivation campaign to a segmented list. (Don't forget to segment your inactives.) By doing this, you will find common denominators in your inactive pool that could shed light on the stillness. You may give each segment its own VirtualMTA for granularity. At that point, you can compare the control to the test group. If the test group does the same as the control, then you will have to decipher the benefits of moving forward.

Let's assume that the subscribers you sent to in the test group have not shown any engagement. Then, in accordance with email etiquette, you would send them an "if-allowed" — one last email asking them to confirm their email to opt back in to your list. The "if-allowed" would be really geared toward the subscribers that haven't engaged or opened or clicked in over a year, as six months is most likely not enough time to accurately gauge subscriber engagement.

The deliverability risks of old addresses that are turned into spam traps or syntax errors are just too great for anyone sending off of a shared pool. The easy way out is to send the reactivation campaign from a less reputable dedicated IP, but we don't recommend this strategy either. It will probably do more harm than good.

If and when the time comes for you to reconfirm these addresses, to be safe, you could implement the process discussed earlier, and send them from a dedicated IP address, segmenting by domain and other parameters, and using VirtualMTAs for each segment. Think of the dedicated IP as an insurance policy, ensuring that you will not interrupt the flow of email from other good senders on your shared IP.

In these situations, there are no hard and fast rules. Email is a process and, after the send, listening to the stillness becomes your greatest asset. The goal is to come up with a smart plan for testing in order to pinpoint subscriber issues. Play with the segmentation; then, rinse and repeat. Staying proactive and always testing in your sending environment will help diminish the inactive roster. Stay patient and, ultimately, you will be able to see clear benefits from your campaign.

Discover PowerMTA™ — Port25's flagship product, PowerMTA™, has a global footprint with more than 4,500 installations in over 51 countries.  Visit the Port25 Solutions, Inc. website for a full-featured trial evaluation copy of PowerMTA.

Alexander Garcia-Tobar
CEO & Co-Founder at ValiMail

"ValiMail has created Distributed DKIM (DDKIM), a patent pending method that solves the traditional difficulties with DKIM key management and distribution."

Learn More ...Given the increase in email fraud (phishing) and an increasingly complex email landscape, it is increasingly important for email service providers to implement email authentication properly. As pioneers of email authentication, servicing 75% of the ESP marketplace, Port25 believes optimal inbox placement rates are based "on" proper authentication protocol.

Major ISPs (Gmail, Yahoo! Mail, Outlook, etc.) are pushing other senders to authenticate their email and are using a carrot/stick approach: Do it well, and your email gets through with high deliverability rates. Authenticate poorly, and your email will be downgraded with lower deliverability — and increasingly with warnings or a lack of graphics and identifying logos.

Here are two examples from Google and Microsoft showing what non-authenticating emails will look like starting in mid-2016. Note that Google will insert logos for authenticated email and "?" for non-authenticated email. Similarly, Microsoft will redact logos and graphics and add red indicators if an email lacks proper authentication. Authenticate properly, and the email will display a green shield and render all logos and graphics.

The DKIM Ideal

Given this environment, we wanted to write a quick post on one aspect of email authentication that trips up many ESPs: DKIM (short for DomainKeys Identified Mail). DKIM is an open, DNS-based email authentication standard that uses public-key encryption to authenticate email messages. There are several issues that an ESP should consider when implementing DKIM:

No Key Sharing: Each customer should have their own, dedicated DKIM key, and ESPs should avoid any key sharing between customers. When an ESP doesn't share DKIM keys between customers, a compromised DKIM key can only impact a single customer.

Regular Key Rotation: As recommended by the specification, DKIM keys should be changed (or 'rotated') on a regular basis, about 3-4 times/year. Rotation ensures that if a key is compromised for any reason (for example, by a hacker who obtains the private key), then the compromised key will only be useful to the attacker for a short time. Once the old key is rotated out and replaced with a new key, the compromised key is useless.

Store Private Keys Securely & in a Distributed Manner: DKIM private keys are extremely valuable, as they can be used by attackers to impersonate your clients in a virtually undetectable way. Given this, it's critical to use best practices for key management: Don't store private keys in plaintext, avoid maintaining a centralized database of keys, and follow best practices for PKI security.

The ESP DKIM Reality

Widespread Key Sharing: Because DKIM is relatively complex and proper key management is burdensome, it is common for ESPs to use the same key for all their customers. This simplifies configuration: ESPs can provide the same instructions to all of their customers, the same DKIM record gets inserted into every customer's DNS, and the sending infrastructure can use the same key to sign every message it sends.

Little to No Key Rotation: Also, because key rotation typically requires an ESP to manually update one or more DNS records — or even worse, have their customers manually update one or more DNS records — key rotation is extremely rare in practice. DKIM keys are typically set once and never changed, and it's common to see DKIM keys that are 5-10 years old in production use.

Centralized, Plain Text Key Storage: Finally, even if an ESP tries to do DKIM correctly — provide one DKIM key per customer, and rotate DKIM keys on a regular basis — the simplest solution is to store the DKIM keys for all their clients in a central database in plaintext, to simplify key management and distribution to the mail servers. Unfortunately this sort of architecture is a beacon to criminals, and makes it exceedingly easy to steal all of the ESP's customers' keys during a breach.

Given that at least several major ESPs have reportedly been breached over the last couple of years, this approach must be considered highly risky. As with any enterprise system, it's probably safe to assume that all ESPs have been breached at some point in the past 5-10 years.

So What's the Answer?

ESPs should use a DKIM system that supports frequent and automated key rotation, defines unique DKIM keys per client, and stores the DKIM private keys in a secure way.

With this in mind, ValiMail created Distributed DKIM (DDKIM), a patent pending method that solves the traditional difficulties with DKIM key management and distribution while adhering to this ideal. Though more secure and robust, DDKIM at the same time vastly simplifies the process and automates proper DKIM implementation and key management, accelerating the onboarding of new clients and allowing for quick key updates of existing clients.

Whether or not you are interested in DDKIM, feel free to drop us a line at info@valimail.com and we'd be happy to discuss DKIM further. Here's to automated and secure authentication!

Written by Alexander Garcia-Tobar, CEO & Co-Founder at ValiMail, a Port25 partner.

Discover PowerMTA™ — Port25's flagship product, PowerMTA™, has a global footprint with more than 4,500 installations in over 51 countries.  Visit the Port25 Solutions, Inc. website for a full-featured trial evaluation copy of PowerMTA.

The IGF this morning published a number of reports, including the aforementioned one here, titled 'IGF 2015 Best Practice Forum Regulation and mitigation of unsolicited communications.'

The reports can be found at the following URLs on the IGF Website:

• IGF2015 session reports/outputs for workshops, open forums, main sessions, other sessions, etc.

• Output reports from 2015 IGF Best Practice Forums

• Output reports from 'IGF Policy Options for Connecting the Next Billion'

• Reports Classified by Contributing Party

• IGF 2015 webcasts

• IGF 2015 Transcripts

Written by Neil Schwartzman, Executive Director, The Coalition Against unsolicited Commercial Email - CAUCE

In PowerMTA v4.5 and later versions messages can now be scheduled for delivery. This may be very useful for instances when it takes a long time to build a campaign or if there is a need to have a campaign go out very quickly (e.g. flash sales); therefore, the campaign needs to be in the queue and ready for delivery at the start of the event. The feature allows for scheduling multiple delivery windows.

The use of scheduled delivery in PowerMTA requires the addition of an x-schedule header to the email prior to injection into PowerMTA.

The format of the header is:

x-schedule: <start time - 1>/<end time - 1>, <start time - 2>/<end time -2>

Here is an example:

x-schedule: 2016-12-29 17:01:00 / 2016-12-29 17:30:00, 2016-12-30 17:01:00 / 2016-12-30 17:30:00

In the above example message, delivery will be started at 5:01pm (PowerMTA server time) on Dec 29, 2016. The delivery attempts will stop at 5:30pm Dec 29, 2016. Delivery attempts will resume on Dec 30, 2016 at 5:01pm, and if not delivered will bounce out of queue on Dec 30, 2016 at 5:30pm.

As many delivery windows as needed are allowed, as long as the headers are folded so each line is not longer than 1000 characters.

The bounce-after does not apply to recipients scheduled for delivery with the x-schedule header. The schedule overrides the defined bounce-after and the message is bounced when there are no more schedules to try. In addition, if the queue is in retry mode when the messages are injected, the message delivery will not start at the window start time, but rather message delivery attempts will start when the queue comes out of retry mode.

For strict adherence to the schedule start time for large campaigns (e.g. flash sales), it is required to set the same jobID for all recipients of the given campaign. For best results, customers should ideally use the same schedule for all the recipients in a job, and not mix scheduled and unscheduled recipients in a job. Messages with the combination of Scheduled Delivery Control and a jobID will use the start time defined by the first message for the job injected into the queue.

For example, if the first recipient in the queue for jobID 123 has a start time of 12pm, and the second recipient injected into the queue for the same jobID has a start time of 11am, the 12pm start time will be used for both recipients. Likewise, if the first recipient in the queue for jobID 123 has a start time of 11am, and the second recipient injected into the queue for the same jobID has a start time of 12pm, the 11am start time will be used for both recipients.

Discover PowerMTA™ — Port25's flagship product, PowerMTA™, has a global footprint with more than 4,500 installations in over 51 countries.  Visit the Port25 Solutions, Inc. website for a full-featured trial evaluation copy of PowerMTA.

Last month I attended the 36th annual M³AAWG conference in San Francisco, where esteemed members of the online messaging and anti-abuse community come together to make the Internet a safer and more secure environment.

The sending community is highly influential especially among Email Service Providers (ESPs) and truly dominated the two-macro conversations that I participated in. These conversations have the industry in somewhat of a transition.

The two issues are partly responsible for transforming other parts of the overall IT ecosystem. The first is the "movement" of IT resources from on-premises solutions to the cloud, and the second is deciding between open source and commercial email infrastructure to power email applications and business processes.

On-premises vs. Cloud

Increasingly on-premises vs. cloud for email is not necessarily an "either / or" decision.

A hybrid email infrastructure solution may make sense for large enterprises as a bi-lateral deployment option in your sending environment. A hybrid cloud is a cloud computing environment that uses a mix of on-premises and cloud resources (public or private) with orchestration between the platforms. Programmatic and agile workloads, and/or distinctive message streams may float across private and public clouds as messaging demands and cost structures change, giving enterprises greater flexibility among deployment platforms.

So how can you determine how best to leverage the strengths of both an on-premises Mail Transfer Agent (MTA) and an outsourced cloud email delivery provider? The key is to maintain a focus on the objectives being pursued and understanding your existing architecture and processes as they pertain to email.

For example, logical reasons for adopting cloud infrastructure may include redundancy and disaster recovery and the ability to quickly "burst up" in capacity without requiring additional internal IT investment. If these are your objectives, you might look at a cloud partner which offers adaptable service level agreements (SLAs) that meets your standards. You should also make sure that the data flow between your on-premises MTA and the cloud is secure and congruent, so confidential information is protected.

Reporting is another important consideration. In all likelihood your internal email infrastructure will offer a different set of metrics than your cloud delivery solution.

In a hybrid environment, having delivery data in silo's is a challenge. So getting your cloud delivery service provider to offer blended data sets with your on-premise solution is key. You should understand going in how you will consolidate and standardize the data so that visibility is maintained into your overall email performance. Both front-end and back-end delivery analytics are at play among dozens of important metrics.

Port25 Data Snippet: The graphic to the right depicts US based cloud email infrastructure "interest" among five hourly volume buckets. While there is some cloud interest among senders that send more than 1M per hour, 61% of our evaluation requests, have expressed interest in cloud-infrastructure that send between 50K hourly messages or less.

Open Source vs. Commercial MTAs

In regards to Open Source vs Commercial MTAs, there is considerable traction towards commercial MTAs. Early stage ESPs which implemented various forms of "open source" MTAs which go by various names, including postfix, sendmail, qmail, Exim, have grown out of these platforms and onto more sophisticated platforms. Within the Port25 sending ecosystem, many ESPs and Enterprises are upgrading their sending platforms from open source MTAs and have invested in commercially-supported solutions for higher performance and ease of operation and configuration.

Sheer delivery speed is one big reason and access to more granular delivery controls is another. Originally, open source MTAs were never designed to be high-performance delivery workhorses. Rather, they were created to perform more traditional tasks such as email account management. ESPs and enterprises that still use this somewhat dated architecture usually need to build elaborate, proprietary, and complex server cluster farms to achieve tolerable performance in today's hyper-competitive delivery market.

To achieve capable scaling with an open source MTA an organization needs to build a highly complicated cluster of instances or nodes. Newer commercial solutions have been designed to scale "out of the box", such that a single server instance can reliably deliver millions of messages an hour if needed. These servers can be expanded linearly (load balanced) so that the ESP or enterprise can deliver several orders of magnitude more email in a short time frame.

Ease of configuration is a big differentiator between open source and commercial MTAs along with much more sophisticated bounce categorization. The amount of time and level of effort required to complete normal management tasks (for example spawning new instances as ESPs bring on new clients, or making sure new IP addresses are properly warmed, maintaining per stream delivery settings, etc.) quickly adds up when working with customized code.

The potential investment of man hours can be cost prohibitive and a major liability.

Ongoing maintenance and upgrades also are important considerations. With a highly customized sending infrastructure, open source MTA code must be continually tweaked by admins and engineers each time an update is required. This constraint makes it difficult to keep pace with changes happening within the dynamic email delivery ecosystem.

Open source software can sometimes foster a knowledge transfer challenge as well. This can be a very under-estimated issue for infrastructure maintenance. How many members of the company's technical group really understand how the delivery infrastructure operates? Is there just a handful of system admins who truly understand the current open-source set up? What if that person or persons left, through a layoff or by being poached by a competitor? Often times all the specialized aspects of the infrastructure have not been properly documented, and new employees cannot easily access and understand the information.

Because of these and other considerations, ESPs and enterprises continue to inquire about and ultimately adopt a commercial MTA platform. Here at Port25, the graphic below shows the platform our customers were using prior to adopting our PowerMTA gateway:

The considerations above are just some of the challenges facing senders today. Email has never been more important to online success, and ESPs and enterprises need to stay one step ahead of ISP requirements and new authentication policies such as SPF and DKIM and DMARC. Authentication is a critical issue to get right — for example, 94 percent of all email sent to Gmail uses two methods of authentication.

When deciding on the best email infrastructure for your enterprise. Make sure the email technology partner you choose has a track record of proven on-premises success and a cloud-based offering to conjugate hybrid delivery opportunities, which most on-premises providers have today. That's the way to stay successful through this period of email transition in the Email Infrastructure space.

Written by Fred Tabsharani, VP of Marketing at Port25

Internet pioneer, Ray Tomlinson has passed away. He died at his home yesterday morning from a suspected heart attack at the age of 74. While best known as the creator of the email messaging system, Tomlinson made tremendous contributions to the field of computing science, evolution of the Internet, and ultimately how the world communicates today.

* * *

Craig Partridge says: "He's best known for inventing the concept of sending email over a computer network and choosing the @ sign as the way to split the mailbox name from the host name. But that's a fraction of his amazing contributions to our field. Ray was one of a four person team that created TENEX, the first operating system to support virtual memory using paging. He wrote one of the first implementations of TCP and, when he found data being duplicated in the received stream, devised methods to ensure that sequence numbers were not duplicated that remain fundamental to TCP/IP implementations today. He worked on the first object-oriented distributed system and early multimedia email systems. And I'm sure I'm forgetting at least half a dozen other ways Ray made our world better."

* * *

Vint Cerf says:  "I knew and worked with Ray Tomlinson during the development of the ARPANET and its host protocols and benefited, as have billions, from his seminal work on networked electronic email. More important, from my personal perspective, was his work with Bill Plummer on the first PDP-10 TENEX implementation of TCP (and later TCP/IP). In 1975, he discovered that the TCP as specified in December 1974 had flaws that led it to fail to detect duplicate packets and, together with Yogen Dalal, developed the three-way handshake and initial sequence number selection method to solve this problem. As Craig Partridge summarizes, Ray was a long-time and creative contributor to the Internet, operating systems, and many other highly practical applications in the computer science and communications domains. He was a self-effacing and humble man and extraordinary performer in our online world. I will miss his thoughtful, low-key and always helpful counsel."

* * *

In 2012, Tomlinson was inducted into the Internet Hall of Fame by the Internet Society. His other awards and honors include: Receiving the George R. Stibitz Computer Pioneer Award from the American Computer Museum in 2000. In 2001, he was honored with a Webby Award from the International Academy of Digital Arts and Sciences and was inducted into the Rensselaer Alumni Hall of Fame. In 2002, Discover Magazine awarded him its Innovation Award. In 2004, he earned the Institute of Electrical and Electronics Engineers Internet Award. He was named the Prince of Asturias Award Laureate for Technical and Scientific Research in 2009. In 2011, he was honored with the Eduard Rhein Kulturpreis Cultural Award. He is ranked number four on the MIT list of top 150 innovators and ideas from MIT.

Sometimes, a software company is as much about people as it is about technology.

Who says PowerMTA admins don't have influence? Not only are they the influencers of our brand [Port25] they are also the main influencers and decision-makers when it comes to purchasing decisions. With the increased demand for PowerMTA evaluations and a shortfall of experienced PowerMTA administrators, enterprises and ESPs that deploy PowerMTA are finding it challenging to administer ever-increasing levels of unilateral (on premise, in-house) and bi-lateral (hybrid: both on premise and cloud) deployments.

This demand has begun to surface in unfilled positions as companies that deploy PowerMTA as a platform are noticing a severe shortage of experienced PowerMTA admins throughout the US and Europe. Some of the people stepping up to fill that demand are coming from the last place you would expect. You'll have to wait to the end to find out where.

At small ESPs, you might find the delivery administrator wearing many different hats, including trouble shooting customer facing non-technical delivery questions and also managing the technical aspects of the MTA such as analyzing log files. At larger enterprises and maturing ESPs, you find customer facing delivery teams separate from the technical delivery teams or pure MTA administrators.

Here is a quote from an experienced delivery admin at a large ESP:

"Our attempt to hire a senior PowerMTA admin was a complete failure. To quote my director, "there are none." I would make two statements. Those that know SMTP are very rare. The other comment is that the pecking order in tech is as follows:

• Product
• Sales
• Development
• Infrastructure

PowerMTA admins fall under infrastructure, at the bottom of the hierarchy, or at the top, depending on who you ask… :) Within infrastructure, MTA admins are unicorns. A senior router, senior DBA, or senior virtualization admin will always carry more weight in an IT organization than an MTA admin because those roles have value measured by the general IT industry. Yet, the MTA administrator holds an increasingly more responsible role among the "infrastructure subset."

* * *

Outside of an organization that sends email on behalf of others, MTA admins are a merely "nice to have," or "extras." In addition, outsourcing message streams to the cloud has become viable alternative for some enterprises.

* * *

Authorized PowerMTA consultants such at companies like Postmastery, founded by Maarten Oelering, are seeing a sharp increase in demand for consulting services both domestically and abroad. This is not necessarily something new, but demand has spiked over the past quarter. Through his encounters with PowerMTA admins, he posits: "the PowerMTA admin position is a "task" and not a "job". The people I know that do PowerMTA administration have a broader set of skills and duties, related to email deliverability, or related to system administration."

Deliverability administrators at some of the largest senders in the world (companies like ExactTarget, now a Salesforce company), have asked me to help them find experienced PowerMTA administrators for both remote and in-house opportunities. ExactTarget and Pardot, both deploy on the PowerMTA platform and both owned by SalesForce, send close to 1B emails per day. This number continues to grow, according to a source at ExactTarget.

Further, at the Messaging Anti-Abuse Working Group (M3AAWG), we're looking at facilitating a PowerMTA training session at an upcoming meeting, perhaps Philadelphia or Paris. The goal of this training session is two-fold: to introduce PowerMTA to new IT admins and to hone the skills of experienced PowerMTA admins, and prepare them to enter the workforce at larger enterprises. Students entering ongoing one-day workshops will be introduced to out of the box delivery settings and configurations that ISPs and the dev team at PowerMTA recommend. Students will also learn advanced bounce management logging analysis, along with how to integrate popular services like Splunk and Kibana from ElasticSearch for optimal data visuals. Other essential tools and integrations will also be shared.

That surprising source of new MTA admin talent? Hollywood. Actress Katie Holmes was recently interviewed by Email Service Provider Listrak to take on a PowerMTA admin position that would include managing privacy and compliance. Gwyneth Paltrow just accepted a PowerMTA position with ESP Pinpointe, where she will be working closely with Craig Stouffer. I also know through our client SailThru, a well-known ESP based in New York has hired a PowerMTA admin with some history working in Hollywood. Her name has not been released. Hard to believe , but Cindy Crawford is finally getting out of modeling: she recently was interviewed by the delivery team at MyEmma and hopes to come on board in short order as a PowerMTA admin working closely with Marc Powell and Art Quanstrom. Is it April yet?

Amid this shortage of PowerMTA administrators, development for both enterprise and standard editions PowerMTA has never been more robust. And, I'll release more wonderful news about PowerMTA in the very near future. If you are a PowerMTA consultant or a vendor who supports PowerMTA, I'd love to hear from you. Keep an eye out for that M3AAWG training certification course at M3AAWG.

Written by Fred Tabsharani, VP of Marketing at Port25

The Internet Infrastructure Coalition (i2Coalition) has joined the Messaging, Malware and Mobile Anti-Abuse Working Group (M³AAWG) to continue efforts on developing best practices for hosting and cloud service companies as well as sharing other information that will protect end-users. "To encourage an exchange between the anti-abuse experts in M3AAWG and the hosting companies in the i2Coalition, M3AAWG will co-host a formal i2Coalition member meeting at its M3AAWG 37th General Meeting in Philadelphia on June 13-16, 2016. The meeting will include both joint sessions with speakers on vital issues related to hosting abuse along with separate sessions focused on topics specific to each organization, according to Jerry Upton, M3AAWG executive director."

When V12 Group set out to build its Launchpad Marketing Platform, email marketing was a central component of the platform. Launchpad provides a lightweight marketing automation platform for existing customers for highly targeted and personalized campaigns across multiple channels. With more than 8,000 platform users, 85 percent of which are brand-name retailers, reaching out to 110M US households, V12 needed an MTA (Messaging Transfer Agent) that would execute high delivery rates, offer more control, and easily enable the latest authentication protocols.

The Challenge

Before PowerMTA™ was installed into their technology stack, the V12 Group had tried outsourcing their email marketing to various email service bureaus (ESBs) but turnaround times, lack of client-level customization, poor delivery rates, and slow delivery speeds shifted the company's focus to a reliable internal solution. Before they built Launchpad on the PowerMTA™ platform, V12 Group had used an out of the box email marketing platform. They had worked with the vendor to add some customization, but it still fell short of their needs and they had to fall back on their ESB to handle volume during peak seasons.

The Solution

"When we decided to build our Launchpad marketing technology, the email aspect of the platform was our priority. We researched various commercial and open-source MTAs on the market and selected PowerMTA™ for its lightweight code, ease of integration, flexible configuration, IP-based sending control and VirtualMTA technology" said V12 Group's CIO Ray Estevez.

V12 Group was able to granularly configure, integrate, and fine-tune PMTA for use within the Launchpad platform using PowerMTA™'s flexible APIs. Granular application of delivery policies and delivery rates through PowerMTA™ allow Launchpad to achieve an inbox placement rate of 90 percent. VirtualMTA gives Launchpad's PowerMTA™ server the capacity to segment delivery into multiple mail streams with unique IP addresses and different delivery policies for each IP, or VirtualMTA, for additional control.

PowerMTAv4.5 includes an IP rate limiting feature which allows V12 Group to control the number of delivery attempts within a specified time frame for each VirtualMTA, which further contributes delivery success on the Launchpad platform. With functionalities like Multiple DKIM Signing Support, PowerMTA™ supports Launchpad's successful delivery to other popular email providers, including Gmail, by routing mail to the inbox. V12 Group's architects and engineers continue to use the delivery metrics tools, including web-based status monitoring and real-time data access, to optimize Launchpad's delivery controls.

"Once we are hooked in, the automated delivery controls allow us to easily customize settings to meet rigorous sending volumes," said Estevez. "We can focus on innovation across the platform with the knowledge that our customers get responsive email delivery as part of their digital marketing plans." Estevez added that this helps them maximize ROI for their customers.

* * *

PowerMTA compliments your technology stack whether it's on premise or in the cloud. Increasingly, cloud based senders and enterprises are integrating PowerMTA with other front end applications for maximum delivery and granular controls. Learn More

Encryption is becoming increasingly necessary when transferring data across the internet, and email is no different. In PowerMTA 4.5 and later there are several methods to encrypt both inbound and outbound connections. Here we'll provide a quick overview of how they may be achieved. Keep in mind, this document only deals with encrypting the channel, not the content.

Outbound Opportunistic Encryption

To use outbound opportunistic encryption in PowerMTA, simply add the following to your configuration file:

<domain *>
    use-starttls yes
    require-starttls no
</domain>

With this, PowerMTA will check to see if the remote mail server supports encryption. If it does, an attempt will be made to create an encrypted channel over which to send mail. If the encryption fails, or if no encryption is offered, then the mail is sent using no encryption.

To verify if the mail was sent over an encrypted channel, it is necessary to add additional fields to the CSV accounting file. This can be done with the following configuration:

<acct-file logacct.csv>
    records d, b
    record-fields d *, dlvTlsProtocol, dlvTlsCipher
    record-fields b *, dlvTlsProtocol, dlvTlsCipher
</acct-file>

If encryption is used, the above configuration will record the protocol and cipher used to deliver the message over an encrypted channel.

Outbound Client Certificate

While the vast majority of outbound connections do not require a local certificate, there may be some B2B cases in which the remote mail server requires PowerMTA to use a given certificate for encrypting the channel between the two servers. This can be facilitated in PowerMTA with a setup similar to the following:

<domain super-secure-server.com>
    smtp-client-certificate /path/to/certificate.pem password
    use-starttls yes
    require-starttls yes
</domain>

In the above example, any messages sent to super-secure-server.com will sent over an encrypted channel using the certificate /path/to/certificate.pem (in most cases supplied by the administrator of the remote mail server). If the encryption fails, the messages will not be sent.

Inbound Encryption

Of course, outbound traffic is only half of the traffic on a PowerMTA server. It may be required to encrypt the traffic coming into a PowerMTA server as well. This can be done in PowerMTA on a per <source> basis. The setup would look similar to the following:

#
smtp-listener 1.2.3.4:465 tls=yes
smtp-server-tls-certificate /etc/pmta/smtp-cert.pem "YourPasswordHere" smtp-server-tls-ciphers "HIGH:MEDIUM:!ADH:@STRENGTH"

<source 0/0>    # matches all
    allow-starttls yes
    require-starttls-before-auth yes
    allow-unencrypted-plain-auth no
</source>
#

Creation of the certificate /etc/pmta/smtp-cert.pem follows standard OpenSSL practices, and if assistance is needed in getting the certificate created (please contact support@port25.com). An example of the contents of the certificate is as follows:

-----BEGIN CERTIFICATE-----
YOUR CERT HERE
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,EBA505536010547C

YOUR PRIVATE KEY HERE
-----END RSA PRIVATE KEY-----

With this configuration all traffic connecting to 1.2.3.4 on port 465 can attempt to use encryption for transmitting email into PowerMTA.

Inbound Certificate Chain Validation

PowerMTA 4.5 and later supports the ability to validate certificate chains.

Evaluate PowerMTA (Free Trial)

PowerMTA compliments your technology stack whether it's on premise or in the cloud. Increasingly, cloud based senders and enterprises are integrating PowerMTA with other front end applications for maximum delivery and granular controls. Learn More

The following is written by Juan Altmayer Pizzorno, the original author of PowerMTA. Pizzorno has been developing email server software for over 25 years and currently serves as Sr. VP of Research & Development at SparkPost. He co-founded and was CTO of Port25 Solutions.

* * *

With the recent Mandrill announcement, there's been a lot of coverage of SparkPost in the industry lately. While this has been a great time for the company as a whole, I want to give you an update on Port25, as things here are going very well.

When the acquisition of Port25 by Message Systems (now SparkPost) was announced, there was a great deal of fear for the future of our company — and more importantly — what it meant for the loyal users of our PowerMTA product. But as they say, "the reports of our death were greatly exaggerated". Now a year later, it seems like a good time to let you all in on how the integration went and to lay those fears to rest.

The initial transition was swift but went impressively smoothly. We moved to the SparkPost offices, met our new colleagues and found that the corporate culture wasn't all that different from our own. Even our LAN's IP addresses fit in nicely. Sure, our old offices were quieter, but along with the noise came additional email technology experts to collaborate with, not to mention the added support of company resources like IT and HR.

Despite these changes, the most important things remained consistent. I continue to lead the very same PowerMTA/PMC team, and we're even looking to hire an additional engineer to expand the team (Know any great engineers? We'd love to meet them). We continue to work in the same manner as before, setting our goals, writing code test-first, and doing our daily scrum meetings.

Work on PowerMTA and the PMC also continues normally. We released v4.5 / v1.5 last year followed by a few micro-releases since. The next update (spoiler alert!) should include MX-based queue roll-ups and SMTPUTF8 support. I'm excited to finally launch the MX-based roll-ups, as I remember thinking about this some 17 years ago, before Port25 was even founded. There are other cool features we're working on, but I don't want to get too much ahead of myself. We're also taking advantage of the new resources and team to train additional support engineers on PowerMTA, providing wider coverage to Port25 customers.

As PowerMTA's original author, I'd love for it to enjoy a long life, and I can say today that SparkPost feels like a good home for it.

The U.S. House of Representatives voted unanimously today to pass H.R. 699, the Email Privacy Act, closing a loophole that allowed law enforcement authorities to obtain old email and other digital communications without a warrant from the court. While a warrant was required to obtain information, Electronic Communications Privacy Act (ECPA) imposed a “180-day rule,” which permitted electronic communications to be seized without a warrant after 180 days. Supporters of the legislation say it is needed to update a decades-old law. Technology companies and privacy advocates say that statute was written before the rise of the Internet and so is outdated.

The latest discovery came while researchers at a security firm found a young Russian hacker bragging in an online forum that he had collected and was ready to give away a far larger number of stolen credentials that ended up totalling 1.17 billion records, Reuters reports. After eliminating duplicates the collection is reported to have contained nearly 57 million accounts of Russia's most popular email service, Mail.ru — a big chunk of the 64 million monthly active email users Mail.ru said it had at the end of last year. It also included tens of millions of credentials for the world's three big email providers, Gmail, Microsoft and Yahoo, plus hundreds of thousands of accounts at German and Chinese email providers.

"This information is potent. It is floating around in the underground and this person has shown he's willing to give the data away to people who are nice to him," said Alex Holden, founder and chief information security officer of Hold Security. "These credentials can be abused multiple times," he said.

Happy Early Memorial Day.

Once an ESP or marketing automation company declares itself for sale, there seems to be a mass exodus by investors, which sends up a red flag, (well in this case, a red & white striped flag). This past week there were rumblings about the potential suitors for Marketo. While it is rumored that German company SAP is the front-runner, there are many other potential suitors circling the marketing automation software company.

I will write another post in relative short order on other marketing automation companies that might be good acquisitions targets for tech giants looking to get into cloud-based automation. For this blog post, I will focus on Marketo.

We're no longer living in an era where cloud based SaaS valuations are fetching 7 to 9 times multiples. SaaS valuations have dropped 57% this year, and we're not even in June yet. While Marketo is a mature ESP, at an approximate run rate of 250M, there is some uncertainty in determining its real value to tech titans such as SAP, Oracle, Google, HPE, Microsoft, or Adobe.

Investors Shuffling

Potrero Capital Research purchased 233K additional shares in Marketo during the most recent quarter. The investment management firm now holds a total of almost 400K shares of Marketo. Its share of the company is valued at $10.9 million. Marketo makes up approximately 10.07% of Potrero Capital Research's portfolio.

Potrero Research might know something we don't, but let's take a look at this list of Investors who have opted out or sold out of their positions in the MRQ:

• Trexquant Investment LP (Sold out Position)
• Penserra Capital Management (Reduced Stake)
• Norgus Bank (Sold Out Position)
• Nueberger Berman Group (Sold Out Position)
• Pier Capital (Reduced Stake)

With SaaS valuations on the decline and investors in an ambiguous position regarding Marketo, the company will most certainly not fetch a valuation as high as those of marketing automation companies put up for sale in recent years. It has been a relatively slow M&A period this year in our space. If Marketo sells, the terms will be a beacon for other deals to follow.

If I were an ESP or marketing automation company, I would focus on widening the account base right now rather than being acquired. In the last quarter, there were a number of down rounds, which are often a precursor to lower valuations.

Analysts and Volumes

Marketo was upgraded by Bank of America/Merrill to "Neutral" on May 5, 2016. Craig Hallum endorsed the company as a "Buy" on Apr 4, 2016.

When a marketing automation company begins to scale its core business by bringing on new accounts after a rigorous compliance check, you know their messaging volumes are going to grow. Having insight into these messaging volumes and the widening of the account base are benchmarks of a healthy marketing automation company. Some companies have built messaging volumes as high as 1B messages per day, while others are at a remarkable at 1B per month, or 1B per year. While the winning recipe includes message volume, it's safe to assume, that the type of customer and size of customer are critical ingredients to a balanced account base. In our network, the average ESP or Marketing Automation company sends about 800M messages per month.

Of the 253 ESP/marketing automation companies in our network, 73.91% still remain private. So there are still a number of excellent choices for big investors who want to add a cloud-based ESP to their portfolio.

While SAP has purchased a few cloud-based companies in recent history, none are focused on cloud-based marketing-automation, which is why it's considered a front-runner for the Marketo deal. A few years back, Oracle paid market price for both Eloqua and Responsys. At this time, I don't think they will be bidding on Marketo, although a pitch could be forthcoming. Adobe spent a pretty penny for Neolane a couple of years ago and has actually built a formidable marketing cloud, so it has already filled the market segment that Marketo will bring to its buyer. Adobe may have an appetite for more however. NetSuite is another company that recently purchased a great ESP, Bronto Software. I don't think they are looking to expand with a Marketo purchase. By the way, $200M for Bronto was a steal.

Google might be thinking about a series of deals aimed at buying cloud software companies to boost its reach with mid-market business customers and enhance its overall cloud and infrastructure business. Marketo fits the bill, reaching both large and mid-market customers, but I don't think Marketo is in Google's sweet spot.

In my opinion, HPE will be the next tech giant itching to get into the game and buy a cloud-based marketing automation company. All of the companies I have mentioned have healthy balance sheets and can afford to buy Marketo in an all cash deal.

With valuations softening among cloud-based marketing automation companies across the the board, Marketo will most likely to fetch a 3 times revenue multiple. That will be close to a 800M.

This post was inspired by the hundreds of ESPs in our network and Tomasz Tunguz at Redpoint Ventures.

Written by Fred Tabsharani, VP of Marketing at Port25

This article was penned by Port25's reseller, Postmastery.com. They are a prominent reseller and authorized consultant of PowerMTA products and services. Feel free to reach out to them when needed.

Jobtome.com helps job seekers access millions of jobs gathered from hundreds of thousand's of recruitment agencies and employer sites across Europe. Jobtome.com helps companies reach millions of job seekers via pay-per-click based job advertising services.

The Challenge: Managing 30 Postfix Installations

Email is a key business driver within the Jobtome daily operation. The majority of customer interactions are facilitated via email. On a monthly basis Jobtome.com sends more than 300M emails (and growing). Their main challenges include but are not limited to:

• Managing 30 Postfix installations on virtual servers was quite labor intensive;
• The verification of deliverability through database queries was cumbersome and did not generate a comprehensive delivery performance overview;
• Jobtome.com processed bounces separately on all the Postfix instances. A script checked the mailbox to elaborate bounces;
• There were no Feedback loops in place.

The Solution: Replace 30 Postfix instances with 1 PowerMTA box...

Upon request, Postmastery conducted a requirement analysis into Jobtome.com email functionalities. The analysis showed that PowerMTA, was an obvious choice to manage volume. Postmastery installed all the required software and supported Jobtome.com in selecting the right on-premise email infrastructure.

After an 8 week IP warm-up process and new outbound ISP configurations in place, including an extensive knowledge transfer, Jobtome.com began sending the first transactional and marketing related emails via the new platform in November 2015. The total volume or all email streams have now been migrated to the new self-hosted email infrastructure. Postmastery is now managing, monitoring and optimizing email delivery measures for Jobtome.com.

The Result: 2.5 million emails per hour

The results of the new self-hosted email solution are clear:

• Sent 2.5 million emails in peak hour on one PowerMTA instance;
• Average delivery time is 7 minutes. 90% emails are delivered instantly (1<minute);
• More than 30 Postfix instances replaced by 1 PowerMTA;
• Complex bounce processing which involved 12 Postfix instances replaced by a intelligent built-in bounce processor in same PowerMTA instance;
• Fully automated and built-in Feedback loop processor in PowerMTA;
• Delivery analytics through complex MySQLqueries is replaced with Postmastery's Delivery Analytics platform which runs at Google scale and offer a tailored online dashboard and email delivery alerts. Now there is more time for the analysis of the data and metrics at Jobtome.com

Evaluate PowerMTA (Free Trial)

PowerMTA compliments your technology stack whether it's on premise or in the cloud. Increasingly, cloud based senders and enterprises are integrating PowerMTA with other front end applications for maximum delivery and granular controls. Learn More

Data solutions provider Return Path has released a new report highlighting 20 visionary ideas for brands to "futureproof" their email program. Among various insights, the report warns brands that adoption of IPv6 will result in rising dependency on domain-based reputation. From the report: The adoption of IPv6 will change the face of email filtering. With the quantity of internet enabled devices in use today, we are quickly running out of IP addresses. The advent of longer IPv6 address will allow for exponential expansion in available IP addresses. However, this wealth of IP addresses is an opportunity that spammers can — and will — exploit, leading mailbox providers to employ ever more sophisticated filtering techniques. Domain-based reputation will become increasingly important in filtering decisions, so marketers will need to maintain a pristine reputation to ensure consistent email delivery.

Between September of 2015 and May 2016, (last 8 months) Port25 saw almost a 30 percent jump in new cloud-based email infrastructure interest outside the United States as indicated in the chart below. While most of the influential senders are not abandoning on-premises mail transfer agent (MTA) solutions, many are looking to cloud infrastructure for managing higher-volumes by bifurcating individual email streams to the cloud. The cloud for email infrastructure combines the stability and feature-rich environment of hosted MTAs with the flexibility and scalability of cloud-based email/transactional streams or marketing solutions.

Port25 has seen a near 30% rise in new cloud email infrastructure interest outside U.S. in the past eight months.
(Click to Enlarge)

The Hybrid Cloud

A hybrid of on-premises and cloud-based messaging infrastructure gives ESPs and Enterprises, the ability to quickly and cost-effectively scale operations instantly. Why invest IT time and resources when you can have two solutions that work genuinely and seamlessly together?

Some email platforms may use the cloud like a peaker power plant: when forward-looking demand is high, they partition some of the volume that can't be handled by their hosted MTA and migrate to the cloud; when demand is low, the cloud requires little overhead and maintenance.

Security and Redundancy

Service interruptions can spell disaster for high-volume messaging. When ESPs or enterprises add a hybrid cloud to their hosted MTA solution, they bring in not only agility but security. With two very different systems on board, one can be considered as a failover if the other is down. The cloud helps provide continuity of service. Continuity is the term frequently used by Email Service Providers and stakeholders of demanding senders.

One important challenge when creating a hybrid cloud is to make sure the data from both sources is standardized. You don't want the hours of labor the cloud saves you in upfront configuration time to be consumed on the back end trying to reconcile apples and oranges in your data and analytics. The good news is that many cloud-based email marketing solutions can be configured so that their data is normalized to the data you get from your on-premises MTA. Further, in regards to data, some or most cloud based infrastructure provides "even" more granular analytics.

Size Matters

While even some of the largest global ESPs are turning to cloud-based solutions, a recent chart of interest in cloud email in the United States shows that smaller companies have an even higher level of interest.

In fact, the largest chunk of cloud-based solutions users was among companies with hourly message volumes of less than 10,000. For Startups, and smaller ESPs and Enterprises, the cloud has a number of advantages. It allows them to keep their costs down by outsourcing development and provides affordable scalability during peak sending times and during tight-budget times when sales expansion outpaces revenue in a growing enterprise.

Among the younger generation of programmers, and for the most part millennials, "there is" little resistance to adding sending capacity in the cloud. After all, the cloud is their native environment. If you want to look into the future of email delivery, look to the cloud.

Nimble Environment for Software Development

Cloud based software for email infrastructure has as much agility in regards to customization, as hosted MTAs. One way the hybrid cloud does this is to offer ESPs the benefit of the latest features in real time — no waiting for the next release.

In a recent interview on the SparkPost blog, SparkPost co-founder George Schlossnagle described the ability of the cloud to facilitate rapid turnaround on new features:

"The biggest ... difference between architecting for the cloud [versus on-premises software] is that it flips many of the traditional challenges of release software on its head. In an on-premises world, you have to be extremely conservative about quality control, because when you release a version into the wild it becomes its own entity and you cannot force your customers to upgrade. When you control the entire deployment cycle yourself, you can iterate much faster because you can instantly (and globally) roll back from any issues. This allows for a feature velocity that is tremendously larger than on-premises software."

Aim High in the Hybrid Cloud

Getting the most from a hybrid cloud that leverages the strengths of both on-premises MTA infrastructure and resources that live in the cloud is a matter of design. Plot out the structure and flow of email traffic from your MTA to the cloud. A bit of forethought goes a long way to allowing teams to design an integration that makes the best use of the hybrid cloud to boost capacity and move data seamlessly from one platform to the other.

Written by Fred Tabsharani, VP of Marketing at Port25

Port25, A Message Systems Company, has just released its latest version of PowerMTA v4.5r5 and PowerMTA Management Console v1.5r5. Highlighted below are the major features of this particular release.

SMTPUTF8 Support

Support for SMTPUTF8 is a specification whether one can submit internationalized email addresses per RFC6531, RFC6532, and RFC6533 to PowerMTA from the connecting IP address. When enabled or set to yes (or true), PowerMTA will list "SMTPUTF8" in the list of extended SMTP commands supported for the connecting IP, allowing the submitter to use internationalized email addresses in the SMTP envelope. Note that if the remote gateway for the domain does "not" advertize support for SMTPUTF8, PowerMTA will subsequently bounce the message(s) for the recipient out of the queue. If desired, SMTPUTF8 support can be disabled with the new per-<source> allow-smtputf8 directive.

UTF-8 is the dominant character encoding specification for the internet accounting for 87.1% of all Web pages as of June 2016. The Internet Mail Consortium (IMC) recommends that all email programs be able to display and create mail using UTF-8.

MX RollUp

MX Rollup List Allows one to define "rollup" queues based on the MX records of the recipient domain, in order to consolidate separate but related recipient domains into one queue. Messages moved into the roll up queue are handled as if they were one recipient domain with regards to rate limiting, connection caps, and other directives.

For example, since 'msn.com', 'live.com' and 'outlook.com' are all handled by the same exact MXs or Gateway, it makes sense to roll these up into a single queue (outlook.rollup for example) vs. being handled separately by PowerMTA. This feature works very well for the large mailbox providers that provide corporate hosting, for filtering/antispam cloud providers, or for large hosting providers in general that manage corporate email for tens or hundreds of thousands of various domains. To configure this feature, you need to define the MX record that maps to each rollup queue name along with the name of the rollup queue, which must end in ".rollup." More than one MX can be mapped to the same rollup queue.

Additional Features include but not limited to:

• Added support for internationalized domains to "pmta resolve"
• Increased spool-max-recipients limit to ~16.8M and total-max-smtp-out to 10,000
• Added ability to show per-recipient schedule in "pmta list"
• Added support for pattern list header matching on Encoded-Words that include a language declaration, as specified by RFC2231

PowerMTA compliments your technology stack whether it's on premise or in the cloud. Increasingly, cloud based senders and enterprises are integrating PowerMTA with other front end applications for maximum delivery and granular controls. Learn More