Pictures from Life as a Sales Engineer

There’s not many memes that I jump on the bandwagon for, but I’ve seen enough people having fun with this that I have to join in.

When my demo hits a snag…

When my Sales Exec calls to say the deal is closed…

When my Sales Exec says he wants to move forward after I tell him there’s red flags all over an opportunity…

When the SE Manager is looking for volunteers to work on an RFP…

 

What the Sales Exec expects me to do when he forgets to invite me to a meeting until the last minute…

My expression when the Sales Exec claims our product has a non-existent feature…

When the guy at the prospect (whose app has been called junk by everyone else) tells me things are fine, they don’t need my solution…

When the client asks me to click on an un-configured section of the demo…

When the client doesn’t ask about the un-configured section of the demo…

When the presentation goes off perfectly…

When I spend two days building a demo, only to find out the prospect wasn’t qualified after all…

What I want to do to the person who didn’t qualify the prospect…

When the Proof of Concept comes together perfectly…

When the customer asks me if it’s true that <insert wild claim made by Sales Exec>…

And now a small plug: I’m not the SE anymore, I’m the Manager, and at Message Systems I’m hiring multiple Senior SE’s right now (we call them Solution Consultants) in multiple regions! Head on over to our jobs page and check it out! I poked a little fun at the Sales Exec stereotype but we’ve got a great group to work with, a solid product and a great team. Join us, won’t you?

Disclosure: Borrowed and modified extensively from http://martinvalasek.com/blog/pictures-from-a-developers-life

See You At The Message Systems User Conference!

I’m looking forward to the upcoming Message Systems User Conference next month in San Francisco, not only for what looks like an excellent venue, but for the great set of quality sessions on the agenda.

There’s a number of sessions I’m looking forward to attending, but I’d like to invite you to attend the sessions I’ll be delivering next month (read to the end to save on conference admission):

What the Convergence of Data Security & Privacy Concerns Will Mean to Companies

The barrage of news stories about data breaches and privacy violations is taking a toll on consumer confidence.

What You’ll Learn:

  • Why data security and privacy issues are converging and how an erosion of consumer confidence can jeopardize data availability for communication and commerce.
  • How security and privacy are connected to Message Convergence and why they should now be of concern to all ecosystem players and at all levels, Marketing as well as IT.
  • What principles companies should embrace to address security and privacy in their own environments.
  • How companies can safeguard their customer data and messaging streams.

New Directions in Email Deliverability

Our panel of industry experts will explore the ongoing evolution of deliverability management and new technology advances, such as adaptive delivery, that will make it easier.

What You’ll Learn:

  • How deliverability is a tactic companion to Message Convergence – getting messages delivered, read and acted on.
  • How new advances in technology can improve deliverability management effectiveness and remove the hassles for all stakeholders.

Building Multi-Channel Apps

This session will introduce participants to the whys and wherefores of multi-channel messaging applications ­ how they deliver business value, and how to construct them. You¹ll gain both an understanding of the business strategy behind multi-channel apps, and a nuts-and-bolts working knowledge of the tools and techniques required to design, build and deploy them. Topics will include how to access multiple data sources on the fly and how to make routing determinations. For instance, once you¹ve made a judgment on content, context and preference, how to go about actually getting a message routed to its ultimate destination. We’ll go in depth on the subject of multi-channel message type (MCMT), a proprietary content container format that makes it possible to inject messages into the delivery stream with content alternatives dependent on the preferred message channel.

Target Audience:

Product and program managers, developers, line of business owners.

What you’ll learn:

  • How multi-channel messaging delivers business value across any number of industry verticals.
  • The messaging and data systems/architectures needed to deploy multi-channel messaging.
  • Introduction to MCMT.
  • How to configure Momentum, Mobile Momentum and Message Central for multi-channel apps.
  • Understanding and acting on customer preference data.

Advanced Momentum & Message Scope

This session will extend the sessions on “Introduction to Lua” and “Momentum Essentials and Message Scope” by taking participants through advanced, Lua-based message parsing APIs. Advanced policy scripts for database-driven binding assignment and DKIM signing will be demonstrated. Participants will see practical, but advanced remediation list usage with Message Scope and learn how to create custom remediation actions.

