SIDEBAR
»
S
I
D
E
B
A
R
«
Email Subaddressing
August 17th, 2021 by miki

Control Reachability of Your Inbox

If you are here because I have pointed to this text to explain my strange use of email addresses. Welcome, this first paragraph is for you, but peruse the technical details about subaddressing below if your are interested.

During my years as an email user I have developed a practice, and conventions around it, of using unique special purpose email addresses when creating accounts, subscribing to newsletters or notifications or otherwise expose the address into an environment where it is likely that it will be or become available to a larger and uncontrollable audience. Generating a unique address pr. sender serves the purpose to enable me to discover who has been disclosing, consciously or not, the address and subsequently take measures against that organisation/individual and not least to effectively filter out emails being sent to that address.

For long this was technically implemented using a catch-all on the mail server side, so that mail destined for any local part (text before the @ “at sign” preceding the destination domain) that is not specifically a user inbox is redirected to a specific inbox.

For some time, however, I have been using another technical approach which is an almost ancient but rather discrete and lesser known feature supported by most mail servers in some way: subaddressing

Subaddressing involves adding a free form text to the local part of the address usually separated by a “+”, so that fx. a unique email address generated by the user “user” on the domain “example.com” for the purpose of subscribing to the Linux Kernel Mailing List (LKML) would be user+lkml@example.com instead of user@example.com.

The rest of this text will dive into the confusion, technicalities and implementations of subaddressing.

Subaddressing

I will use this term for the feature that is known by many other names, I guess in part because of the lack of standardisation, but in its essence it regards dividing the local part of an email address into a part that describes the recipient, as is the traditional scenario, and another part which is an arbitrary free form string not influencing the recipient but can potentially influence the folder in which the mail is stored.

In practise, the most common delimiter is the plus character (“+”), which is also suggested in IETF documents, although some systems are using hyphen (“-“), a few equals (“=”) but some MTA software even allow an arbitrary delimiter to be configured, or even arbitrary ordering of the two parts.

As mentioned, many different terms are in use to refer to this approach, adding to the confusion, but here is an attempt at listing them in roughly chronological order and with some indication of usage (more about that and references further down in Availability and Resources & Discussions);

  • user level alias (usenet FAQ)
  • submailbox (usenet FAQ)
  • extension address (postfix, qmail, s/qmail, notqmail)
  • subaddressing (IETF RFC/draft, Wikipedia, postale.io)
    • IETF documents also uses specific terms about the local parts of the address and the complete address
    • user part: part deciding receiving user
    • detail part: additional carried information (aka. subaddress)
    • detailed address: address with a detail part
    • primary address: address without a detail part
  • alias (Google, Protonmail)
  • email suffix (RegExCatcgAll)
  • email tagging or address tagging (Google, Spamhero)
  • plus addressing (Microsoft, fastmail.com, Smarter Mail, cPanel, Debian wiki)
  • +Alias (Protonmail)
  • disposable email address (Yahoo Plus Mail)

Documents that are closest to a specification and/or standard are from the IETF (summary in Wikipedia article “Email address”‘s subaddressing section);

Below follows lists of some common implementations of subaddressing in hosted environments and MTA software and how they handle subaddressing specifically.

Hosted Availability

MTA Software

Messages in the email system are being transferred by Message Transfer Agent as defined in RFC 5598 sec. 4.3.2 and interpretation of the local part of the destination address MUST, according to RFC 5321 sec. 2.3.11, be done only by the destination mail server, so subaddresses used in subaddressing is only a matter of concern to the software installed on this server. Below is a survey of different more or less prominent FOSS and proprietary MTA software anf how they handle subaddressing.

FOSS

Proprietary MTAs

Resources & Discussions


Comments are closed

»  Substance:WordPress   »  Style:Ahren Ahimsa
© 2023 Mikkel Kirkgaard Nielsen, contents CC BY-SA 4.0