At 01:05 29-03-2009, Nick Levinson wrote:
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.
You can use user(_at_)example(_dot_)example or
nick_levinson(_at_)levinson(_dot_)example(_dot_) These email addresses will result in
a delivery failure if they are used on the Internet.
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 is near impossible to find a name-part which no email provider
uses as people use long and unusual name-parts too. There are also
domains that use a "catch-all" for mail.
To discover what name-part to reserve for the purpose, here's one way:
[snip]
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.
It is better to ask the email service provider instead of spamming its users.
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.
Nowadays, your mail server can get blacklisted when it sends
bounces. The mandate you propose will be ignored.
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.
An optimistic schedule would be ten years.
There are a large number of senders that do not know to which email
address the bounces go to. Designating an email address for testing
will only conflate the problem. Some mail servers only include the
original message headers in the bounce.
At 17:38 02-04-2009, Fred Baker wrote:
When you sent this note, I immediately sent an email to
test(_at_)example(_dot_)com(_dot_) It took a few days, as my mail handler
queues things
up and retries them for a while, but I eventually got a bounce. I
suspect that any email address @example.com would have sufficed, as
there is by definition no A record and no mail receiver for example.com.
There is an A record for example.com. There is a web service
responding to queries on the IP address to which example.com resolves
to. There isn't any mail service listening for SMTP connections at
that IP address nowadays.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf