Wayne, thank you for taking the time to talk to me today! I usually kick these things off asking about how you got started in email and/or deliverability. Looks like you came to it through the internet service provider (ISP) route, no? Did your initial unix-related role at Bellsouth involve email, or did that come later as everything got borg'd into AT&T?
Most MTA admins fall into the work by accident. If you have a room of 100 unix admins and ask "who wants to run the MTA?" no one will raise their hand. I was a brand new admin so I was foolish enough to volunteer for the work. I worked at a mom and pop dial up ISP in the mid 1990's. One of the main reasons to get a dial up account was to get email. I worked my way up from phone support to unix admin and was put in charge of our single MTA server. It was a Sun OS box running Sendmail. I like text based work, found out I was good at unix shell and regex, and had a knack for running live services. Email was much more appealing than coding.
I did not start out at SBC as an MTA admin. But again, there was a project to retire the legacy MBP for Americtech/Swbell/Pacbell. Again, no one on staff had MTA experience except me. A 60 day project turned into a 5 year project. If you remember, SBC planned to use Prodigy as their ISP. That fell apart. Later it was SBC/Yahoo, and that project was completed. This was my first big platform, about 1 billion emails per month.
After the SBC/Yahoo project, I heard about a startup in Indy called ExactTarget. They were sending email for commercial messaging. After several false starts, I got in touch with the right people and as they say, the rest is history. My first month at ExactTarget, we sent 1 billion emails. As of Black Friday/Cyber Monday 2023, the platform I designed for SFMC sent almost 7 billion emails.
I've found that deliverability folks that have worked both the sender side (ESPs, etc.) and receiver side (ISPs and mailbox providers) tend to have a better understanding of the challenges that mailbox providers face – that there's a universe of bad things and challenges that reach far beyond simple marketing mail. Do you think your ISP experience helped you in your later ESP-related roles? And if so, how?
Working both sides has helped me a great deal. At my ISP jobs, I had to manage anti-abuse methods to keep our services running. At SBC, we were not allowed to use vendor products for anti-abuse. I ended up writing my own RBL and automations to report to the policy team. Understanding how ISPs manage their services helps me be a good sender. My basic rule is "do no harm". If I see a pattern of sending that I know would stress their infrastructure, I will modify sending to align with their postmaster policies and my general knowledge of email gateways.
I noticed lately that the new Yahoo/Google requirements seem to have resulted in a dramatic shift in MTA queue averages for some senders and platforms. Gmail's deferring a lot more mail than they have done in years past, which means in some cases MTA queues and MTA disks are fuller for longer, with the potential to impact platform health if it isn't well accounted for. What kind of other client, MTA, system or platform issues can jump out at you, identifiable from MTA logs and MTA data?
At my most recent job we have been monitoring the new blocking by Gmail. So far the blocking has been light, but Google stated that they would be rolling out the new policies from February to June. We see two types of blocking, blocks due to lack of auth and blocks for unwanted emails based on SPF or DKIM. This is the obvious shift away from IP based policies to domain based policies. We will have to wait and see how Gmail handles these new policies.
A few details on the new SPF/DKIM blocking. Lack of AUTH has both 4XX and 5XX DSN's. I assume the policy is to compensate for transient DNS resolution issues. Once the gateway has confirmed that SPF or DKIM do not exist, the block moves to a permanent 5XX block.
The other detail to note, some of the older IP based block DSN's have been retired. You may want to check your existing Gmail sending rules to see if they are still working as expected.
And you made me think of an important point – basically, that "your mileage may vary" – what happens next will vary, depending on the nature of your client mail streams, what they're sending, and whether or not they were already authenticating. It's possible that big, enterprise senders might see fewer issues than MTA pools made up of entirely SMB/newsletter traffic, much of which might not have been fully authenticated before.
Technically there is no reason a SMB cannot make the leap to proper authentication. It is a bit of a challenge in shared pool space, but it can be done. I think the real challenge will be education and tools. It will be up to the email community to educate why auth matters and to create tools to make provisioning auth easier.
After you got laid off recently, your next move seemed to be to eat a taco. Are you a big taco fan? What makes the perfect taco?
Really there is no such thing as a bad taco. But one of the students I mentor at my children's high school likes to put ketchup on her tacos. I do not approve.
It has been said (accurately so) that raisins ruin everything. Do you agree, or are you wrong? If not raisins, what is one foodstuff or ingredient that you believe should simply NOT exist, something you can't believe people knowingly enjoy?
I seek out raisins. That makes me highly questionable to some.
What's the one bit (or two bits or three bits) of advice you wish you could give every email marketing or bulk email sender? Is there guidance, a recommendation, or a wish, that marketers just haven't understood or haven't heeded so far, where you wish you could snap your fingers and just change their mind without argument?
Read the DSN. When the DSN says "you have been blocked for a high volume of unwanted email" that means no one wants your email.
This is how I feel some days working with clients:
Client: If you want to keep our business you to find a way to get 1 percent more emails to Gmail
Me: OK, let me take a look (whistles)
Client: we plan to triple our list the first week of November....
As my friend Karen would say, clients cannot do simple maths....
Clients, you control list quality. List quality is the primary variable for delivery. Engaging content and product is the primary variable for deliverability.
Wayne, thanks so much for sharing your time and expertise today. It's really fun to get to catch up and geek out about MTAs and I look forward to future chances to chat about this sort of thing with you!
Wayne, thank you for taking the time to talk to me today! I usually kick these things off asking about how you got started in email and/or deliverability. Looks like you came to it through the internet service provider (ISP) route, no? Did your initial unix-related role at Bellsouth involve email, or did that come later as everything got borg'd into AT&T?
Most MTA admins fall into the work by accident. If you have a room of 100 unix admins and ask "who wants to run the MTA?" no one will raise their hand. I was a brand new admin so I was foolish enough to volunteer for the work. I worked at a mom and pop dial up ISP in the mid 1990's. One of the main reasons to get a dial up account was to get email. I worked my way up from phone support to unix admin and was put in charge of our single MTA server. It was a Sun OS box running Sendmail. I like text based work, found out I was good at unix shell and regex, and had a knack for running live services. Email was much more appealing than coding.
I did not start out at SBC as an MTA admin. But again, there was a project to retire the legacy MBP for Americtech/Swbell/Pacbell. Again, no one on staff had MTA experience except me. A 60 day project turned into a 5 year project. If you remember, SBC planned to use Prodigy as their ISP. That fell apart. Later it was SBC/Yahoo, and that project was completed. This was my first big platform, about 1 billion emails per month.
After the SBC/Yahoo project, I heard about a startup in Indy called ExactTarget. They were sending email for commercial messaging. After several false starts, I got in touch with the right people and as they say, the rest is history. My first month at ExactTarget, we sent 1 billion emails. As of Black Friday/Cyber Monday 2023, the platform I designed for SFMC sent almost 7 billion emails.
I've found that deliverability folks that have worked both the sender side (ESPs, etc.) and receiver side (ISPs and mailbox providers) tend to have a better understanding of the challenges that mailbox providers face – that there's a universe of bad things and challenges that reach far beyond simple marketing mail. Do you think your ISP experience helped you in your later ESP-related roles? And if so, how?
Working both sides has helped me a great deal. At my ISP jobs, I had to manage anti-abuse methods to keep our services running. At SBC, we were not allowed to use vendor products for anti-abuse. I ended up writing my own RBL and automations to report to the policy team. Understanding how ISPs manage their services helps me be a good sender. My basic rule is "do no harm". If I see a pattern of sending that I know would stress their infrastructure, I will modify sending to align with their postmaster policies and my general knowledge of email gateways.
I noticed lately that the new Yahoo/Google requirements seem to have resulted in a dramatic shift in MTA queue averages for some senders and platforms. Gmail's deferring a lot more mail than they have done in years past, which means in some cases MTA queues and MTA disks are fuller for longer, with the potential to impact platform health if it isn't well accounted for. What kind of other client, MTA, system or platform issues can jump out at you, identifiable from MTA logs and MTA data?
At my most recent job we have been monitoring the new blocking by Gmail. So far the blocking has been light, but Google stated that they would be rolling out the new policies from February to June. We see two types of blocking, blocks due to lack of auth and blocks for unwanted emails based on SPF or DKIM. This is the obvious shift away from IP based policies to domain based policies. We will have to wait and see how Gmail handles these new policies.
A few details on the new SPF/DKIM blocking. Lack of AUTH has both 4XX and 5XX DSN's. I assume the policy is to compensate for transient DNS resolution issues. Once the gateway has confirmed that SPF or DKIM do not exist, the block moves to a permanent 5XX block.
The other detail to note, some of the older IP based block DSN's have been retired. You may want to check your existing Gmail sending rules to see if they are still working as expected.
And you made me think of an important point – basically, that "your mileage may vary" – what happens next will vary, depending on the nature of your client mail streams, what they're sending, and whether or not they were already authenticating. It's possible that big, enterprise senders might see fewer issues than MTA pools made up of entirely SMB/newsletter traffic, much of which might not have been fully authenticated before.
Technically there is no reason a SMB cannot make the leap to proper authentication. It is a bit of a challenge in shared pool space, but it can be done. I think the real challenge will be education and tools. It will be up to the email community to educate why auth matters and to create tools to make provisioning auth easier.
After you got laid off recently, your next move seemed to be to eat a taco. Are you a big taco fan? What makes the perfect taco?
Really there is no such thing as a bad taco. But one of the students I mentor at my children's high school likes to put ketchup on her tacos. I do not approve.
It has been said (accurately so) that raisins ruin everything. Do you agree, or are you wrong? If not raisins, what is one foodstuff or ingredient that you believe should simply NOT exist, something you can't believe people knowingly enjoy?
I seek out raisins. That makes me highly questionable to some.
What's the one bit (or two bits or three bits) of advice you wish you could give every email marketing or bulk email sender? Is there guidance, a recommendation, or a wish, that marketers just haven't understood or haven't heeded so far, where you wish you could snap your fingers and just change their mind without argument?
Wayne, thanks so much for sharing your time and expertise today. It's really fun to get to catch up and geek out about MTAs and I look forward to future chances to chat about this sort of thing with you!
Also, people! You should hire this guy!
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.