[tyler_larson]

The idea of SMTPing email out from your home ISP turned out to be problematic once spam became a business model. Gmail's not the only place that categorically won't trust it.

You need a mail server. You can run it yourself if you're in to that sort of thing, but you can't run it off a residential/consumer uplink. Sorry, this one's non-negotiable. Then your home server authenticates to your mail server as a client, and send email through your mail server. Your mail server is recorded as the IP address of origin, not your home address. MTAs are already designed to do this with nearly zero effort on your part, so you don't have to change your workflow, just your config file.

Don't want to pay for a mail server? Good news! There's like a gazillion services that actually do this for free. Gmail actually turns out to be one of them. Don't want to have to use Oauth? Good news! Gmail's not the only mail service. There's ten billion others.

[zAy0LfpBZLC8mAC]

> Sorry, this one's non-negotiable.

It totally should be. If you use SPF and DKIM, that should override distrust of IP addresses. If your domain has good reputation and SPF and DKIM prove that you are authorized to send using your domain, then only the reputation of your domain should be considered (and affected) when processing the inbound email.

> Then your home server authenticates to your mail server as a client, and send email through your mail server.

That just overcomplicates things in that you now have to maintain two mail servers. Just set up a tunnel to route the public addresses of your server to your home server, then you can send directly to whereever using static addresses. Also has the advantage that the TLS is terminated on your own hardware, rather than on systems with potentially questionable security of some cheap hosting provider, so less trust in proper security and data protection practices of the hosting provider is required.

> Don't want to pay for a mail server? Good news! There's like a gazillion services that actually do this for free. Gmail actually turns out to be one of them.

Giving power to Google both over your data and over the direction of email in general is not free. That's the one thing everyone should finally grasp. Using Facebook isn't free, using GitHub isn't free, using Gmail isn't free, ...

[zaarn]

>It totally should be. If you use SPF and DKIM, that should override distrust of IP addresses.

There are several IPs that are completely banned on my firewall because they send shitloads of spam over dozens of domains. And some IPs are just inherently not trustworthy (Tor exit nodes, North Korean IPs, etc.)

Everyone can setup a SPF and DKIM record on their domain. It's not hard.

IPs have reputation and you better deal with it because most sysadmins on your receiving end won't deal with any special snowflake configuration.

This isn't exclusive to Gmail, this is basically any mail service and server out there.

[zAy0LfpBZLC8mAC]

> There are several IPs that are completely banned on my firewall because they send shitloads of spam over dozens of domains.

I understand that that is the case. I said that it shouldn't be the case and why. So, what's your point?

> And some IPs are just inherently not trustworthy (Tor exit nodes, North Korean IPs, etc.)

Noone is saying you should be trusting those IPs. I said domain trust should override IP distrust. So, again, what is your point?

> Everyone can setup a SPF and DKIM record on their domain. It's not hard.

Which is obviously the premise of using them to override IP distrust? So ... what is your point?

> IPs have reputation and you better deal with it because most sysadmins on your receiving end won't deal with any special snowflake configuration.

I think I wouldn't write "It totally should be" if that were the current reality, would I? So ... what is your point in explaining what I am obviously aware of?

Also, you might be surprised, but "special snowflake configuration" is how every change starts. So, if your argument were to be taken seriously, we should never have introduced SPF, because the first person to use SPF had a very special snowflake configuration indeed.

> This isn't exclusive to Gmail, this is basically any mail service and server out there.

Erm, yeah, thanks for repeating half a dozen times the obvious premise of my comment.

[zaarn]

>Noone is saying you should be trusting those IPs. I said domain trust should override IP distrust.

I don't trust certain IPs. Why should the presence of a SPF or DKIM override my trust of these IPs? If that is the case, why should it be for any other IP?

>Which is obviously the premise of using them to override IP distrust?

Which is my premise for why having them override IP trust is completely useless. There is nothing involved in the process of setting up SPF or DKIM that would make me trust a domain if the IP is not trusted.

[zAy0LfpBZLC8mAC]

Nothing about the presence of SPF or DKIM should override distrust of an IP, just as the presence of an IP shouldn't override distrust of a domain, that's simply confusing different functions. Neither SPF nor DKIM nor IP provide trust, what they provide is identity. Identity is the basis for reputation. And reputation is the basis for trust.

When you use IP blocklists, say, you are effectively using a reputation database that maps an identity (a client's IP address) to a reputation score that heuristically reflects how well the owner of that address space has guarded the address against use by spammers.

Equally, you can have a database of reputation scores for domains that reflect how well the owner of that domain has guarded the domain against use by spammers.

So, the existence of an authenticated domain identity, as established through SPF or DKIM, should override the IP address identity as the basis for determining the reputation of the sender. The identity alone never provides trust, it is only the key for looking up reputation in some database to base your trust on, and to store any reputation feedback under (like, when an email is marked as spam by the recipient). If your database says that my domain is trustworthy, then you should accept emails from that domain even if they come from a tor exit node, and if you determine that it is spam after all, that should lower the reputation score of the domain, not of the tor exit node.

[zaarn]

>If your database says that my domain is trustworthy, then you should accept emails from that domain even if they come from a tor exit node, and if you determine that it is spam after all, that should lower the reputation score of the domain, not of the tor exit node.

How would you establish trust in your domain from a tor exit node?

Home connections that send email are 99.9% of the time involved in a spam sending botnet. Those IPs are almost always entirely distrusted.

So you can't build trust into your domain without getting a both a trusted domain on a trusted TLD on a trusted IP.

The identity issue is not of concern since there is no good way to tell if the IP of a domain's mail server changed to a tor exit node because it was compromised, sold or otherwise maliciously claimed or if the owner legitimately did it. Lots of people will therefore treat changing the endpoint for mail as a new identity (for good reason).

>Equally, you can have a database of reputation scores for domains that reflect how well the owner of that domain has guarded the domain against use by spammers.

This already exists, multiple domains. Any spam blacklist operates via such reputation scores. It's utter pain to get your reputation fixed on these once you're in bad standing.

These go for both IPs and Domains. SPF and DKIM are a great way of avoiding trashing your reputation because some spammer is sending under your domain. But we already have tools for reputation.

If you build an IP reputation database, you'll quickly find out that Home IPs will get trash reputation regardless of if you think they should be allowed to send anything. (That's not even mentioning that Home IPs aren't stable)

[xg15]

> Then your home server authenticates to your mail server as a client, and send email through your mail server.

But then, why can't I do that with Git?

[xte]

Mh, because cars are about moving on roads and boats on water?

Git is a dCVS, so a software to store source code tracking history and users, not a communication platform, mails on contrary are communication platform.

If you want something like Fossil (dVCS with built-in webserver with a mini-site for bugtracking etc) integrated with something like ZeroNet well, we do not have anything like than and yes, it can be an interested thing, far more interested than IPFS monsters etc.