When Asking a Question

steve
Industry
October 5, 2023

A lot of beginner questions about email delivery aren’t about broad strategies for success, or technical details about authentication, or concerns about address acquisition. They’re something like:

My mail to $ISP is being blocked. How do I contact someone there?

Asking a question to your peers about how to deal with a concrete problem you’re having is a great thing to do – you might get immediate help, and hopefully you’ll pick up some technical or industry information and level up some skills along the way.

But there are good questions and good ways to ask them, and bad questions and bad ways to ask them. You really want to get the most value out of the answers you get, and you don’t want to waste your peers valuable time.

Lets talk about the “My mail is blocked, who do I ask to fix it?” sort of question on an interactive forum such as Slack, but most of the advice is applicable to other questions in other sorts of places.

Before you ask

Is your mail accepted successfully by the recipient mailbox provider, but then delivered to the spam folder / promo tab / somewhere you can’t find it? Or is it being delivered but you’re not seeing opens / clicks / massive purchases?

These are good questions, but are likely to have much squishier answers and much of the rest of this list doesn’t apply (though some of it does).
Do you have the full rejection message from the mailbox provider? If all you have is a summary or categorized report from your ESP, go find the actual rejection or deferral message. It’ll look something like “554 5.7.9 Rhubarb hatstand - [PH01] Cantaloupe aardvark https://postmaster.yahooinc.com/error-codes“.

If you can’t easily get that, or have to reach out to your ESP customer support desk to get it then you’re not going to have a good time diagnosing delivery issues yourself.
Is this a deferral, where your mail system will automatically retry delivery of the mail, or is it a rejection, where you shouldn’t try and deliver again? Rejection messages begin with a 5, deferrals with a 4. Deferrals happen, and a low rate of them isn’t necessarily a problem.
Did you read the rejection message? They’ll often have, in fairly plain english, some details about why mail was deferred. That might answer your question or point you in the right direction.
Do you know what IP address you’re sending mail from? Make a note of it, you’ll need it.
Is there a link in the rejection message? If there is, click on it and see what it says. Sometimes they’ll lead to a form that lets you see whether an IP address is blocked or not – enter the IP address you’re sending from and see what it says.

Sometimes it’ll give you a list of SMTP response codes (e.g. 421 or 553). They’ll tell you what the recipients mailbox provider means by that rejection code.

Sometimes it’ll list phrases or ISP-specific codes that are used in the rejection messages (e.g. “Authentication failure”or “TS04”) which can give you a fairly specific reason for the rejection.
Have you asked your ESP about it? They have access to a lot more data than you do about delivery issues across their entire customer base, and may well have already seen a similar issue with another customer. And it’s what you’re paying them for.
Search the forum where you’re about to ask for any obvious codes in the rejection message (e.g. “PH01”). Maybe you’ll get an explanation of what can cause it. Maybe you’ll see other folks are seeing the same issue. Sometimes you’ll find an announcement from the mailbox provider, or from someone who’s talked with them that it’s a known issue, a false positive that’s being worked on.
Search the forum for the name of the mailbox provider. Maybe other people are seeing the same issue. Or maybe someone has posted something useful about that providers behaviour.

Asking the question

IP addresses and domains and authentication details are not company secrets, and trying to hide them will hurt your chances of getting a useful answer. DNS is public, and email is largely public. A lot of delivery issues depend on those details, and if someone asks for more details they’re probably trying to help.

Also, there’s a history of bad actors trying to get information to evade spam filters. They tend to be very coy about who they work for, where their mail is being sent from and who it’s being sent to. If you look like a spammer you’ll probably be treated like one.
Ask in public, not in private.

Questions to a well-chosen public forum are more likely to get useful answers than to a private one. It gets more eyeballs on the issue, and problem solving as a group is often more effective and more interesting to do.

