6 ms·
Sounds like the big claim here is that it is faster. That's definitely a good thing, but what I want is a protocol where: 1. Every time I give out my email ad
by gcanyon 3y ago
Sounds like the big claim here is that it is faster. That's definitely a good thing, but what I want is a protocol where:
1. Every time I give out my email address, behind the scenes a single-source permission/token is created.
2. Thus, that one source is able to send me email, from the email address they specified at the time.
3. But if they hand over the permission/token to anyone else, email from that new source will automatically bounce/be marked as suspect/flagged (my choice in configuration).
4. Even if the original authorized party tries to email me from a different address at the same domain, that email will be handled as in (3).
5. Even from the same email address, the configuration can specify limits, e.g. only 5 emails total, only 3 per week, expire after 10 days, etc. Again, configurable.
Oh, and 6. Of course this means unsubscription becomes a local configuration thing that doesn't require the sender's participation.
I know current email protocols allow none of that, but if we're proposing new protocols, that's what I want out of it. Faster is better too.
- Hooray_Darakian 3y ago> Every time I give out my email address, behind the scenes a single-source permission/token is created. 2. Thus, that one source is able to send me email, from the email address they specified at the time. 3. But if they hand over the permission/token to anyone else, email from that new source will automatically bounce/be marked as suspect/flagged (my choice in configuration). Do you mean hand out in a digital sense or on a business card? I'm not sure you can support the business card use case if you implement that.
- all2 3y agoI assume that business cards would have a unique email/end point to allow for this case, kind of like how gmail and others allow you to add +<stuff> to the end of your email address. So you'd have a set of "business card" emails + rules that would allow only the first sender to send emails to that address (for example).
- jrky 3y ago>So you'd have a set of "business card" emails + rules that would allow only the first sender to send emails to that address (for example). Simple but genius! I love it :-)
- gcanyon 3y agoYep -- I wasn't thinking of business cards for this, but something like this would be required I think.
- mminer237 3y agoSo each business card would have to be unique with a unique address? I feel like it is generally considered unprofessional to have an email address with random letters in it, not to mention, you'd need a special business card printer to handle that.
- gcanyon 3y agoI think yes, this would be required. An email address with random characters in it for no reason would certainly be questionable, but if the use case I'm proposing becomes at all known it would be much more understandable I think.
- ivan_gammel 3y agoThe email address can be user-friendly, but card can also include an unique code similar to product serial numbers, that is redeemed with the first message. E.g. „Max Mustermann“ <ABCD-1234-XYZW|max@musterfirma.de> is a valid email address with unique code part.
- gcanyon 3y agoMore digital -- I haven't had business cards in ages. But even in a card case it should be possible to: 1. print cards with a unique token/whatever on each card (I get that this isn't the same as old school cards that have to be identical) 2. limit any given token to 3 uses (or similar)
- Hooray_Darakian 3y agoI think the more practical issue is that if each business card has its own single use token then your printer is doing one copy of each card. Doable, but not how any business card company is setup today. I do get the desire for this sort of thing, but I also think most users of email treat an address as a static entity.
- Spivak 3y agoSounds like you want email to work basically 1-1 with OAuth where you authorize the sender the way you would grant access to your Google/Spotify account. I would actually love this flow and you get OpenID style SSO for free. Could be the actual password killer.
- ghayes 3y agoThis is a little confusing since it’s not just an access token (or refresh token) since the OP wants to verify that the sender is the correct sender, not just that they have access to the token. Otherwise a token holder could simply pass the token to spammers, still. This is harder since the sender could share his or her sender key, so you’d have to disincentive that, but doing so it going to make the system even more complex.
- gpvos 3y agoYou don't have to go very far with extra checks and disincentives, as the recipient can also invalidate the token at the first sign of spam. SPF/DKIM or an equivalent can also help with sender authentication.
- Spivak 3y agoI think the idea is that OAuth token would allow sending emails as a specific sender, like if I allow say Lyft to send me emails in this flow and they pass the key to spammers the emails will appear to come with Lyft.
- ilyt 3y agoI actually loved XMPP/Jabber flow where sender first need your permission to get added to the contact list and get their messages thru. Still can be spammed but without any meaningful content at least.
- __MatrixMan__ 3y agoYour vision is further than fastmail can currently take you, but a partial solution which I use is to just give out a unique email address to each company. that way when you get spam you can disable that address for future use and also use it as a conversation starter with whoever leaked your data to a spammer. The format I use is {yourname}@{myname}.{mydomain}, so there's a unique address for every pair--some of which I've disabled delivery for.
- gcanyon 3y agoDo you have the system automated? Meaning: if I send email right now to {somerandomstring}@{yourname}.{yourdomain} does it get automatically rejected, or flagged? And if yes, how do you add {myname} to your whitelist?
- vidarh 3y agoBoth Gmail and Fastmail supports "+something" in the local part of your email address, so you can just add a foo+*@domain filter to block everything or move it to a folder, and then add a foo+someapprovedsender@domain filter before it for anyone you want to reach your inbox.
- davchana 3y agoAlmost every provider (social media, banks, websites and spammers) also know this, and routinely remove anything after + in @gmail addresses. Indian Retirement Fund website, NPS, government operated, will take your abc+nps@gmail.com at signup, no errors, but will not let you login saying, Email Not Found. You have to login with abc@gmail.com to get in your account.
- lilyball 3y agoFastmail supports both yourname+foo@example.com and foo@yourname.example.com. I use the latter precisely to avoid the problem of sites that don't play well with plus addresses.
- 3y ago
- vidarh 3y agoYour best bet for something like is simply to set up catchall rule to move everything not already shunted elsewhere to a "staging" folder, and then use a script to apply whatever advanced filtering you want that your provider cant and move anything that should be allowed past to your inbox.
- pravus 3y agoI had a similar idea to this and wanted to add a couple of more features. It essentially is policy-based email so I thought: * Every cert is put into a trust classification that can dictate a default policy * Policy items could include things such as rate limits, message sizes, spam filter weights, etc. * Identities can be tied to multiple certs to allow for different modes of communication when desired * Allow for a trust classification labeled as "public" that is the default classification (with strict limits by default) * Make common mail items first class objects and allow URLs (e.g. attachments are no longer inline but must be a URL with metadata that can be verified before my system is willing to pull it on my schedule). I have other ideas as well; This is something I've been thinking about a lot lately. One other feature that would be nice is if you could somehow link it up to SMTP gateways. I realize that sort of defeats the purpose, but that would accelerate adoption of any new technology since it has so much gravity. Anyway, just ideas for now...
- gcanyon 3y agoNice! If there were a reasonable path to get from here to there, I'd say we should share a google doc to firm up the definition/requirements. But since (as far as I know) there is zero chance of something like this working, we'd both be wasting (more of) our time :-(
- grepfru_it 3y agoI think this would work, question is what’s the market and does the product fit? If there’s a (potential) user base I’ll jump in a build with ya!
- gcanyon 3y agoI think the market is: 1. anyone who wants a clean inbox -- maybe less profitable 2. any company that wants better protection against phishing attacks -- maybe more profitable 3. Edit to add: someone pointed to https://www.mailinblack.com/ I don't speak French, but that's apparently a company that (somehow) provides a service similar to the description here to high-profile targets. If the skateboard version of this seems technically do-able without having to convince the entire world to switch to a new protocol I'd be happy to jump into a google doc to noodle it further. On the surface it seems like: 1. it would have to rely on email addresses alone -- I don't know another way to transmit information from sender to receiver that fits within current "what's your email?" standards. 2. it would have to have a sparse enough address space that accidental collisions are unlikely -- so maybe 8 alphanumerics for ~41 bits? But if you have other ideas I'd love to hear them -- griping about email has been a thing of mine for 20 years...
- nashashmi 3y agoI guess there is a hack that can work on current systems but it is less seamless to setup. The '+' symbol combined with a 10 char UUID can be used to filter
- plq 3y ago> Every time I give out my email address, behind the scenes a single-source permission/token is created. How would this work exactly? You send the token to the recipient's email address? Doesn't that become a chicken/egg problem because the recipient could very well have the same requirement?
- ilyt 3y agoThat's why he wrote it is probably not possible. Per-recipient email is probably best you can get
- gcanyon 3y agoUnder current email protocols, 100% agreed. If we get to define our own RFC from scratch then much more of this becomes possible under a single email.
- gcanyon 3y agoExactly what the other replier said -- with current protocols almost certainly not possible, and even with complete access to *@mydomain.com it would likely be a serious hack, brittle in many ways, and not robust in others. But with a new protocol underlying, I could see this all being handled automatically. (maybe -- I haven't walked through this with a technical person).
- yobbo 3y agoSounds functionally equivalent to a whitelist of domains you accept from?
- gcanyon 3y agoWith much more specificity and control, and automatic.
- chmike 3y agoThere is a french company named mailinblack [1] that does this. They protect administrations in this way. [1] https://www.mailinblack.com/ https://www.mailinblack.com/
- throw0101b 3y ago> Sounds like the big claim here is that it is faster. IMAP worked over 2400 bps modem connections; we now have multi-megabit connections. How much faster is JMAP over IMAP and what makes it faster?
- gcanyon 3y agoIn their demo video they show an inbox rendering much more quickly, but don't give specifics, so ¯\_(ツ)_/¯
- ilyt 3y agoThe simplest hack I can think of is: * Making a wildcard email address for domain, say @example.com making a filter that only allows sourcedomain@example.com (or user_sourcedomain@example.com) to accept mails from @sourcedomain Could replace it with hash in second part hashing whole sender's address with some secret but that might be annoying if you have to tell the email via phone and now it needs to be generated manually But > 4. Even if the original authorized party tries to email me from a different address at the same domain, that email will be handled as in (3). 5 Would likely bite you HARD as it isn't too uncommon practice to respond from other email if say you are contacting some generic alias (contact@) but get answer from (john.doe@) that handles your case.
- gcanyon 3y agoYeah, I abbreviated the spec. If I were putting together a full requirements doc for this feature, it would have to include different levels/types of filtering. So e.g. if I registered my email with signup@walmart.com and then received email from noreply@walmart.com, that wouldn't receive the same sort of blackholing as an email using the same token but from *@sospammy.com
- ilyt 3y agoIf it was new protocol the XMPP approach would most likely be saner. Which is "if I don't put it on my contact list you ain't getting thru". The invite spam is far easier to handle than message spam.
- danielheath 3y agoI'm on fastmail. 1 and 6 are a feature they offer (I use it). In place of automation for features 2-5 - anytime I feel an address is misused, I add a rule that forwards messages to trash (or spam, for egregious offenders).
- gcanyon 3y agoCan you describe (or point me to the docs) how 1 works? Do they generate custom email address extensions, or...?
- danielheath 3y agohttps://www.fastmail.help/hc/en-us/articles/1500000277942-Catch-all-Wildcard-addresses https://www.fastmail.help/hc/en-us/articles/1500000277942-Ca...