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