Many of the folks do this professionally and answering a question in private is just asking them to do hundreds of dollars of work for free. Answering in public is something they do when they feel like it, or if it’s interesting – and it demonstrates their expertise, so it’s a somewhat justifiable use of their business hours.
Ask in one place, don’t blast it out to multiple channels. If you ask in the wrong place and someone suggests a better place it’s fine to re-ask in the better place, and add a pointer to that in your original thread.
Block out some time to be involved. Asking a question then just vanishing, and not being around to answer requests for clarification wastes everyone’s time.
Ask about your problem, not about what you think the solution should be. (This is known as the XY problem). “What can I do to fix this delivery issue to $ISP” is the problem you have, “I need to ask someone at $ISP to remove this block” is what you think the solution should be.
Be respectful of people’s time. Include the critical information as you understand it in your initial question, rather than needing to have basic details teased out of you over rounds of clarifications. Actually ask the question, don’t link to where you asked the question somewhere else (a link to StackOverflow or LinkedIn or … is never a good question).

There’s seldom any need to include large amounts of data (log files, screenshots, entire messages, dozens of rejection messages). If there is you can share it later.
Be respectful of people’s screen space. If your question and it’s associated data is more than a couple of lines, hide most of it in a thread. Just make sure there’s enough context in your first post to let people know whether it’s worth their opening the thread to see the rest of it. “Hey, I’m seeing odd deferrals to Yahoo and Google apps customers over the past 36 hours, with ‘418, I’m a teapot’. Anyone else? More details in thread.” is good, followed by a thread, with more details.

For any chunk of text that’s more than a few lines consider using a Slack text snippet rather than just pasting it into a channel. For bigger things linking out to a pastebin or a github gist or similar might be worthwhile.
Don’t flag your question as urgent. It’s not an emergency. There’s no such thing as a deliverability emergency, and if there were you’d be paying someone to help with it rather than relying on the generosity of the internet to fix it for you. Chill.
Never include the recipients email address, unless it’s a mailbox you control and are sending test mailings to. Ideally remove the left hand side from the email address and leave the right-hand side. I don’t need to know that you’re sending mail to steve@blighty.com, but it’d be very useful to know that you’re trying to send to someone at that domain.

❌ “steve.smith@gmail.com”
✅ “<deleted>@gmail.com”
Include the full rejection or deferral message, other than removing PII such as the recipients email address. Your IP address is not PII, your domain is not PII, the recipient mailbox providers domain is not PII.
Include the most important information about how the mail is being sent. What IP address is it being sent from? What domain is it being sent to? If that’s not obvious from the rejection message, include it explicitly.

If you know who the mailbox provider is (e.g. Google workspace) and it’s not obvious from the recipient domain mention that.

Is it being sent from an ESP pool shared amongst multiple customers, or a dedicated ESP owned IP, or an IP owned by the sender?

Is it B2C mail or B2B? They often have very different filters and delivery issues.

Is it cold email? (If so, any delivery issues are spam filters working as intended and it’s really not worth asking the question).
Include anything that seems important about what’s in the mail being sent and who it’s being sent to. Is it transactional? Marketing? Password resets?

Is it being sent to active users or new signups?
What’s changed? Did delivery suddenly fall off a cliff a week ago? Did you change ESP? Did you start sending to an older group of addresses?
What have you tried so far? This helps narrow down what the issue may be, and hopefully reduces the amount of clarification / have you tried? questions. It also demonstrates that you have tried to get somewhere before asking for help.
Don’t use screenshots of text, use the text itself. Screenshots of things like charts of delivery rates over time? Sure. Screenshots of web reports or other all-text content? If you can share it as readable text, do that instead.
Don’t start off by bitching about how terrible Gmail’s filters or Yahoo’s staff or .. are. It’s unprofessional. It’s rude. We know folks who work there. They may be represented in this very forum. And it also demonstrates that you have a childish understanding of how spam filters work.

“Yahoo are blocking your mail because you’re sending spam, Gary.”

And then

Wait. It’s an asynchronous medium. People are busy. People are all around the world in different timezones. Don’t “bump” the issue to try and get an immediate response.
People will ask for clarification. Try and answer that helpfully.
People will often ask about an aspect of your issue you don’t feel is relevant. Just go with it. They’re trying to help you fix your problem, and they may see an underlying issue you’ve not considered. (Also it’s far quicker and more productive to answer a few clarification questions than expend any effort on defending why that’s not the issue).
Quoting from Eric Raymond:
“Much of what looks like rudeness in hacker circles is not intended to give offense. Rather, it’s the product of the direct, cut-through-the-bullshit communications style that is natural to people who are more concerned about solving problems than making others feel warm and fuzzy.”
People will ask you to try and share additional data (“What selector are you using to sign DKIM with?”, “Have you seen click activity from these recipients in the past month?”).

