Subject: Re: designate an email address for testing at any provider

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Mar 2009 21:51:56 -0400

Aside from the opinions that it's too late to have an explicit bounce
address be recognized (and catch-all systems could be told to
explicitely bounce it)... the biggest problem with the explicit bounce
is simple... I just send:

   MAIL From: Nick Levinson <[email-masked]>
   RCPT To: <[email-masked]>
   ...

and you may get backscatter.  

Sure, we may be able to write that the SMTP transaction should fail
immediately, but then, that wouldn't help your situation, because you
wanted the bounce message from the remote mailer, not from your mailer.

Of course, many mail systems are unable to make the SMTP transaction
fail so soon, and backup-MXs can not do it at all, so we wouldn't even
be able to write such text.

- -- 
]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Apr 2009 17:38:03 -0700

On Mar 29, 2009, at 1:05 AM, 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.

When you sent this note, I immediately sent an email to  
[email-masked]. 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.

---

From: <[email-masked]>
Date: Fri, 3 Apr 2009 11:01:09 +0200

Fred Baker wrote:

> [email-masked]. 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.

BTW, example.com does have an A record (and web server listening
on port 80). But nothing listening on port 25, it seems.
(And it doesn't support IPv6 either :-)

Best regards,
Pasi

---

From: SM <[email-masked]>
Date: Fri, 03 Apr 2009 02:42:19 -0700

At 01:05 29-03-2009, Nick Levinson wrote:
>actual account. I did not find an RFC or other standard providing this.

You can use [email-masked] or 
[email-masked].  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 
>[email-masked] (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.

>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