I've dropped the proposal because of security concerns for which I don't have ready answers, the amount of work needed, and the possible lack of interest. I'm not sure it's as useful as I first thought. But some responses should be addressed in case someone wants to pick up the idea.
That some systems ". . . will now outright reject email to an unknown recipient . . ." I assume refers to silently dropping instead of bouncing. I used to get nondelivery notices that were obviously fake, which was their point; they'd be shortly followed by an offer of a fake Windows security patch. If out-of-connection bounces are used for spam in the form of apparent bounces to a degree that providers are often rejecting incoming postconnection bounces as likely spam based on the content of the (often-truncated) original message quoted in the bounce, that's understandable, but, on the other hand, this uniform address wouldn't be an unknown address, it would be a single address set aside for a purpose.
Catch-all addresses don't apply to any address that is taken by a customer or is reserved by a provider for special use, so catchalls aren't in the way.
In response to "[w]ell know[n] addresses tend to create opportunities for DOS", I think that's true only for those addresses, and this one is intended to bounce, thus having little DoS effect that the provider isn't already subject to with addresses such as abuse@ and postmaster@, which are receiving addresses, and unlikely-to-be-open addresses that an attacker can invent for a given provider, such as I did for a single provider (as I described in my first message). In other words, a well-known address does not create an opportunity for DoS against the provider s a whole but does against the address in particular, and since this address is intended to bounce the DoS effect is even less than that of any address at that provider, including a customer's.
"[S]uch an approach would make it easier to evaluate what criterion a system is using to accept mail, which many people obviously are reluctant to do": Only partly true. The kinds of filtering that occur after the name-part is compared to their roster would not be analyzable since bouncing would be required regardless of spam status. But some spam filtering occurs before name-part comparison, and there criteria could be deduced. However, those deductions could be made by sending to any real-looking address at a given provider.
Forging a sender header does risk a DoS attack on the alleged sender, but a solution to that might be to bounce while the connection is open as that ensures the sender being known apart from the header, and perhaps only if the alleged sender matches that determined through the connection. Whether a bounce being intraconnection should be required or recommended is an open question. But if an intraconnection bounce generates a response from the sender's host, that might be less useful than one from the provider's host, possibly obviating the utility of this whole project.
A provider being treated as a spammer for sending bounces probably refers to postconnection bounces, i.e., for bounces sent after a connection had been broken, because forged-header innocent alleged senders then get the bounces for messages they never sent, which become a vehicle for spam.
Bouncing via <example.com>, <user@xxxxxxxxxxxxxxx>, or <nick_levinson@xxxxxxxxxxxxxxxx> is something else. I was proposing that each real email service provider provide an address guaranteed to bounce and I was drawing an analogy to the existence of domains that are set as examples not to be used in the real world. Emailing to example.com or *.example does not offer a realistic picture of what happens at most domains, because these few are such specialized domains, even though there are 3 real IPs registered to example.com (they seem to be run by IANA).
One suggested I write a draft on how to pick an address no one has given to a customer. I did; it's in the initial message on this topic.
Asking an email provider out of the blue if an address is registered with their service is unlikely to work. They're unlikely to tell us. Answering about one takes more labor than filtering spam to one person once. Answering for a whole machine-readable list is likely to raise security concerns at their end unless it's for a good reason, and the original proposal embodied a version of such a procedure, which provides for that reason.
I'm dropping the proposal. If someone else sees enough value in it to pursue the security concerns, including those touched on above and to manage the work of sorting out proposed name-parts, feel free. Thank you very much for considering it this far.
--
Nick
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf