The demise of email forwarding is getting closer
talk.tidbits.com
talk.tidbits.com
----------------------
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.
> 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.
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.
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.
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.
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.
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.
https://www.linode.com/community/questions/11438/solved-low-...
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.
I also forward email sent to my domain to gmail.
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.
When you have your own server the marginal cost for a forwarding inbox is zero.
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.
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
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.
Very well said. Institutions that only issue ephemeral email addresses cannot reasonably expect such addresses to be included in publications.
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)?
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."
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.
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.
Dammit. So I won’t be able to send and receive my personal domain emails through gmail anymore…?
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.)
Pretty much all of my email addresses are forwarded one way or another to my "main" inbox.