If you're struggling to secure email forwarding, it's not you, it's ... the protocols

Over the past two decades, efforts have been made to make email more secure. Alas, defensive protocols implemented during this period, such as SPF, DKIM, and DMARC, remain unable to deal with the complexity of email forwarding and differing standards, a study has concluded. In a preprint paper titled, "Forward Pass: On the …

[Fazal Majid]

It’s Outlook’s fault

Basically Outlook allowing an account unrelated to state.gov to launder forwarded email using an allowlist is the issue, but like GMail they are too big to fail and can get away with gross insecurity like this.

Securing email is pretty much impossible due to all the legacy and a fool’s errand.

[Anonymous Coward]

Re: It’s Outlook’s fault

Actually, securing email IS possible, but it depends on the reach you want that trust to have. In a company? Easy. In a government? Done (there are more around the world). In a whole country? Harder, but that too has been done.

On a global scale? Good luck trying to change the protocols and no, PGP is only half the answer.

If you can stay in a managed container you'll be OK. Step outside it and profit trumps any decent security measure as long as anonymity equates to unaccountability. Someone flooding your mailbox with spam and "I have better SEO for your website" would stop the moment you could identify the sods and bill them for the time they've wasted, but you cannotm especially since there are whole nations happy to hide them. Sure, you can block anything that isn't properly following simple SPF rules, for instance, but then you run into issue 2: not everyone has it set up. Now, I personally think that not doing the very basics to protect email should deservedly leave you at the door, but we're years of education away from that position.

As for DKIM, if I see the tens of KB that Microsoft adds to every mail header just to pretend that your email is protected by them I get the feeling that that isn't a solution either..

[katrinab]

Re: It’s Outlook’s fault

In this case, yes, because it is going from one outlook.com account to another, So it is an outlook.com problem, not an email problem.

[teknopaul]

Re: It’s Outlook’s fault

When it forwards a mail from [e-mail] does it appear as from them or forwarded by xxx from them?

It's a big difference. You can always forget an email and embed it and send it along

[sitta_europea]

Quoting from this article:

[quote]

DomainKeys Identified Mail (DKIM) creates a cryptographic signature binding a message to the sending domain, but doesn't verify the sender (the FROM header).

[/quote]

I stopped reading the article at that point.

In DKIM, the 'From' field must *always* be signed:

https://datatracker.ietf.org/doc/html/rfc6376#section-6.1.1

https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Signing

[Sora2566]

That means that the FROM header hasn't been changed since the email was sent, not that the email was really sent from that account. The only "authentication" this process provides is proving that the email was sent from *somebody* with access to that domain's private key, not a particular person.

[Michael Wojcik]

Right. The sender has not been verified, just the integrity of the From header.

DKIM can't verify the sender, of course, because all it has is the message to operate on.

Authentication of the originator of a message is a hard problem. The best we can do, with email, is to verify, using an additional protocol such as OpenPGP or S/MIME, that the sender had possession of the private key which corresponds to a public key which, under some threat model, we have some reason to associate with an identity – and the nature of that "identity" can vary widely. For OpenPGP, usually it's nothing more than an email address and a small amount of associated text, usually a claimed personal name. But nothing associates that email address with a person unless you can do out-of-band web-of-trust endorsements (and far more often people just look for a public key on a keyserver and call it a day). S/MIME makes use of PKIX, so in the best case there's an X.509 certificate with useful information that chains back to a CA you grant some measure of trust to, but PKIX (and everything related to X.509) is a horrible mess and CAs have not proven to be particularly trustworthy.

And even if all of that works out, you're left assuming the sender's key has not been compromised, nor the equipment and software the sender uses. (Actually trusting the sender is not a technical problem.)

[Dr Paul Taylor]

So send email from YOUR OWN domain

the spoofed domain state.gov includes the spoofed domain state.gov includes Outlook’s SPF record (spf.protection.outlook.com) into its own SPF record (spf.protection.outlook.com) into its own SPF record

If (large) organisations sent out their own email from their own IP address space, instead of from Outlook, Messagelabs, etc., then this hole would be fixed. Human recipients could also see for themselves, without doing a recursive SPF lookup, whether the email comes from who it says it does.

If they include the SPF record of some mail handler that's also used by The Great Unwashed, their authentication goes down the drain.

Whatever the problems with SPF, I (can in principle) be more confident of where email has come from than a phone call, especially (purportedly) from a bank that starts by askingme "security questions". So far as I can gather, there is no way of tracing a phone call, even a "landline" one.

[Anonymous Coward]

Re: So send email from YOUR OWN domain

Phone calls can be traced, at least within a given provider's network. The problem comes when the call originates from another network, if you can't trust the signalling info sent by the source network you're stuffed.

[katrinab]

Re: So send email from YOUR OWN domain

state.gov does send out from its own IP address space rather than from outlook.com.

This works because it is being sent from one outlook.com account to another, so doesn't actually get transmitted over the open internet.

[AndrueC]

I've been meaning to investigate why I can reply to emails forwarded to me from Gmail as it seems odd. My Gmail account is set to forward but I can reply with 'Reply to' set to '???@gmail.com' and it works.

Seems like something should be whining about my email server impersonating Google but recipients say that the emails are clean according to their clients.

[Yes Me]

Get what you ask for

What you are describing is the definition of how "Reply-to" works. If you don't like it, don't set "Reply-to".

[Cheshire Cat]

The scenario of forwarded email was considered a long time ago, and the "Sender" header is supposed to handle it. When you forward an email from user A to user B on to user C, you are supposed to have the Envelope From set to user B, and add the Sender header to indicate user B was the latest source. This is used by mailing lists and is sometimes referred to as the "Secretary scenario".

Unfortunately, there are some issues -

* Some mailing list software doesn't do this

* Most forwarding mailboxes don't do this, and don't change the Envelope From or add the Sender header

* Some mail clients only display the From and not "From [Sender] on behalf of [From]"

* The DMARC definition ignores the Sender header and uses From even if Sender exists

The first 3 were just a case of improving software, the but the fourth screwed it all up.

[Yes Me]

DMARCrap

DMARC was badly conceived by people who didn't care about the things it would break, such as forwarding and mailing lists. So it is mainly being ignored or defeated in practice. It keeps a few liability lawyers happy.

I get 50 to 100 spams or phishes per day. Gmail catches almost all of them. The others are so obvious that they are trivial to identify and delete unread. All DMARC ever does is cause legitimate mail to be misclassified as spam, but even so I see false positives less than once a week.

[simkin]

Re: DMARCrap

DMARC works fine for forwarded messages as long as you don't alter them in transit (assuming they were DKIM-signed, SPF obviously is not suitable for use).

Mailing lists can choose to either not modify the message or they should remove auth headers and replace From: with their own address to take responsibility for sending an altered message.

[Anonymous Coward]

I blame the...

I blame the marketers, they're they weak link in this equation, every time, 100%

[jake]

Re: I blame the...

I also blame the marketers. But they are not the weak link, rather they are the exploiters of the weak links.

[jake]

Relax.

Email is not now secure, has never been secure, and never will be secure.

Don't trust anything to email that you wouldn't shout from the rooftops, and you'll be fine.

_{Yes, this can be fixed. But at that point it is no longer email.}

[Anonymous Coward]

Network Service == Single Point Of Failure

Have I mentioned this before?

Here at White Hat Towers we use peer-to-peer encryption/decryption.....where ALL the encryption and decryption is done on the end point device. We use Diffie/Hellman to communicate the secret keys (and remember that with D/H there are no transmitted encryption keys and no persistent or published encryption keys either).

So.....with this arrangement, the message transmission mechanism does not matter.....even if it's email. All the heavy lifting is done on each peer device......and there's (almost) no chance that a D/H packaged message can be spoofed, especially since every message has different, random secret keys for multiple encryption passes.

P.S. For those of you who wonder about using Telegram, you might like to read this recent article. The important bit is near the end:

- Link: https://www.theguardian.com/world/2023/feb/15/revealed-disinformation-team-jorge-claim-meddling-elections-tal-hanan

P.P.S. It's the message CONTENT that matters.......not the protocol.......private encryption is the key!!

[Terry 6]

For the public...horror

The ordinary email user sort of expects that the "From" line is there to show who an email is from. Implicitly, that the sender of an email has their identity placed into the "from" line by the magic of the internet. Or, more pointedly, assumes that the people who wrote the software included a "From" line that shows who wrote and sent that email. And this is not unreasonable. An email is from me. Therefore the software should be putting my identity into the from line. my identity . And the user has no reason to think that those clever programmers would have written it so that the from line shows any other identity than the sender's . And though I'm much more tech savvy than most users and totally suspicious of anything and everything that comes from the internet I also find it beggars belief that this system has been written in any other way. Specifically that it's been written so that a sender can lie about their identity. I don't understand email protocols; it's never been an area I've needed to develop. But I struggle to imagine why they were written with such a loophole for fraud built into them. Apart from the fact that it's like building a safe with a window in the side even if they weren't able to imagine that someone would misuse this facility, why would they put it there anyway. To me, like any user, it seems an obvious aspect of a messaging system that it tells the recipient who it's from and so it is inconceivable that anyone would write it so that didn't happen

[Anonymous Coward]

Let's Believe Two (Or More) Impossible Things Before Breakfast!!!

@Terry_6

Very clear. But the problem is not with the programming or with the technology.

Why? Well.....just think about this.....How does anyone certify the identity of the person hitting the keys of a remote computer? Exactly who is the AC typing this comment?

And if you look carefully at the "Online Safety Bill" you will see that lawmakers also have a problem with these questions. A part of the act which "demands mandatory age verification" has been dropped.....specifically because "age verification" means verification of the identity of the person at the keyboard....AND THIS IS IMPOSSIBLE!!!

So.....you are puzzled about email NOT having a capability which "tells the recipient who it's from".......our lawmakers and OFCOM are similarly puzzled because they can't find any way of making a law which forces internet service providers to find out who is at the keyboard.

Welcome to the world of network-based services!!!!!

[sitta_europea]

Re: For the public...horror

"... it beggars belief ..."

Maybe not if you look at the history.

RFC821 is dated August 1982.

In those days, wide-eyed, bushy-tailed nerds, many of them at universities, were experimenting with new ways to communicate which they thought would benefit all Mankind.

They'd had no exposure to third-world levels of corruption and crime. They hadn't bargained for abuse on a global scale.

It soon became clear that the first, fumbling steps hadn't taken account of the Lowest Common Denominator - the Mankind of which we'd seemingly had such a high opinion.

Unfortunately by the time everyone realized what some of the people would do with this new toy, it was too late to do very much about it. The specifications weren't written in stone, but it takes forever to change them because the technical inertia caused by complexity, the installed software base, the need for diverse systems to inter-operate, and both users' and suppliers' resistance to change (whether conscious or otherwise) is truly gigantic.

So we've patched a few holes in it, but basically it's the same garment we made forty years ago.

If we were able to start with a clean slate and a lot of hindsight, things might be different. But we are where we are and we just have to live with it.

[Terry 6]

Re: For the public...horror

That's where it beggars belief. (An AC wrote "Why? Well.....just think about this.....How does anyone certify the identity of the person hitting the keys of a remote computer? Exactly who is the AC typing this comment?") But......

For me, a user. I log in to an email programme ( or web site). That programme has my email account(s) set up in it. If I have more than one I select the one I want to use. My email address appears in a line that says "From:... It just does. No user intervention required. It's the address I am literally sending from . No need for a remote ISP to need to identify me or "certify " anything. I'm identified by the account I'm sending the email from. The clue's in the word.

I add the recipient(s) into To: CC: or BCC:, then type the message and send. There is no obvious reason why that "From" line would contain anything other than my email address- the one attached to my email account.

So why would those idealistic early developers have decided " I've had this great idea- let's give users a way to send an email that looks like it came form someone else entirely".

Even if they hadn't considered the remote possibility that it could be misused ( could anyone have been that naive?) it still seems remarkably perverse.

[Anonymous Coward]

Re: For the public...horror

@Terry_6

Quote: "....There is no obvious reason why that "From" line would contain anything other than my email address...."

Go to Mail.com. Choose a user name, say "Benjamin Disraeli". Choose a domain name, say "journalist.com".

......then start sending lots of email as "Benjamin Disraeli"@journalist.com.......................

Yup.....you are sending your email from your new email address....................but none of your recipients know that the sender is Terry_6.

Got it?

[Terry 6]

Re: For the public...horror

But that is from that address It's just become another one of mine.

I'm not sending from one address and appearing to be from another.

Spoofed messages appear to come from prominent domains operated by government, finance, legal, and media organizations, but come from somewhere else. An example cited in the paper of a successful attack is a spoofed email purporting to be [e-mail] that was delivered to a Gmail user’s inbox without any warning notification.

[jake]

Re: For the public...horror

It is because the From line in an email header isn't important to the delivery of that email. It is only there as a courtesy to the (intended) recipient. It is so unimportant that it can be omitted entirely, and properly written email software will allow it to be delivered anyway. Alternatively, you can make it say "From: [e-mail]" and give your kid a thrill.

Yes, nefarious people exploit this ... but they are not actually exploiting the email system, rather they are exploiting the gullibility of the ineducable masses who don't know (and don't care) how email actually works.

[Terry 6]

Re: For the public...horror

