Hacker News new | past | comments | ask | show | jobs | submit login
The demise of email forwarding is getting closer (tidbits.com)
70 points by kruuuder 67 days ago | hide | past | favorite | 32 comments

From https://support.google.com/a/answer/14229414#zippy=%2Cwhat-i...


Starting February 1, 2024, all email senders who send email to Gmail accounts must meet the requirements in this section.

- Set up SPF or DKIM email authentication for your sending domains.

- Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records.

- Use a TLS connection for transmitting email. For steps to set up TLS in Google Workspace, visit Require a secure connection for email.

- Keep spam rates reported in Postmaster Tools below 0.3%. Learn more about spam rates

- Format messages according to the Internet Message Format standard, RFC 5322.

- Don’t impersonate Gmail From: headers. Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery.

- If you manage a forwarding service, including mailing lists or inbound gateways, add ARC headers to outgoing email. ARC headers indicate the message was forwarded and identify you as the forwarder. Mailing list senders should also add a List-id: header, which specifies the mailing list, to outgoing messages.

I was under the impression this is what Authenticated Received Chain (ARC) was created to solve:

> Authenticated Received Chain (ARC) is an email authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.[1]

* https://en.wikipedia.org/wiki/Authenticated_Received_Chain

It's how mailing lists are able to keep the original sender's From: header in the messages delivered to members.

ARC is more like a chain of custody than a security feature, unless you are very strict about it (which can cause breakage at scale).

Plus ARC isn't deployed everywhere yet. Large providers tend to do it, but sometimes older established email servers (like in academic institutions) may not be on the cutting edge due to smaller budgets and different use cases.

So to clarify, "forwarding" here only refers to full automatic forwarding of one address to another, not manual Fw: right? I can't imagine they'd break the latter

“Forwarding” here almost certainly refers to the From: header in the email. If I receive an email at my personal gmail address with “From: noreply @mybank.com” that was sent to me by “myuniversity.edu”, gmail will start to mark that email as nondeliverable because the message “claims” to come from the bank. But this might be a normal setup. Perhaps my bank has my university email address, and my university mail server is configured to pass the email along.

Clicking the forward button merely copies the email body into a new message appearing to come “From:” your personal email address, so there isn’t an issue with that. Doing this doesn’t preserve headers however.

> only refers to full automatic forwarding of one address to another

Yes, that is correct. In my job I started referring to this as 'relaying', to prevent confusion with forwarding (Fw:) from an email client.

In more technical terms: in the article they are talking about forwarding on the MTA level, not the MUA level.

"The big email services, gmail, yahoo, outlook and apple, are going to start tightening the thumbscrews (strict SPF, DMARK and DKIM, but also other stuff) on April 1"

why this coordinated change? I don't understand the root cause?

It seems like this might affect a large swath of normal people.

Now just a huge coincidence, but this would also lock people into big email providers.

It's important to note that this change impacts only the kind of forwarding, where the sender doesn't change.

That's different than pressing the "forward" button in your email client, where the email is not being forwarded from your intermediary mailbox.

In the first case, you're practically impersonating the original sender, which you're typically not authorized to do so. This is also what scammers do to trick people into believing a higher authority authorized a payment to a malicious entity.

In the latter you're just sending an email that contains the original email. The difference here is that the recipient doesn't see the original sender immediately, but has to look in the attached email, or into the email history to find this out.

So, to answer your question, this change is being made to make it harder for scammers to scam people.

Just speculating: To increase acceptance. If they all make an unpopular change at once no company can be singled out to be the bogeyman.

Will use of Sender Rewriting Scheme (SRS) be affected?


I forward a handful of email addresses from my domains to gmail, this has worked for years, and I did set up SRS a couple of years ago to solve bouncing emails.

As far as I can make out, SRS is actually the solution to the forwarding problem that the linked article is complaining about. Yes, it is a pain to setup, but it is quite doable.

I also forward email sent to my domain to gmail.

To expand on why forwarding is common and important in academia, as the IT department explanations in that thread seem to misrepresent how people actually use forwarding: email is arguably the primary form of communication in academia, and important parts of academic practice assume that an address will continue to reach someone, in some way, in perpetuity.

Journals often put email addresses directly in text, even printed text, as the only direct contact information for authors. Scholarly conversations and collaborations often involve emailing people you vaguely know, and might not have emailed for a few years, but you probably have an address for them in your address book or some old emails. Contacting reviewers, or potential committee members for conferences, often involves discussing and cutting and pasting lists of names and email addresses. Unlike in business, in academia people often move between institutions, sometimes on the time scale of a year, while being in the same field, doing the same work, and often working with the same people. They usually want to keep receiving the same emails, and being on the same mailing lists, too.

The way this has typically been handled is through email forwarding: there was the understanding that, at least above a student level, you would continue to be able to forward your email address after you left for as long as you wanted, quite often the rest of your life. People would usually forward from their former institutional email addresses, not personal ones, to either their current institution, or a personal account they used to centralize everything. Thus, people could contact them with whatever old university email address they had, and they could reply with their current email address.

Unfortunately, university IT departments have started to ignore how academic practice differs from corporate practice, and now tend to bring in policies that fit business but not academia (another is the mangling of 'external' emails: most of the important emails we receive are from academics at other institutions). As far as I can tell, my current university essentially treats emails the way a business would, and I'll lose access the moment I decide to leave. They even try to change email addresses over time for people who work with us in changing contexts, without allowing forwarding (student to postdoc, intern to student, etc).

My personal practice is that I will not publish any institutional address unless the institution can give me assurances that my email address will continue to work indefinitely. Sometimes that means I'm listed with a personal address, or an email address for a different institution. Sometimes they are printed in important contexts, and it does look awkward. But that's more an awkwardness for the institution, and I need to be able to ensure that I actually receive emails.

That shift probably happened at the same time when uni IT departments started renting their email from Microsoft / Google who are billing by number of users.

When you have your own server the marginal cost for a forwarding inbox is zero.

It does seem largely related to that, and it is both frustrating and confusing as to why Google and Microsoft have not developed features and plans that consider these problems, despite so heavily pushing their services to universities.

Just yesterday I had several emails back and forth with a student at another university who needed my help with some research software of mine where she eventually realized that, as a student, she simply wasn't allowed to share Google Docs outside her university at all; she had to switch to her personal account. This is on a project her university is funding. And yes, their IT could configure it differently, but so often, the defaults don't fit academia.

I think because MS and others are approached by Universities because of things they promise businesses.

For example: A rather large University in town got hacked. They ran their own infra till then and, as it happens, caught on of the "give me money or your infra is dead" things. Afterwards a lot of not so tech and security savvy folks that where in charge of handling the rebuild and aftermath where eager to shift the blame and damage in the future - especially since said town is located in a GDPR country. In comes MS and gives the same promise as to every other entity: "Buy us and never worry about accrediting your own infra or software solutions. Also conveniently point to us when shit happens".

Edit: wording

This is why you see so many grad students and early career faculty with their own domains. Which is a reputational hit on departments against their will.

>Which is a reputational hit on departments against their will.

It really is. I have a recent Nature paper where, as the result of the email problem, a reader could easily think I'm actually more connected to a different university. I expect the administration, and publicity people, are not happy about it. But IT won't change their policies, and I'm not going to put an ephemeral email address on a permanent publication.

> But that's more an awkwardness for the institution, and I need to be able to ensure that I actually receive emails

Very well said. Institutions that only issue ephemeral email addresses cannot reasonably expect such addresses to be included in publications.

ORCID (Open Researcher and Contributor ID) identifiers are an attempt to resolve this. https://en.wikipedia.org/wiki/ORCID

> Can I continue to forward my email to my university address [which then forwards to my personal address]?

What is the usecase to have the university address middleman instead of forwarding directly to the personal? And what would the first forwarder in that chain be, since its not the sender (it says forward, not send)?

Prestige and permanence.

