freedomPusher

Just a tip, if you want to report this one in place that has a chance at being seen or forwarded into github, gaupol happens to be in the official Debian repos. So there is a debian bug tracker db which takes submissions via email, and there is also an Ubuntu bug db for it on Launchpad.

Take that with a grain of salt though, especially if you don’t test it on debian or ubuntu before submission. Some Debian maintainers are willing to mirror the report upstream but most will ask you to do that (which you can refuse). Technically, the Debian rules favor upstream reports to be made to debian, but many maintainers ignore that guidance. Ubuntu maintainers tend to be less active. They won’t complain about upstream bug reports but at the same time the reports there tend to just sit idle AFAICT.

Gmail doesn’t care what the FROM field address is. It can be entirely unrelated to the sending server and can be complete gibberish nonsense. MS did not care either back when MS did not consider dynamic IPs blacklisted. Now that MS wholly rejects dynamic IPs I’m not interested in retesting that anyway.

Even from a narrow purely infosec-privacy PoV, how can people be so clueless this day in age with the fully enshitified web?

It’s not going to be a simple text email with your receipt attached. The email will be HTML with a tracker pixel (text MIME part broken or generally non-existent), so the seller can log the fact that you read the receipt, when, and with what IP address. Then when you get the email open, it won’t even contain the receipt because it will be used as an opportunity to get you on their website where they can get more sales. It will say “come to our website and pick up your receipt”. When you try to visit the site with the unique URL they send, Tor will be blocked (under the guise of “security” but in reality they want your browser print and IP again in case you used a text-only MUA). This will give them what makes it trivial to link your online identity to your offline purchase (cha-ching.. mo money). Then a Google Plastore-only non-FOSS app will be shoved in your face as a more convenient way to fetch your receipts in the future. You will have to solve a CAPTCHA to reach your receipt, which generates more profit for them while steering people toward a shitty app.

It will be like London Heathrow or JFK airport, where you cannot simply walk to your gate without being long-hauled through a series of marketing opportunities.

And before you irrationally call this “paranoia” as well, I will preempt that by saying no, it’s capitalism. Which brings us the enshitified web.

NFC would encourage phone upgrading which is worse for the environment than the problem they think they are solving. Paper is biodegradable. Phones are not.

Android 2.3+¹ supports bluetooth file transfers. This would avoid both the problem of using cloud energy and privacy problem (but only for smartphone owners who carry their smartphones). The article mentioned PDF being rejected. PNG could work, though it’d be a missed opportunity to get a digitally signed receipt. In any case, the paper receipt cannot be wholly replaced if it requires consumers to have a phone and to carry it, or if it requires sharing email addresses.

¹ maybe even AOS 1.8.. didn’t check

Privacy is about control.

You don’t understand privacy given your conflation with paranoia and oversight of my mention of a boycott. Privacy is not just about non-disclosure of sensitive information. It’s much more than infosec.

When you mislabel privacy as “paranoia”, you become part of the problem of advocating disempowerment of people in favor of control misappropriation.

If you don’t want to receive emails from servers belonging to Microsoft, Google, or Amazon, you better delete your mail account and ask them to mail you the receipt.

This absurd attempt at a false dichotomy showcases contempt for individuals having power to boycott selectively. What you suggest is wholly disempowering to people -- to claim this all or nothing narrative.. that people should either not have email access at all, or they should have zero control over who they connect with over email. Your stance represents a boot-licking wet dream for corporations and governments. It has no place in any privacy community.

I’m fine with all that. I’ve mostly abandoned #email anyway because I do not accept the terms Google has imposed on the world. I send most messages by postal mail when recipients have only exclusive and restrictive receiving options.

The inability of the recipient to reply to an onion address using their normal service is actually part of the idea. I would not want a gmail user to be able to use gmail to reply, for example. While Google drags people into their walled garden, I’m happy to exert pressure in the opposite direction.

(edit)
If I were to send a msg to gmail user in a way that they could simply reply from Google, then I become part of the problem by reinforcing the use of Gmail and helping Google get fed. That’s not going to happen. It’s a non-starter.

That is 100% what im saying, yes.

Okay, so AFAICT you’ve not said anything that prevents individual users from using an onion FROM address, so long as the sending server is authorized via all the shitty spf, dkim, dmarc, dane hoops. This is what I’m after. In fact, I’m even less demanding. I don’t care if a service provider doesn’t bother with dkim and gets rejected by some servers. Email is in such a broken state anyway.. I just need the option to set the FROM field to an onion address. The reason my own server is insufficient is the residential IP is very widely rejected.

I’m not surprised. Google took an anti-RFC posture when they broke email and brought in their own rules under the guise of anti-spam (the real reason is domination). The whole point of RFCs existence is interoperability. That was broken when servers reject RFC-compliant messages.

I’m not interested in bending over backwards to accommodate. Satisfying Google’s dkim reqs requires the server admin to solve a CAPTCHA. That’s a line I personally will not cross. So at the moment I simply do not email gmail users (or MS Outlook users, same problem).

The server is checking that the EHLO domain matches that of the IP of the sending server. Whatever is in the FROM: field is entirely irrelevant to that. The RFC even allows multiple email addresses in the FROM field. It’s rarely practiced, but it’s compliant. So if you have FROM: bob@abc.com, bob@xyz.onion, bob@xyz.org, are you saying the receiving server would expect the domain of all FROM addresses to match that of the sending server? What happens when a sender has a gmail account but uses a vanity address? Instead of bob@gmail.com, he has bobswidgets@expertcorp.com. Are you saying expertcorp.com ≠ gmail.com, so the receiving server will reject it? I think not. Google offers the ability of their users to use an external address last time I checked.

If you monitor IRC channels on email servers, you’ll find there are plenty of email admins unwilling to even go through the dkim and dmarc hoops. An fqdn check not on the sending server but on the FROM field of a msg is over-zealously above and beyond dkim and dmarc. I’m quite fine with not reaching these fringe servers. I can always decide from the bounce msg whether it’s worth my effort to dignify their excessive hoops with a transmission to their persnickety liking.

How do you expect to receive replies from clearnet users, or are you okay not receiving replies?

Indeed that’s the idea. If you’ve ever received a message where the sender’s address is “noreply@corp.xyz”, it’s similar. But in fact the onion address is slightly more useful than a “noreply” address because the responder would at least have the option of registering with an onion-capable email server to reply.

Imagine you want to email a gmail user. You can ensure that the message contains nothing you don’t mind sharing with a surveillance advertiser, but you cannot generally control what gets shared in the response. An onion address ensures that replies will be outside of Google’s walled garden, for example. That’s just one of several use cases.

Also most mail hosts these days toss emails that dont match dmarc/dkim/spf, which would be especially hard to do for an onion email

Those are server to server authentication protocols, not something that validates the functionality of a sender’s disclosed email address. Otherwise how would a bank send an announcement from a “noreply” address?

Do you know who does care? The email server you’re sending messages to, because spammers and scammers love to try and send email with fake from addresses.

The receiving servers do not generally care what’s in the FROM field. They care that the sending server they are connected to is authorized and has their SPF, DKIM, and DMARC shit together. It’s not for the receiving server to control the email aliases of individual senders. Some rare over-zealous servers will look at the FROM field and expect the domain to match but if I encounter that, the collateral damage is what it is. I can always still decide from there whether it’s worthwhile to go through extra hoops.