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.