Target Audience: System administrators, operations and support personnel and developers.

What You’ll Learn:

  • Various parsing techniques using Lua API functionality.
  • Write Lua policy scripts that implement database-driven binding assignment and DKIM signing.
  • How to integrate Momentum bounce information with an external database.
  • How to integrate Message Scope with 3rd-party data feeds.
  • How to create custom remediation actions with Message Scope.

It’s going to be a great conference and I look forward to meeting everyone, to make it even more appealing, register now and use discount code VIP2S2 to save $250!

See you there!

14 Email Security Do’s & Don’ts

Note: This article originally appeared at http://www.messagesystems.com/wordpress/?p=84

Introduction

Anyone who follows the email marketing industry news is no doubt aware of the increasing number of well-publicized data breaches that have been occurring at the various major ESPs. In addition to the major ESPs, there are no doubt a number of less-publicized or even non-publicized data breaches occurring all the time at both smaller ESPs and in-house enterprise senders. The days when most of us in the email industry could watch from the sidelines and shake our heads have surely passed. Henceforth we should all operate on the assumption that we’re either now under attack as well, or will be shortly.

Email marketers have two valuable resources that malicious parties want to capture and exploit: information and infrastructure. Attackers want to access the information you hold, including email addresses, personally identifiable information (PII) and affiliation information (which organizations send to which recipients). Using this information the attackers can send spam or phishing messages and (in an unlikely worst-case scenario) even perform identity theft.