Pre-Gmail/Hotmail, you lost your ISP-based email address if you ended your subscription (AOL, Earthlink, etc) or moved (Time Warner Cable, Southwestern Bell, etc). University addresses were promised "for life."

Know of any Uni addresses that were promised for life but no longer are?

The for-life email address was typically a perk given to people who were affiliated with a university when internet was still fairly young (think late 80s and 90s). This was a nice perk, because web-mail was not as common and advanced as it is today. And outside web-mail, email addresses were generally very volatile.

The main reason universities couldn't keep doing this is that they eventually ran out of email addresses. Some may have tried to continue the practice, by adding e.g. some university-specific id to the email address. But this makes the email address much less desirable for using after your graduation. In the meantime, web-mail offerings had become arguably more advanced than whatever the university offered. So it made sense to just discontinue the practice altogether.

I was in the "lucky" batch that got a for-life email address. But it was still an opt-in feature. I.e. when the university decided that the email naming scheme was not sustainable, it asked all alumni if they would be interested to keep their forwarding address or not. Many had already dissociated themselves enough with the university to not take the offer.

At least a few in the UK that I’m aware of (I'd say which ones but I don't really want to dox myself).

University of Western Australia is one.

while hiring, I've seen plenty of devs continue to put their ivy league email address on their CV years after completing their degree.

one in particular iirc was using an MIT email over a decade after attending but had never completed more than a year of undergrad there.

> “This is a common set up, so alumni and retirees can keep receiving mail to their university address, even though they no longer have accounts and can’t send from that address.”

Dammit. So I won’t be able to send and receive my personal domain emails through gmail anymore…?

The article is misleading. You can just implement SRS on your personal domain and it will work just fine. See https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme for an overview of how it works.

Will this affect a catch-all forward on a domain? I own a bunch of domains and have them set so that any email sent to any address at those domains goes to my gmail account. If this stops working I will be in trouble.

Yes, I’ve seen deliverability of forwarded email to gmail drop dramatically recently.

Forwarding traditionally looked like this:

1. I tell my email client from colimbarna@fine.server.example to send an email to eisenstein@old.server.example using my.correctly.configured.smtp.server.example

2. my.correctly.configured.smtp.server.example looks up the records for old.server.example and contacts the SMTP server that is sitting there.

3. old.server.example accepts the email and checks its rules for what to do with it: and it is supposed to forward it to eisenstein@new.server.example.

4. old.server.example looks up the records for new.server.example and contacts the SMTP server that is sitting there. It forwards the email basically unchanged - this isn't something where it's from:eisenstein@old.server.example to:eisenstein@new.server.example subject: Fwd - old subject, it's just saying "here's an email to eisenstein@old.server.example, please deliver it to eisenstein@new.server.example". Remember that the "to" address isn't necessarily the person the email is getting delivered to, because you might be in a cc or even bcc list.

5. new.server.examples accepts the email and checks its rules for what to do with it: and it supposed to put it into eisenstein's inbox.

The change here is to steps 3 and 5: "server accepts the email". Instead of simply accepting the email, the SMTP server will checks to make sure that the server which is sending the email is allowed to send the email on behalf of that email address.

So in step 3, old.server.example will check to make sure that my.correctly.configured.smtp.server.example is allowed to send emails on behalf of fine.server.example. It will see that it is, and the email will continue.

But then in step 5, new.server.example will check to make sure that old.server.example is allowed to send emails on behalf of fine.server.example. And it will see that it is not, and it won't accept the email.

Now, your situation is probably different. Instead of steps 3-5, you probably have gmail checking to make sure the sender is allowed to send the email, and if so it checks its rules for what to do with it: and it is supposed to put it into eisenstein's inbox. It's not actually forwarded, it's just that there's more than one email address that gets delivered into the one inbox. (This assumes you have your domain correctly configured for delivery to a gmail address. It's worth double checking, especially if you set it up longer ago than you care to remember.)

Well shit.

Pretty much all of my email addresses are forwarded one way or another to my "main" inbox.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact