Independently of all the concerns about who is mandating what, there are
a few informational points that are interesting even for sites that
implement subaddressing locally--i.e. that can serve as advice for some
kinds of new implementations. For purposes of this presentation I'm
going to assume that the locally-interpreted subaddressing scheme is
based on a ``addr+subaddr'' form of local-part.
Point one: Copy the incoming address to a Received: header, perhaps in a
``for'' clause. Generally, I want to be able to put my
addr+subaddr(_at_)domain address in a distribution list and retain the fact
that it was sent to addr+subaddr. If the +subaddr text is to be
interpreted by some post-delivery process, it has to be recorded
somewhere at delivery time, and a Received: header is a reasonable
Point two: Use the entire addr+subaddr for any duplicate elimination.
If an MTA attempts to eliminate the delivery of duplicate messages, it
will often do so by refusing to send the SAME MESSAGE to the SAME
ADDRESS. Thus, it can make some record of having sent a given message
to a given address, and future delivery attempts can check for such a
record. While I could offer some advice about what constitutes an
adequate record of the SAME MESSAGE, at this point I'd just remark that
the entire addr+subaddr information is important to be considered for
purposes of duplicate elimination; thus, sending message A to addresses
foo+bar and foo+baz is not an instance of duplicate delivery.
Point three: Raise the issue of copying the +subaddr annotation.
Suppose mail to local user user1 is forwarded to local user user2. If
mail arrives for user1+foo, should it be forwarded to user2 or to
user2+foo? Perhaps the MTA's notion of mail forwarding needs to be able
to allow the user or administrator who sets the mail forwarding to make
Needless to say, these fine points arose from real-life use of
addr+subaddr notation over a few years.