Vernon Schryver wrote:
If the envelope sender was forged as is common in spam, universal in
worms, and practically nonexistent in legitimate mail, then your bounce
will afflict third party's mailbox. My mailbox receives enough worm
bounces to make me say it is an awfully bad thing.
Yes. However, if your mailbox could automatically handle confirmation
requests based on messages that were actually sent by you (in much
the same way that NAT boxes work -- you only get a reply to a request
you send), then you would not be bothered by the C-R traffic at all.
The only fix is to have your external MX servers know all valid
addresses and so reject junk before it can be accepted and later
need to be bounced. That fix is often impractical or impolitic.
Yes, also because "all valid addresses" is a dynamic list.
No, SPF, RMX, TOES, etc. etc. etc. cannot fix this problem unless you
assume frictions (deployment resistence and delays) do not exist
or you discard SMTP design goals including transporting messages among
complete strangers.
Messages among complete strangers is a necessary feature, IMO, but
shouldn't it behave in cyberspace as we learned to do it in the
social space? Trust is earned. When a complete stranger calls me,
I usually ask who or what introduced me to him before I start any
conversation. If the complete stranger has no satisfactory answer,
I ask him to take me off his database and not call again.
People who know each other's crypto keys are not strangers.
It is possible for my MUA to automatically provide a complete stranger
with my PK if I receive an email from him. The barrier to have my
crypto keys does not have to be any higher than the barrier to have
my email address.
If you could someday trust organizations to vouch for strangers and
not sell spam-for-a-day certs to Ralsky/Ricther/&co, then today you
could trust the same outfits to not sell spam-for-a-day/week/years IP
bandwidth accounts.
Yes. TTPs cannot be trusted per se. The answer is not PKI as we know it.