In addition to getting to the information you hold, attackers will also try to gain access to your infrastructure. In a recently reported breach at CheetahMail (http://blog.wordtothewise.com/2011/04/another-security-problem/) it was reported that an attacker had gained control of a customer account to send malware (UPDATE: The same thing just ocurred at Bronto: http://blog.bronto.com/2011/05/02/shared-security-responsibility-and-a-compromised-password-incident/). While many reports focus on attacks that result in data leaks, it’s also very common for attackers to access infrastructure to send their own messages from trusted systems, ruining reputation for the operator of the compromised infrastructure.

It’s time for all email marketers, whether sending themselves or through service providers, to make security a fundamental principle in their operations. The Online Trust Alliance (http://otalliance.org) recently published a set of guidelines (https://otalliance.org/resources/securitybydesign.html) that I highly recommend reviewing and following. I’d like to make a few additional recommendations of my own.

People

All the security technologies in the world can often be defeated by a simple phone call or a few dollars. There are multiple cases where attackers have been able to get into a system through social engineering: calling up someone in the target company and presenting themselves as a trusted co-worker and asking for the unsuspecting employee’s login credentials. In other cases a simple offer of cash in exchange for information or access can bypass any number of security measures.

Whether they are acting innocently or maliciously, your own employees (and customers) can easily be your downfall. There are a number of security measures that can help alleviate this:

  1. Educate your employees and users. Make sure they understand what social engineering attacks are and how to identify and prevent them. Teach them to never disclose their usernames and passwords, and enforce a policy of never asking customers for their credentials and make it clear to your customers that you will never do so.
  2. Do your homework. Employ best practices in your HR department. That includes performing background checks on your employees (at least the ones with access to sensitive customer information), including credit checks. Keep in mind that people in positions with access to sensitive data could be susceptible to enticement – this is particularly true if you’ve made it easy for them to act on that temptation.
  3. Apply the ‘need to know’ rule. Consider who really needs to be able to see customer information, and how much needs to be visible. Does someone who manages message templates really need access to your recipient list? Does someone who manages segmentation really need to be able to see both the user and domain portion of an email address? Perhaps they can do their job with access to the domain information only. Do customer service reps really need to be able to see lists of recipients or do they just need to be able to look up a specific recipient to do their job? There will always be people who need to access sensitive information, but not as many as you might initially think, and few need access to absolutely all the information rather than just a subset of it.

Data Storage

There are a number of best practices around securing the data you store, but I want to share a few ideas about what to store, to be used in combination with data security best practices.

  1. Store as little as possible. An attacker cannot steal information that you don’t possess. Do not ask for information you do not need or can’t use. Marketers tend to err on the side of over-collection because it ‘might’ come in handy. (Example: are you asking for a physical address when you do not send anything by regular mail?)
  2. Use encryption where possible. Consider a suppression list to prevent sending to people who have unsubscribed (hopefully you followed step one and purged everything but their address when they unsubscribed); you need to have their address in order to prevent sending to it, but you can store their address as a one-way hash and compare a one-way hash of recipient addresses to identify if a recipient should be suppressed. I’ve worked with senders who encrypt the user portion of every recipient address (mike@messagesystems.com would be stored as 18126e7bd3f84b3f3e4df094def5b7de@messagesystems.com as an example) in the database, with a custom Lua script in the messaging server decrypting the user portion of the address on the fly just before sending. With this approach, they can still do domain reporting and segmentation, while making it much more difficult for attackers to extract useful information.
  3. Purge data as soon as possible. Again, you cannot lose what you do not have. Purge information as soon as feasible, both customer data and the various logs that can contain customer information. If you need a piece of information for a specific mailing, purge the data once the mailing is complete.

Email Infrastructure

While I have no reports to date of email infrastructure as an attack vector there are still some steps you can take to better secure your email infrastructure.

  1. Secure the server. Implement security at the operating system level as well as at the network level. Restrict access to the web UI to internal machines only (use a VPN for external access). Strongly consider using two-factor authentication including password-protected SSH key-based authentication.
  2. Secure your logs. Remember that your logs will often contain address information, so you need to secure your logs with the same vigilance that you secure your database. Ensure that your file system permissions are properly set and that you retain your logs for no longer than necessary.
  3. Customize your logs. If your system supports customizable logging, consider trimming your logs down to the bare minimum data required for your purposes. Instead of storing the recipient email address, store a customer identifier that you can use to lookup the customer address (high-end solutions will let you store just the domain portion of the address so you can still do reporting on domain volumes and deliverability).
  4. Secure against being an open relay. Grant permission to inject mail on a per-IP basis if possible, use TLS and authentication if you need to allow relaying to external hosts.
  5. Scan your outbound mail streams. An effective way to mitigate infrastructure attacks is to filter all traffic as it leaves the server to prevent sending mail that contains viruses, spam or malware. The incident at CheetahMail I mentioned at the start of this entry could have been prevented with outbound traffic filtering. Keep in mind I’m speaking about AV/AS filtering on a per-message basis. It’s not enough to send a test message to a preview tool if you’re trying to protect your infrastructure; you need a messaging server that can filter traffic on egress.
  6. Implement Feedback Loops. While this may not seem like a security tool, I’ve worked with senders who were able to use a spike in incoming FBL messages to identify an unusual sending pattern coming from their servers, leading them in turn to identify that their network had been compromised and a malicious attacker was using their system to send mail.
  7. Implement authentication tools such as DK/DKIM/SPF/SenderID. Again, this does not directly secure your data, but if a list is compromised it will be harder for a malicious party to deliver mail from their own servers and make it appear to come from you (especially when making phishing attempts with your data).
  8. Monitor Block Activity. As with spam complaints, a sudden burst in rolling blocks could be a red flag that an infrastructure beach has occurred. Set-up alerting system for blocks and automated suspension processes to catch and shut down malicious mail streams before serious damage is done. The good news, if you’re running Momentum, is that our Adaptive Delivery product does this for you automatically.

Conclusion

The latest security breaches in the email marketing industry have re-enforced that an attack is a matter of when, not if, and senders need to plan accordingly. The recommendations of the OTA, combined with the recommendations above (and constant vigilance) should provide a good start at avoiding (and minimizing the impact of) a malicious attack.

Message Queuing & Segregation: Lessons from the Airline Industry

Note: This also appears at http://www.messagesystems.com/wordpress/?p=38.

Many email marketers are unaware of the importance of message queuing to the successful delivery of their email. As a component of their messaging infrastructure, queuing is something that marketers typically defer to their IT department to manage. Yet, the reality is that queuing and the segregation of message streams can make the critical difference between the success and failure of a company’s messaging programs, and therefore, should be of concern to both the IT and marketing departments.

Effective queuing really comes down to the choice of messaging infrastructure. When using a technologically advanced messaging platform, companies can efficiently manage parallel queues with messages assigned into multiple streams to ensure that each stream flows at an appropriate rate, providing efficient delivery of all classes of traffic. Unfortunately, those that rely legacy MTAs have no such options. They’re left trying to manage the bottlenecks and slowdowns that result from poor architecture with complicated priority schemes within a single queue.

Recently, one legacy MTA provider suggested that their routine for queue prioritization was the answer for reaching high-value customers first. While the business need is certainly legitimate, trying to prioritize messages within a single queue is both outmoded and a solution to a problem that should not exist in the first place. There are better ways to satisfy this need that are both simpler and more powerful at the same time. To illustrate my point, allow me to provide an analogy that should be familiar to my fellow business travelers.

One of the most common headaches for the air traveler is the security checkpoint; you get your ID checked, get in line, get your ID checked again, get in another line, empty your bags, take off your shoes and belt, get in yet another line and then get radiated in the name of public safety. During the highest traffic times these lines can become so long that people start missing their flights because there are a very limited number of security checkpoints and the airports were architected in a time that predated the need for such extensive security. This fundamental flaw in the architecture of the airports means that the current needs of travelers for additional parallel security screening checkpoints cannot be met, and everyone has to wait in a queue to get to their plane, sometimes with unacceptable results, leading to additional costs for all involved and potential lost business.

This is handled in a variety of ways, including performing the security check at every gate area (creating a very parallel security screening system) and by using priority security lines. Imagine for a moment that instead of this solution, the airport chose instead to assign priority on an individual basis to every single passenger and then tried to sort the individual travelers in the security line. As you can imagine such a solution would require additional work to make the individual assignments and then keep track of who ranks where in the line, with a risk that low-priority passengers would find themselves significantly delayed as they were repeatedly bumped. In all my travels I have never seen such an approach, primarily because the airports already have an approach that works.

Find a particularly efficient airport and what you’ll see is a fairly consistent set of practices:

  • Separation of passengers into queues based on their fitting into a certain profile.
  • A large number of parallel checkpoints.
  • Efficient handling of passengers.
  • Intelligent queue management that can modify queuing on the fly to meet circumstances.

Look at a particularly efficient airport and you will see multiple queues, including queues for:

  • Frequent / First Class travelers – The most frequent travelers and those who sit in First Class. These people bring a lot of value to the airlines and receive a lot of value in return.
  • Expert travelers – A new lane starting to appear in some airports, for those who are experienced in getting through security and unlikely to cause delays.
  • Family / Special Assistance – A slow lane, these groups will take longer to get through security.
  • Casual Travelers – A lane for those who move at an average speed through security.
  • Staff / Crew – While in some airports workers and air crew jump to the front of the line, the most efficient airports avoid this disruption by maintaining a separate checkpoint for those who work at the airport, minimizing disruption and ensuring that staff can get to work on time.
  • Specialty – From time to time I’ve seen the airport create a special temporary queue for unique groups such as chartered planes by opening a checkpoint and redirecting the group to the specialty group.

Not only has the separation of travelers into queues according to their profiles (including their priority as a group) proven sufficient to make prioritization by individual traveler unnecessary, it is much easier to manage.

While separating passengers into a number of queues can certainly benefit airports, the most efficient airports are also architected to operate a large number of parallel checkpoints, preventing a situation where every passenger in the airport needs to be funneled through the same metal detector. Imagine an airport trying to service millions of passengers a year on only one or two metal detectors and a single x-ray machine.

In addition to having many checkpoints, the best airports will also have efficient checkpoints, maximizing the flow of passengers through any given checkpoint through better design of the checkpoints and better training of the staff, all without compromising safety.

Perhaps most importantly to the smooth operation of an airport is intelligent management. I’ve seen airports where there were several queues open but empty because the people managing things weren’t flexible enough to reassign lines and adjust the queues to ensure well balanced passenger flow. The best airports will change the designation of queues, move staff around and even redirect passengers to alternate checkpoints that are less busy, all in the interests of moving the highest number of passengers per hour.

Senders can follow these same principles to get maximum throughput and deliverability in their own environment:

  • Segment mail by profile.
  • Choose a sending solution that supports highly parallel sending.
  • Choose a sending solution that provides sufficient throughput.
  • Choose a sending solution that is intelligent.

When sending, remember that segmentation is not just for who to send to or what to send them, but for deciding how to send a message and with what priority. You will want to create queues for high priority messages to satisfy your most valuable customers, queues for high-reputation traffic that delivers without issues as well as for traffic that you expect to deliver slowly (one example is traffic that results in human interactions, you may need to slow this to prevent overloading your call centers), test and administrative traffic that needs to go out as soon as possible and transactional traffic that should not queue up behind bulk sends. This is a common practice among ESPs, who often add specialized segmenting for scenarios such as new customers and customers with specific SLAs.

As with the airports, you need to architect your environment to be able to handle more traffic in parallel. This can be accomplished by adding more injectors and more messaging infrastructure, or by adding better infrastructure. Look at your existing solution: how many IPs can it send from? How many messages per hour can you send on a single machine and how many concurrent connections can it handle? Most Open Source solutions can handle one IP address, send 100,000 messages per hour at most, and can open less than one hundred connections. Low-end commercial solutions can often do over a hundred IPs, send close to a million messages per hour and can handle a few hundred to a couple of thousand connections. On the high end you have carrier-grade systems designed for the enterprise such as Momentum by Message Systems, which can utilize thousands of IPs to send millions of messages per hour across tens of thousands of concurrent connections (while you will never open more than a few connections to a given ISP on a given IP address, lesser solutions will fall short when sending across hundreds of IPs to thousands of ISPs, defaulting to ISP prioritization as a workaround).

Finally consider the intelligence of your infrastructure:

  • Can your infrastructure send across all servers simultaneously and fail-over in the event of an outage?
  • Can your infrastructure adjust throttles on the fly based on responses from the ISPs and bounce and feedback loop data?
  • Does your infrastructure handle queues so efficiently that performance is the same with thousands of messages in the queues as it is with millions of messages in the queues?
  • Can your infrastructure dynamically change from email to other protocols such as SMS and MMS based on subscriber preferences and ISP responses?

If not, we should talk.

Technical Considerations For IP Warmup

Introduction

In response to the recent news regarding Goodmail closing its doors, Tom Sather at Return Path published a blog entry regarding IP warmup and the difference it can make for inbox placement.

Tom sums up the need for IP warmup well:

If you had talked to any email marketer 10 years ago and asked them how they dealt with blocks on their IP addresses, the answer would probably be the same: “We just switched IPs.” Not only was this an unfortunate, albeit effective, way to deal with blocks, it also became a common method used by spammers. They would simply send from one IP address for a very short time and then move on to another, either with IPs they owned or through hijacked computers controlled by botnets. Because of spammers’ behaviors, ISPs and email providers respond by temporarily blocking and limiting the amount of email a new IP address could send. ISPs now treat any new sending IP address like a dog on a short leash, and only extend the leash when the senders’ reputation is proven.

I personally have seen what can happen when senders try to send too much, too soon, with senders trying to send millions of messages on their first day using new IP addresses and finding themselves blacklisted in short order. For a reputable sender the key is to start sending slowly and gradually increase volume on new IP addresses until a proper sending reputation has been established.

A Clarification

Before I get into some technical advice I’d like to clarify one thing from the Return Path article. Regarding the shutdown of Goodmail Tom has this to say:

There are a couple of reasons you still might have to send from a new IP address, such as moving to a new ESP, moving to a new data provider, or moving off of Goodmail. Goodmail had a unique way of tokenizing their customers’ mail by relaying mail through their own IP addresses, and consequently their reputation. Therefore, once you stopped using Goodmail, your traffic now goes through your IPs, which hasn’t had any traffic in awhile, which means you’ll need to work on building up your sending reputation again.

This statement applies to any customer’s of Goodmail’s hosted imprinting service but does not apply to in-house senders using products such as Momentum by Message Systems that had a built-in Goodmail Imprinter. For such users the shutting down of Goodmail involved shutting off the Goodmail Imprinter component of their infrastructure but IP warmup will not be required since those users were already sending using their own IP addresses.

Tom’s Advice

Assuming you didn’t get a chance to read the link, here’s the five points of advice provided by the article:

  1. Sign up for all feedback loops. Suppress from future mailings.
  2. Authenticate. Use SPF, SenderID and DKIM.
  3. Segment and mail your active subscribers. Put your best foot forward.
  4. Monitor. Use seedlists such as Mailbox Monitor and watch your IP’s Sender Score.
  5. Get Certified. Get your new IP Sender Score Certified.

Some of these warrant additional discussion from a technical point of view.

Feedback Loops

In order to be effective, Feedback Loop message handling needs to be automatic. Message Systems customers should already be aware that we have provided built-in Feedback Loop processing as of our 3.0 release in 2008. In addition to automatically unsubscribing recipients that trigger a Feedback Loop message, you should also take the volume of feedback loop hits as a metric to show the effectiveness of your mailings. Feedback Loop hits should also be used as a factor when determining traffic shaping rules, especially when an IP address is new. If you see a lot of FBL hits, you should throttling back on the sending IP address.

Monitoring

With regards to monitoring, seedlist monitoring is a good indicator of how ISPs are treating your mail, but they provide only part of the overall picture. To get a complete view of your deliverability you need to also monitor what happens before the ISP accepts a given message, taking into account what temporary (aka transient or 4xx) failures and permanent (aka 5xx) failures that are occurring as you try to send. When monitoring permanent failures, keep in mind that permanent failures can occur both during delivery (synchronous or in-band) and post-delivery (asynchronous or out-of-band) through the ISP sending back a DSN (delivery status notification) message to the return path (aka envelope sender or envelope from) address of the original message. You should be tracking and trending all failures, especially when sending on new IP addresses.

Additional Technical Considerations

Keep in mind that just like in life, you are judged not just by what you say, but by how you say it (and whom you say it to). With regards to deliverability this comes down to content and sending practices. From a technical standpoint we focus less on content (what you say), but it does have a significant impact on IP warmup. You should avoid sending riskier content on new IP addresses both on overall content and wording (I’ve seen deliverability dip just for using the word “sexy” in a mailing, even when the overall message was not sexual in nature).

Sending Throttles

Before you ever start sending from a new IP it is vital that you pre-configure your sending software to comply with as many published ISP recommendations as possible. A convenient resource is this page provided by Word to the Wise: ISP Summary Information. Pay particular attention to the Connection Limits and Sending Limits columns.

Sending Volume

When warming up IP addresses it is important to start slowly; ISPs do not trust new IPs and will not respond well to new IPs coming online and immediately bursting out large amounts of traffic. While there are no published limits online one of the recommendations I have heard is to avoid sending more than 10,000 messages per day to the major ISPs (Yahoo!, Gmail, Hotmail, AOL, etc.) when first sending, and I’d say it would be best to send less than 1,000 messages per day to any smaller ISPs. By reviewing your temporary and permanent failure messages you will be able to get a feel on whether your reputation is sufficient to increase volume, and after increasing volume you should pay particularly close attention to your failure metrics to make sure that the change has not had an adverse effect on deliverability. I generally recommend not increasing volume by more than 2x at a time and not more than once every day or so. Don’t hesitate to revert to a lower volume if you start seeing an increase in temporary and permanent failures.

Suppress Bounces

When sending, make sure to quickly and automatically suppress any recipients that the ISPs identify as being invalid. When first sending you should assume that you are being watched closely, and one aspect of that is your practices regarding bounce processing. If you repeatedly send to someone that an ISP identifies as invalid through a bounce message you will be penalized for it by the ISP, and that punishment can potentially come faster when an IP address is new due to the lower starting reputation.

Watch Out For Deferrals

There is a specific class of temporary and permanent failure responses that you need to keep a particular eye out for, the deferral messages. A deferral message from an ISP indicates that you need to quickly and decisively change your sending practices as they are the warning messages you receive from the ISPs prior to being blacklisted. You can get examples of deferral messages from Yahoo here and many ISPs will list examples of their deferral messages on their postmaster page. As an example, here is a hotmail deferral message:

421 4.16.55 [TS01] Messages from x.x.x.x temporarily deferred due to excessive user complaints

When you see such messages, you need to review your content and throttles and pause sending for a couple of hours to allow things to cool off while you determine what changes you need to make.

Automating IP Warmup

In his article Tom Sather advised:

If this looks like a lot of work, then you’re right. To be successful, you need to plan appropriately, be patient, send smarter, and constantly monitor.

Tom is absolutely correct, warming up new IP addresses requires research, preparation and diligence.

The good news for Message Systems customers is that we’ve taken care of this for you with our Adaptive Delivery module. Adaptive Delivery will automatically identify new IP addresses, set initial throttles and gradually increase volume as the IPs age, monitoring ISP responses to ensure that the ISPs are responding positively. If at any point the Adaptive Delivery module identifies a negative ISP response, it adjusts throttles in realtime and monitors for additional negative responses. If an ISP replies with a deferral response, Adaptive Delivery will suspend delivery, throttle back and send you an alert so that you can check the content being sent. All of this is built using intelligence that is constant reviewed and improved by a full-time, in-house deliverability specialist. In addition, our bounce processing system now supports live updates, allowing us to improve classifications thanks to automated feedback from customer systems. If you’re not taking advantage of these new capabilities contact Message Systems and we’ll help.

We’re Hiring Yet Again

My employer Message Systems is constantly growing and I’d like to share our latest career opportunities. I do want to call out an opening on my team specifically for a new Sales Engineer:

Message Systems, the market leader in Advanced Message Management Solutions, is looking for an energetic Sales Engineer to support our sales in the Financial and Healthcare verticals.

This is a full-time position.

Key Responsibilities

  • Provide exemplary pre-sales technical expertise through technical and product presentations, product demonstrations, pilot implementations, beta program administration, consistent communication, and on-going technical consultation.
  • Install and configure trial and demonstration systems and train customers on their use.
  • Translate complex technical problems for non-technical clients as well as translating non-technical specifications into precise technical requirements.
  • Meet with clients to evaluate their current systems and needs and make recommendations for software and hardware and integration.
  • Travel approximately 30% in support of sales and customer activities.
  • Respond to RFIs, RFPs and serve as liason between the sales, technical and support teams.
  • Play a pro-active “Technical Account Management” role within strategic accounts including relationship and business development activities.

Experience Required

  • Bachelor’s degree in IT-related field or relevant experience.
  • 2 – 5 years of experience in a software pre-sales, post-sales or related role.
  • Keen desire and enthusiasm to assist prospects in understanding the value proposition of the technology and helping customers improve their business processes.
  • 2 – 5 years experience administrating Linux systems (Solaris experience a plus)
  • Experience programming in Lua a plus
  • Experience in the Financial and Healthcare verticals a plus
  • Strong inter-personal, oral and written communication skills a must.
  • Experience with large enterprise software a plus.
  • Experience in the email marketing industry a plus.

In addition, we’re also hiring the following roles:

  • Project Manager
  • Director of Product Management / Alternative Channels
  • Enterprise Software Sales Executive – Mid-Atlantic Region
  • Quality Assurance Engineer
  • Web UI Developer
  • Senior Systems Engineer

Full details for all are at http://www.messagesystems.com/company/careers/, if you’re interested send me an email at mike@ this domain.

We’re Hiring

One unfortunate side effect of the Oracle acquisition of Sun and therefore MySQL is that apparently a number of good people will no longer be part of that team. If any are reading and need a lead, we have a number of positions open at http://www.messagesystems.com/company/careers/:

Web Site Developer

Project Manager

Pre-Sales Engineer (UK)

Director of Sales (UK)

Sales Manager (North East)

Director of Quality Assurance

Director, Professional Services

Client Integration Specialist

Support Engineer

Software Engineer

If interested contact me (myfirstname @ this domain) and I’ll gladly get your resume to the right people. Of course, if you’re not former MySQL and interested you can also feel free to contact me.