> So you want to change from a ubiquitous protocol that is supported by > many Many MANY devices to niche protocol that has a non-trivial > installation / configuration curve.
1st half is "yes", 2nd half is "no" (mine is simpler). > > then, verify messages by mailing their supplied email a confirmation > > message. > > And then you want to take what people send you, turn around and send > unsolicited messages based on it — this is the icing on the cake — using > the protocol that you are trying to avoid. > > It's only a matter of time before someone uses your Tor hidden service > as a vector to send spam. — Joe Job comes to mind. this was just a quick thought. maybe adding a captcha is enough in the contact-us html submission form. this is not a permanent element. just a temporary solution to get messages from the lagging wold. > > redundant as in containing concepts already done in other protocols, > > so smtp has many re-invented wheels that are already invented in > > existing protocols. > > Please elaborate. Please be careful to provide information about /when/ > the protocols that SMTP is supposedly redundant of were developed. > > I suspect that you will quickly find that SMTP predates the protocols > that you are stating it's redundant of. I further suspect that you will > find that SMTP predates them by 10, or more likely 20, if not 30 years. > > Here's a hint. SMTP was ~82. HTTP (1.0) was ~89. We couldn't post > thing in HTTP 1.0. HTTP 2.0 was ~15. sure, smtp is older, but protocol age is irrelevant. right now http/2 is more developed and much more efficient (e.g. compressed binary, pipelining, single connection multiplexing, encryption by default). even http1.4 was a more efficient replacement. > > imo, smtp should be a much-higher level protocol defined purely on > > top of how dns and http/2. > > How do you get any higher layer than the application layer? it's a matter of definition. if we define http/2 as an application layer protocol, and we define "depends on" as "on layer below", then mail is necessarily above the application layer. anyway, this whole osi/internet model is not accurate and many protocols ignore it. i propose this model (fireball model?): 6. app layer (usual drill..) 5. resource layer (exch. by res.; http/2) 4. socket layer (socke ids; tcp/udp/etc ports) 3. end-to-end layer (inter-lan; e.g. ip) 2. hop layer (intra-lan; e.g. mac addr.) 1. physical layer (electromagnetic fluctuations) http/2 is morphing into general "resource layer" where data is exchanged between difference resources. email is just a special case of this inter-resource communication where some resources are humans. > > e.g. for mail submission, there is no need for a separate > > application-layer protocol as we can simply use http/2. because the > > concept of mail submission is a special case of data submission, > > which is already in http/2. > > HTTP /now/ has a way to submit data. HTTP didn't exist when SMTP was > developed. Further, HTTP didn't have the ability to submit data for a > while. true, but that's history. now http/2 is better for resource exchange than smtp. > If you look at multiple layers of the network stack, HTTP and SMTP are > both at the application layer. Now you are suggesting moving equal > peers so that mail is subservient of / dependent on web? yes. > Does HTTP or the web servers have the ability to queue messages to send > between systems? How many web servers handle routing of incoming > messages to send to other servers? How dynamic is this web server > configuration to allow servers for two people who have never exchanged > email to do so? > > This routing, queuing, and many more features are baked into the email > ecosystem. Features that I find decidedly lacking in the web ecosystem. of course. it's called web application; it can do all fancy queueing and routing you want. basically the only part of current "email system" that is not redundant is the part where it is a "mail web app". every other part (e.g. protocol for data exchange) is redundant and inferior to what exists (e.g. http/2). i am considering to make an uwsgi ptyhon script for my personal use. there is absolutely nothing really challenging about the concept of mail routing and queueing. > > here is a more complete example of what i mean: > > > > 1. we lookup MX records to identify smtp servers to submit mails to. > > 2. from the response to that lookup we get a domain name, say, > > mail.dom.com. > > #1 and 2 are par for what we have today. No improvement. yes. dns is ok for now. i never said dns is redundant. > > 3. then, the standard defines a http/2 request format to submit > > the mail. > > Given how things never die on the Internet, you're going to need both > SMTP /and/ HTTP /on/ /the/ /email/ /server/ to be able to send & receive > email with people on the Internet. no, but that's how most of today's mail servers are. e.g. they have web interfaces and smtp and imap, heck even pop. for backwards compatibility, i may add an smtp client leg that sends my messages to, say, gmail that will in turn deal with the archaic mess. > So you now have a HUGE net negative in that you have the existing > service plus a new service. You're in many ways doubling the exposure > and security risk of email servers. no. at worst (with backwards compatibility), it will be just http/2 and an smtp-client. so basically i'll have only 1 service listening on tcp 443 and that's the web. this is already less protocols than smtp server + imap, where you have multiple listening ports open. > > an example of step (3) could be this: > > > > https://mail.dom.com/from=...&to=...&cc=...\ > > &bcc=...&subject=...&attach1=...&attach2=...\ > > &attachn=... > > If you were to do this, you would NOT do it via GETs with URL > parameters. You would do it as POSTs. yeah, probably. though to be clear, i never said it'll be GET. was more of an example to show the general idea. even talked about possibility of using POST. maybe all headery stuff might be submitted via http/2 as a json file with all fields in. attachments will probably be their own field and be natively binary (no archaic base64 encoding like happens in smtp). > You will also have to find a way to deal with all the aspects of SMTP > and RFC 822 email + mime. I suspect that you will find this to be > extremely tricky. Especially if you try to avoid SMTP / RFC 822 > semantics b/c SMTP is apparently a bad thing. mime is already supported in http/2, no? as for rfc822, it is another archaic mess that needs to be deprecated asap. seen how they store attachments? all in a single text file each file in base64? not sure why i should deal with their mess. for the potential smtp client leg, i can simply tell gmail to auto respond a mail back saying: "sorry, your're talking to me in a deprecated protocol, please repeat what you wanted to say again but this time using either mailball or submit your text in https://vagzgdrh747aei0q.onion"; for the messy side of the world, i can login to protonmail for them. just thinking loudly. i think we're overrating the importance of having a single protocol for all. because we don't communicate with "all". meanwhile, the wrong side of the internet keeps creating new protocols (e.g. snapchat, tiktok, etc). but somehow us, the good ones, are worried to create a new one? i say let the protocol wars begin, and let different communities have different protocols. then let mother nature choose whom to win the darwin award. > How does your example scheme account for the fact that the SMTP envelope > from address frequently diff from the RFC 822 From: header? Remember, > this very feature is used thousands of times per day. So you have to > have it. no need for this feature. it made sense back when we couldn't communicate directly to each other (and they used a different envelope-sender). i see why this feature was appealing decades ago. but i don't know why would anyone need an envelope-sender today. with ipv6 even a fridge has a publically routable address, but somehow we still think we need a separate envelope sender? > There's also many Many MANY other features of SMTP that are also used > thousands of times a day that I'm seeing no evidence of. thousands? they must be wrong. the observed laws of the entire universe is explained in just 17 fundamental particles. but somehow email thinks needs 1000s of features? why would anyone need "thousands" of features to simply talk to another human, or to send him some attachments? if it is 1000s, this by itself a smoke of a bigger problem. > > i don't know how http/2 works. do they have > > POST requests? if so maybe fields attach1, > > attach2, ..., attachn can be submitted as file > > uploads using POST. > > > > further, if we modify steps (1) and (2), we can generalise this > > concept into tor services. e.g. an email address simply becomes an > > onion address. e.g. if vagzgdrh747aei0q.onion is the hidden service > > address of your mail server, then your email address could be written > > as (for convenience): > > > > remco@vagzgdrh747aei0q.onion > > I ... I don't have the words. Go run that idea past an SEO expert. > > Go ask people to drop their domain name in favor of a hash. > > I'm not going to hold my breath. 1st, for those who somehow want a memorable resource address, they can use a domain name as i outlined in the MX example earlier. 2nd, nothing wrong with remco@vagzgdrh747aei0q.onion, this is a fine resource address. the _real_ problem is that people apparently need to learn about the concept called "address book", which they use lookup resource addresses by using friendly names of people. people who insist on friendly human resource address are not much different than those who insist on wanting a memorable ipv6 address. do you ever complain to your isp that your ipv6 is not memorable? no. likewise, no one should really complain about remco@vagzgdrh747aei0q.onion that's what address books are made for. > How are you going to handle the billions of email clients that exist > today, many of which will never be updated, to handle ToR? You're going > to have to have something to gateway old and new. depends. if money comes from them, i'll use normal email for them (then take a long break and isolate in nature to forget what just happened). but if money does not come from them, i'll send them an auto-generated message to use mailball or submit a form using my onion address. > > basically, our public keys become our user identifiers. > > What?! > > Now you are taking away the human friendly name in addition to the > domain name. > > People are going to be lined up to hang you. no. they can put all friendly names in their address books. it's just a fact of life, identification doesn't really happen until you cryptographically sign a message. seeing "from:c...@dom.com" doesn't mean much (a mere meta data). > > on the other hand, people who use mailball will not have this problem. > > why? because ids are public keys anyway, and their messages are > > signed by their private keys (the usual drill, won't insult your > > intelligence). > > So, how will mail(fire)ball prevent me from creating as many key pairs > as I want and sending you a message from each and every one of them? > How does this do anything to prevent spam or viruses? so, communication can be stateful in a sense that replies will be known. then, we can do this elegant fix: 1. if person is replying to you, or to a thread that you initiated a mail to, then his replies to you (or the thread) will gets through. 2. if person, or network, is whitelisted by an exception, they get through. 3. else, person will have to pay some btc fee to the receiver (e.g. me) in order to let the receiver see his message. this will be automated part of the api, including btc fee negotiation. of course the spammer will get prompted "hey user wants 0.0002 btc, mail him about viagra?" this btc part is only fair. we must not be shocked by it. if a person is not passed through (1) and (2), then if he wants to tell me something he needs to pay. it's just a fact of life. this btc solution is very elegant, and must be a normal part of mailing in the future. the fact that we lack it today is just a historical bug because we live in a time when lots of change happened in a short time. > How well does your security hold up when, not if, someone creates a > gateway to make it trivial to send SMTP based email into mail(fire)ball? > It will happen just after mail(fire)ball gets just enough traction > that people scratch the surface to look at it. That is if it doesn't > happen as part of getting enough people Interested. Or even your own > ""API that you are graciously providing. that'd be great. more btc is always nice.