If it’s easy to get, give ’em the info even if it doesn’t seem relevant. They may see something you don’t, and it helps to look cooperative with folks.

If it’s going to be more time consuming, but seems like it might be relevant then confirming you’ve seen the suggestion isn’t a bad idea. “Yeah, that might be a bit more work to get but if we’ve not fixed it by then I’ll pull that data tomorrow.”

And afterwards

If you fixed the problem, share what the problem was and how you fixed it. It’s only polite.
If you didn’t fix the problem, but it just went away that might be worth sharing in the original thread too. Negative results can be as useful as positive ones.
Learn from it. When someone asks near identical questions repeatedly and they’re clearly not levelling up their skills or are just lazily asking a forum to help them do their job they’ll often start being ignored by folks who are generally skilled and helpful.
Help other folks out. Stick around, answer other’s questions.

Be nice.

Questions about Spamhaus

I have gotten a lot of questions about Spamhaus since I’ve been talking about them on the blog and on various mailing lists. Those questions can be condensed and summed up into a single thought.

Interacting in professional fora

There are a bunch of online communities – mailing lists, Slack channels, etc. – where “people who do email” interact.
Some of them are open to anyone to subscribe, some of them are semi-private and require an invitation, others are closed and only available by invitation and yet others are associated with trade associations and only open to their members.
Many of them include representatives from ISPs, ESPs, reputation providers and technical specialists. They also – especially the open lists – have participants with no particular role in the industry, but very strong opinions on what others should do.
They’re a useful place to keep up to date on current issues and industry trends, and to get help when you need it. But … quite a lot of people reduce their chance of getting timely help by the way they behave there. Don’t be like those people.
Some of the things you should and shouldn’t do are specific to mailing lists. Some are specific to professional fora. Some are specific to entreating others for help. Here, in no particular order, are some suggestions:

DO: Be friendly. Be patient. Be welcoming. Be considerate. Be respectful.
DO: Be careful in the words that you choose.
DON’T: Be a dick.

DON’T: Be wildly unprofessional. If you think sexist or racist behaviour isn’t wildly unprofessional, leave the email industry. Ditto for unwanted sexual attention, personal insults, sexualized language or imagery.
DON’T: Harass people. If someone wants you to stop, then stop.

DO: Follow the community norms. Different communities have different styles and traditions – try and pick up on what they are, and avoid violating them.
DO: Follow the community norms for replying to messages, quoting them and trimming threads. If you’re not sure what they are then snipping out parts that aren’t relevant and replying in-line isn’t likely to offend anyone.
DO: Follow the level of formality of the community. Some are very formal, and should be treated much the same as a business meeting. Others much less so, and blend professional discussion with blowing off steam, ranting about idiot clients and social banter between friends.
DO: Lurk on the list for a day or three before posting to get a feel for how the community works (unless there’s a “welcome to the new person” thread). If you’ve joined because you have an immediate emergency you’re looking for help on, say so and be polite – maybe even a little apologetic – about it. Maybe spend five minutes checking the list archives first.
DON’T: Lurk except when you have a problem. Interacting with others when you’re not asking for help builds up relationships and karma. If you only appear when you’re looking for help, people are less likely to be helpful.

DO: Be clear about what company or organization, you’re affiliated with. That might mean using a corporate email address, mentioning it in a sig file or in a “Hi, I’ve just joined the group” message. Or it might mean including the relevant company name when asking for help. If, for political reasons, you absolutely cannot admit to your affiliations it’s still useful to know that you work for an unnamed major US cable company or an email provider based in Switzerland – particularly when you’re offering help or advice where your insight is coming from your experience in that role.
DO: Remember that the vast majority of the people you’re interacting with aren’t being paid to be there. They’re sharing their time and expertise in return for benefiting from others. Try to both give and take.
DO: Remember that a representative from a large ISP probably doesn’t have answering your questions or helping with your problem in their job description.

DON’T: Aggressively demand help. Nobody owes you anything.

DO: Read responses carefully. Someone may not be able to publicly join the dots on an issue for you, but may point out which dots you might want to look at.
DO: Understand limits. If someone says “our lawyers say this is the process you must follow” then follow that process. And don’t push that person to do things that their lawyers say they can’t do.
DO: Be aware that you’re interacting with people, not company representatives. They almost certainly have opinions that don’t reflect those of their organizations.
DO: Remember that nobody owes you support. Be nice. And if someone doesn’t volunteer help or stops responding, don’t badger them.

DO: Follow the community style for how you present your message. But … in general, mostly plain text won’t offend anyone, heavy use of rich text will annoy some people.
DON’T: Rely on rich text for meaning. It may not be visible to some people or not visible when quoted. “Look at the log lines highlighted in yellow” isn’t a good approach.
DON’T: Warlord. There’s no need for long legal disclaimers on your mail. Nor for more than four lines of signature – we don’t need to know your life history. Graphics are cheesy, even if they’re your employers professionally drawn logo. Even colour can be distracting if it’s not used carefully.

DON’T: Assume that you’re the best representative of your organization to interact with a community. If you’re a senior manager and you have a smart employee who is actively working in the area – they may be a better rep than you are.

DO: Be aware of how public a community is. Does it have a public archive that’s indexed by Google? Is it open subscription? Be aware of how public things you say are.
DO: Be aware of what is expected from you in terms of information distribution. Can things you learn from the community be shared elsewhere? With attribution, or not? If you’re not sure, don’t share information unless the person providing it OKs that – it’s always OK to ask if you’re not sure. Terms you might see are Traffic Light Protocol or Chatham House Rule.

DO: Assume good faith.

DO: Provide relevant information when looking for help or asking “has anyone else seen this?”.
DO: Check unread mail to a list before posting. If someone else is already talking about an issue, join that thread rather than starting your own.
DO: Check the archives first, if you can. The answer to your problem might be in there. And if it’s not, including a mention of “this looks similar to what Yahoo was doing in October” signals that you’ve done a little work before asking for help and might trigger someone’s memory of what happened last time.
DO: Include relevant IP addresses and hostnames, if you’re asking about a delivery issue.
DO: Include exact error or rejection messages – “blocked at AOL” isn’t particularly useful, “554 RLY:B1” is much more so.
DO: Mention what sort of email it is, especially if you think the problems may be content related.
DON’T: Obfuscate.
DO: If you’re asking about a problem, say how long it’s been going on and what you’ve already tried to fix it.
DO: Respond promptly if someone asks for more details.
DON’T: Expect help if you’re not prepared to share data.
DON’T: Vanish once you resolve the problem. Share what you did, even if it’s just “it cleared up around 3pm”.

DO: Be prepared to take conversations that only you and one other person, out of hundreds, are interested in to direct message or private email.

DO: Stick around and help others. Share what you know.
DON’T: Post off-topic stuff people aren’t going to be interested in. It’s great that your kid is selling girl scout cookies or you’re doing a charity 5k, but unless you’re absolutely sure that this is a good place to fundraise, it almost certainly isn’t.
DO: Keep conversation on a mailing list, on the mailing list. There’s no need to Cc everyone involved – they’re on the mailing list too.

DON’T: Email angry. If someone has made you mad, wait before responding.

Thanks for your questions!

Thanks, everyone, who submitted questions to laura-questions@wordtothewise.com. We’ve gotten some great questions to answer here on the blog. I’m working through the emails and contacting folks if I have questions. I’ll be answering the first question on Wednesday.
I also did have someone harvest the address off the website and send me non-CAN SPAM compliant spam to it. I have to admit, I didn’t expect someone to harvest the address at all, but especially not within 12 hours of posting an address. Particularly someone who’s not harvested our contact address previously. I also am considering how much content I could get detailing taking the spammer to court in CA for violating CAN SPAM and the CA anti-spam statute.