A test-only email address should be recognized in standards, much as test-only domains exist (e.g., example.com and *.test), for similar purposes of having a token that can safely escape into the wild from internal use and documentation without fear of representing an actual account. I did not find an RFC or other standard providing this.
In a recent effort to get a bounce of an email with a large attachment so I could see its treatment (I needed the string the attachment would produce in the bounce message, since such a string previously caused a word processor to crash and I was filing a bug report), I sent an email addressed rather like i-hope-this-bounces-8658062682789896678967986892@xxxxxxxxxxx (the domain was real). It quickly bounced and I got the string I wanted.
The main problem is finding a name-part or userinfo that no email provider uses now. That likely means it will be long or unusual, although it might turn out to be as simple as exampleexample. It is a problem since parties who wish obscurity, including spammers, often choose unlikely name-parts.
It also can't use any characters that aren't required to be accepted for a name-part or userinfo. It's possible an implementation of email service may not recognize hyphens, underscores, dots, or numerals, that being up to server configuration. I think that limits possibilities to lower-case letters only.
To discover what name-part to reserve for the purpose, here's one way:
1. Invent and compile possible name-parts. The compilation can be of arbitrary length. Because there are many email service providers, even allowing that many are wholesale, the initial list probably should be long.
2. Exclude name-parts likely to be highly susceptible to spam because created by spammers, since email service providers, especially the largest, are likely to allow such addresses for purposes of detecting spam. A Hotmail manager has already discussed this publicly. For instance, one provider may have accounts for John1 and John3 but a spammer may send email to John1, John2, and John3 at every provider even if no one at one provider has ever heard of John2. Therefore, even if no provider serves John2, that name-part should not be on the list, as it'll be needed for spam resistance. Similar customs likely also exist for name-parts ending in current or recent 2- or 4-digit years.
3. To allow anyone to add, allow incoming emails with a specified recipient, a specified subject line, and the message containing only a name-part token or a comma-separated, tab-separated, space-separated, or newline-separated list of name-part tokens. Choosing one separator will cut most spam. The messages can then be copied and pasted if few or the email input automated if many.
4. Check the name-parts against several of the major email service providers' rosters, simply by emailing with trivial personal-like messages. To test if a provider silently drops, if nothing bounces from a given provider, drop the provider from this round. Any name-part that fails to bounce against even one remaining provider checked would be dropped from the compilation, as presumably a customer is using it, and we don't want to disturb any customers.
5. Publish the list of remaining name-parts as a proposed list. Make one copy of the list machine-readable.
6. Mandate that all providers, not just those tested, immediately reserve all those name-parts except that if a name-part is already a customer's or was recently then the provider should continue serving the name-part for as long as the user wants to keep it, as they would for most other name-parts. Because recently-abandoned name-parts still may have temporary value in resisting spam (the notion used by some service providers is that senders of non-spam drop a recipient from their lists after about three months or two bounces but spammers don't, thus exposing upon delivery which emailers are spammers), mandate that the provider reserve each recently-abandoned name-part after it is no longer wanted for spam resistance.
7. If a provider is serving a name-part, including for a customer, spam resistance, or internal use or testing, mandate that the provider report that it is serving the name-part and, if it does not need the name-part after a date certain, report that date, reporting both to the maintainer of the published compilation. Any name-part currently in use by a customer, including for free service terminable at will by the provider, should be treated as having no date certain regardless of plans or promises between customer and provider, since circumstances may require an extension.
8. Upon receiving the report, the maintainer of the published compilation would then mark the name-part as already in use for an account (regardless of account type, including test and internal), and enter the date certain if applicable, without having to say which provider uses it, so a spam-industry address harvester could not acquire a live address.
9a. If the name-part has no date certain, all providers should then be free to make that name-part available to their customers, if they wish.
9b. If the name-part has a date certain, mandate that it be reserved by all providers except any already using it, and mandate that the latter reserve it after the provider's date certain.
9c. If a name-part has a date certain from one or more providers but no date certain from one or more other providers, treat the name-part as having a date certain equal to the date certain that is farthest in the future for that name-part.
10. Finally and permanently select and promulgate one or more name-parts that anyone may use for tests and documentation. The date certain for any name-part so promulgated must have passed or been always nonexistent by the time of selection and promulgation.
11. Immediately release all other names for use by email service providers as they wish.
12. Forbid a sender from sending any legal notice to such a promulgated address. A legal notice to the domain must be to another name-part or by other means.
13. Mandate that all email addressed to a name-part so promulgated be bounced. It must not be received or silently dropped. A provider must not record any of its headers, read any part of the email, or keep a copy, since that possibility alone would require at least some senders to keep copies of what they send to test recipients.
14. No rights may be acquired by the email service provider because of email to such a promulgated name-part at such provider. This is relevant to intellectual property rights and possibly others.
15. Do not forbid a sender from using cc: and bcc: when sending. It may be relevant to testing. For example, a sender may wish to cc: a real recipient as notice of a test or to test cc: by sending one email to two providers' test name-parts.
16. If a provider has antispam or other policies by which some incoming email is refused (either bounced or silently dropped) before consideration of a name-part, such policies may be continued without regard to this policy. For example, a policy of silently dropping inbound email with giant attachments of unknown MIME types may be continued. If the policy differentiates between such a promulgated name-part and other name-parts, the email service provider must favor a policy that requires or is closer to requiring bouncing.
17. I assume if an email has a cc: or bcc: list but is being bounced for the primary addressee that bounce reports do not go to any cc: or bcc: parties, but anyway mandate that they not, lest that lead to abuse, spam, or just excess network traffic via cc: or bcc:.
As this relies on phases as email service providers become aware of requirements, a schedule spread over months or a year or two should suffice. I think the burden on any party is small, other than for compiling and maintaining the list of possible name-parts.
Thank you.
--
Nick
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf