Send “plain text” mail only¶

The most common problem experienced by new mailing list participants isthat their mail was rejected because it contained HTML. Generally, HTMLmail is not accepted for the following reasons:

• HTML is a very rich standard that requires complex parsing/renderingengines to properly display message contents. These rendering engineshave very large attack surfaces that may be exploited to deliverharmful payloads, track the recipients’ location, leak private detailsabout their work environment, etc. Disallowing HTML mail helps removea large attack vector and improve overall security.
• HTML mail is very commonly used by spammers to defeat anti-spamtooling (e.g. by hiding large parts of the message with unreadablefonts, using hidden elements, etc). Rejecting HTML messagesdramatically reduces the amount of spam sent to the list.
• Many kernel developers prefer using terminal-based email tools thatbetter integrate with their workflows. Reading HTML messages in suchtools is often not supported by design.
• Messages that send both plain text and HTML parts are often seen asunnecessary bloat that just consumes resources.

For these reasons almost all kernel mailing lists will reject HTMLemail.

Use a short but descriptive subject line¶

The subject line is what the list users will see first, and they willdecide whether to read your message or skip it based on whether theythink your email is relevant.

No good:

Subject:help

Much better:

Subject: backporting frobbledev to kernel 5.15

No good:

Subject:bug

Much better:

Subject: frobbledev data corruption with kernel 6.5

Do not include “confidentiality disclaimers”¶

When posting to public mailing lists the boilerplate confidentialitydisclaimers are not only meaningless, they are absolutely wrong forobvious reasons.

If that disclaimer is automatically inserted by your corporate e-mailinfrastructure, talk to your manager, IT department or consider using adifferent e-mail address which is not affected by this policy. Many ITcompanies have dedicated e-mail infrastructure for kernel developers tospecifically avoid this situation.

Always “reply to all”¶

If you received a reply to your message on the list, always reply-allwhen composing a response, unless you have a good reason to do otherwise(e.g. discussing a sensitive matter off-list). Replying only to thesender of the e-mail immediately excludes all other list recipients anddefeats the purpose of mailing lists by turning a public discussion intoa private conversation.

You should be able to configure your email client to use “Reply All” asthe default action when replying to email.

Do not “top-post” when replying¶

Top-posting is the preferred style in corporate communication, butkernel mailing list discussions commonly require proper context formaximum clarity. For this reason, kernel mailing lists exclusivelyrequire that all communication is sent as interleaved quoted replies.

For example:

On Mon, Oct 23, 2023 at 08:55:56AM -1000, Rando Reviewer wrote:> How do you intend to handle these cases:>> - your device is frobbledIn the case of frobbling, we reinitialize the device after a5-second sleep.> - your device is blimpoxedThis is not currently supported by the manufacturer, so we pretendthat blimpoxing never happens.

This style allows the person reviewing your submission to quicklyestablish proper context for all your replies. Please also see below.

Trim your quotes when replying¶

Maintainer time is extremely precious, so they will greatly appreciateif you trim the quoted text in your reply and only leave thatinformation which is crucial to establish the context of yourcommunication.

For example, this is quoting too much:

On Mon, Oct 23, 2023 at 08:55:56AM -1000, Rando Reviewer wrote:> Hello:Hi,>> Thank you very much for following up with replies! I have> re-reviewed the patches you sent, but I still have concerns.>> As you may know, the frobble subsystem is currently being> deprecated in favor of using systemd-flargle. While we still> accept device drivers written to the older spec, we need> to ensure that there will be dedicated resources at your> company that can convert to systemd-flargle when it becomes> the one and only true way of doing things.>> Are there resources allocated at your company to make sure> the driver is properly rewritten to use systemd-flargle?Yes, we have dedicated one hundred billion dollars to theseefforts.Thank you,--Dev EloperFrobbledev Inc> Otherwise, I will queue up your submission when the merge> window opens up in a couple of weeks.>> Thanks!>> --> Rando Reviewer> Reviewing-is-our.biz

This is much better because it leaves just enough context for thereviewer to understand your reply. It trims the top and the bottom ofthe message to only leave the relevant paragraph:

On Mon, Oct 23, 2023 at 08:55:56AM -1000, Rando Reviewer wrote:> Are there resources allocated at your company to make sure> the driver is properly rewritten to use systemd-flargle?Hi,Yes, we have dedicated one hundred billion dollars to theseefforts.Thank you,--Dev EloperFrobbledev Inc

In general, “how much context to leave” is subjective and will vary fromdeveloper to developer, but they will all get annoyed if they have toskip multiple pages of quoted text to see your reply, or if they have toneedlessly paginate through an untrimmed quoted bottom of the previousmessage just to find that there’s nothing else there.

Do not quote large chunks of code¶

If you want to refer to code or a particular function, mentioning thefile and function name is usually sufficient. Maintainers and developersgenerally don’t need a link to a web interface with the code to be ableto understand the proper context.

If you do decide to quote some code to illustrate your message, try toinclude only those lines that are relevant to the problem and[skip]the code that is unnecessary to understand your point.

Be terse, but polite¶

Participating in Linux kernel development often means sending hundredsof emails per day. Longtime users of the mailing lists have thereforebecome accustomed to the short and to the point style of communicationthat maximizes “signal” and minimizes “noise.”

However, “terse, to the point” communication should not be viewed as alicense to be rude or dismissive. Saying “Hello,” “Thank you” andshowing basic professional courtesy is signal, not noise. Please findtime to appreciate and praise the work of your peers and the collectiveefforts of the Linux development community.

Other resources¶

The following sites also discuss mailing list etiquette and may be agood source of additional information:

• Notes about netiquette
• Kernel Newbies Mailing List Guidelines
• Use Plaintext Email