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(_at_)example(_dot_)com (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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf