It is time to translate another email technology-related term here on Spam Resource! The DELIVTERM for today is: List-ID. List-ID is an email header, and the specifics of this email header are defined in RFC 2919.
Courtesy of RFC 2919, here are examples of the List-ID header.
List-Id: List Header Mailing List <list-header.nisto.com>
List-Id: <commonspace-users.list-id.within.com>
List-Id: "Lena's Personal Joke List" <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
Each of these has a “list ID” token, but how they handle the descriptive “phrase” setting varies. What’s different about each of those?
This first one has a simple descriptive phrase associated with the list-ID token value.
This one contains no descriptive phrase.
This is another version of providing a descriptive phrase alongside the list-ID token value. Note that the formatting here works just like the From: and To: headers, as far as wrapping the phrase in double quotes, especially if there’s something that needs quoting to prevent confusion around where the header ends (like a comma or single quote). Instead of using a valid domain for the list-ID token value, they use the allowed alternative of “localhost.”
Another example, this type using a “list-id” subdomain in the token. Not required by the spec, but may be useful for a sender, when organizing a way to manage multiple list IDs.
No descriptive phrase, and no domain name in the list-ID token value.
All of these are valid types of list-ID headers. The RFC offers some suggestions with regard to criteria around deciding List-ID definition criteria. If you manage an email service provider (ESP) or other email sending platform, you may want to link the List-ID field to a customer identifier, so that users may easily filter and route email from that customer, even if the from address or domain/subdomain might change over time. This isn’t only so that subscribers can hide your mail from view; it can be used to route the mail to a specific folder for easy sorting, or even to exempt it from some spam filtering.
Implementation of List-ID filtering support on the receiving side of things is a bit light; in theory, any MUA (mail user agent; aka email client) that can filter on any header can implement a filter based on the list-ID header, but in practice, this is not always easy to understand or implement.
With regard to webmail providers, Gmail is the biggest support of list-ID filtering support. In Gmail, if you select “Filter messages like this,” and the message in question has a list-ID header, Gmail will pre-populate a search descriptor of list: followed by the list-ID header value of the email message. This can be very handy for message filtering.
It is time to translate another email technology-related term here on Spam Resource! The DELIVTERM for today is: List-ID. List-ID is an email header, and the specifics of this email header are defined in RFC 2919.
Courtesy of RFC 2919, here are examples of the List-ID header.
- List-Id: List Header Mailing List <list-header.nisto.com>
- List-Id: <commonspace-users.list-id.within.com>
- List-Id: "Lena's Personal Joke List"
- List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
- List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>
Each of these has a “list ID” token, but how they handle the descriptive “phrase” setting varies. What’s different about each of those?<lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
- This first one has a simple descriptive phrase associated with the list-ID token value.
- This one contains no descriptive phrase.
- This is another version of providing a descriptive phrase alongside the list-ID token value. Note that the formatting here works just like the From: and To: headers, as far as wrapping the phrase in double quotes, especially if there’s something that needs quoting to prevent confusion around where the header ends (like a comma or single quote). Instead of using a valid domain for the list-ID token value, they use the allowed alternative of “localhost.”
- Another example, this type using a “list-id” subdomain in the token. Not required by the spec, but may be useful for a sender, when organizing a way to manage multiple list IDs.
- No descriptive phrase, and no domain name in the list-ID token value.
All of these are valid types of list-ID headers. The RFC offers some suggestions with regard to criteria around deciding List-ID definition criteria. If you manage an email service provider (ESP) or other email sending platform, you may want to link the List-ID field to a customer identifier, so that users may easily filter and route email from that customer, even if the from address or domain/subdomain might change over time. This isn’t only so that subscribers can hide your mail from view; it can be used to route the mail to a specific folder for easy sorting, or even to exempt it from some spam filtering.Implementation of List-ID filtering support on the receiving side of things is a bit light; in theory, any MUA (mail user agent; aka email client) that can filter on any header can implement a filter based on the list-ID header, but in practice, this is not always easy to understand or implement.
With regard to webmail providers, Gmail is the biggest support of list-ID filtering support. In Gmail, if you select “Filter messages like this,” and the message in question has a list-ID header, Gmail will pre-populate a search descriptor of list: followed by the list-ID header value of the email message. This can be very handy for message filtering.
Additionally, Apple’s iCloud mail has the ability to create a filtering rule that will allow a user to filter messages based on the list-ID header.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.