Interesting but that they are exploiting the gullibility of the ineducable masses who don't know (and don't care) how email actually works. sums up the issue. Why the fuck should users think that the "From" field in their email - that automatically appears when they start the message- is anything other than literally that?! You may think it's there as a "courtesy". But anyone with an ounce of reason is going to think that a system which is designed to apparently tell recipients of a message who it's from is actually going to tell them who it's from. Because that's what messages are meant to do.So that the recipient knows who it's from. Which is normally what messages are for. And inevitably creating it so that it only appears to do that is an opening for miscreants.

[jake]

Re: For the public...horror

"So why would those idealistic early developers have decided " I've had this great idea- let's give users a way to send an email that looks like it came form someone else entirely"."

Because in those early days, I might use a mailserver near me[0] to send email, but want the recipient to respond to another domain entirely. For a realworld example, quite often when I was in England I would login to my Demon account to send email. I'd use the Demon mailserver, but set my From address to my personal domain, one of my accounts at Stanford or Berkeley, or perhaps at a company I was consulting for. (Before Demon, I had access through a couple of UK Unis, but phone calls were horrendously expensive back then ... ). Back in the days of switched-56 and the like it saved a lot of bandwidth (money) that most of us didn't have enough of.

The Demon account was just for easy connectivity in Blighty. The only time I used it's email account was for correspondence with the fine folks at Demon, a local computer users group, and later a LUG or two. Or six.

[0] _{A host is a host from coast to coast / And no one will talk to a host that's close}

_{Unless the host (that isn't close) / is busy, hung or dead. —David Lesher}

[jake]

Re: For the public...horror

"They'd had no exposure to third-world levels of corruption and crime."

No? What, you think YOU kids invented that? Honestly ...

"It soon became clear that the first, fumbling steps hadn't taken account of the Lowest Common Denominator - the Mankind of which we'd seemingly had such a high opinion."

Oh, horse shit. The reality is that it wasn't important, at least at first. We were inventing a network that was being used to research networking. Absolutely nobody had any intention of this new network being used outside academia. Because of this, it was built from the ground-up to SHARE data, not to SUPPRESS the sharing of data. Thus no security to speak of ... or, rather, what little security there was handled at the operating system level, sometimes the individual program level.

By the time we realized that perhaps this thing might escape the lab and become useful outside it, it was almost too late. Some of us at Berkeley and Stanford approached the PTB with the idea that we should think about security, as a built-in optional extra. We worked on it, on and off, mostly in our !copious spare time, for a couple years until roughly 1981 when the Brass informed us in no uncertain terms that we were to stop immediately. No security for us. It turned out that the Pentagon (and the NSA, as we found out later) had threatened to cut all funding for the ARPANET if we didn't. The Brass absolutely flat out refused to take our side of the story to his puppet handlers. He simply said (paraphrasing) "No. You are to stop immediately. The subject is closed. Period."

The man who refused to go to bat for security on your Internet? Vint Cerf. Who got his 30 pieces of silver from Alphagoo.

MILNET and ARPANET split soon afterwards (1983), but TCP/IP had already gone "live" and it was too late. Go figure. And of course the NSFnet officially started about half a decade later, and was built on these foundations. And then Marketing started getting involved in the very early '90s, selling an inherently insecure network to the ineducable Masses as a good place to spend money ...

So here we are. Living, working and playing (and spending lots and lots of money!) on a network that was not designed with security in mind, was stopped from getting that security mid-stream, and as a direct result is not secure today, and can not ever be made secure without a ground-up re-write.

And you lot are bitching about a piddly little thing like fscking email forwarding not being secure? FURRFU!

_{No, I do not purchase anything over the 'net, nor I do I do my banking etc. over it. Why do you ask?}

[Terry 6]

Re: For the public...horror

I take your point there, but when you write And you lot are bitching about a piddly little thing like fscking email forwarding not being secure?

Well,what the article was about was teh direct spoofed communication of messages and it's generally an error to say don't worry about this egregious problem because it's part of a bigger one.

[jake]

Re: For the public...horror

"Therefore the software should be putting my identity into the from line. my identity"

What if you have a dozen or more honest "identities"? Shirley it would be easier to do all of your correspondence, with a different From as applicable, and then login to one server and send the lot in one big batch. Your way, one must spend the time (and bandwidth) to individually login to each and every server required, just to send perhaps one email from each, which is spendy when it comes to network resources.

Remember, bandwidth was money when this stuff was being developed. And that logging into the server meant a telephone call which was likely not free.

[Terry 6]

Re: For the public...horror

It's currently a matter of a drop down menu. I guess when I was logging in to an email service in the dial up days it might have been a matter of logging into a different server for a different account. Was that expected to be a thing when the protocols were designed, that users would have multiple email addresses? That early on? And yet they didn't have the same level of foresight to see that a spoofed From line could be used by liars?