Outgoing White House Emails Not Protected by Verification System (axios.com)

The security advocacy group Global Cyber Alliance tested the 26 email domains managed by the Executive Office of the President (EOP) and found that only one fully implements a security protocol that verifies the emails as genuinely from the White House. From a report: Of the 26 domains, 18 are not in compliance with a Department of Homeland Security directive to implement that protocol. Imagine the havoc someone could cause sending misinformation from a presidential aide's account: Such fraudulent messages could be used in phishing campaigns, to spread misinformation to careless reporters, or to embarrass White House employees by sending fake tirades under their names.

Comments

Alternative verification in place

[Anonymous Coward]

Anything that ends with the word
B00B135
is genuinely from POTUS.

SubjectsSuck

[aardvarkjoe]

Imagine the havoc someone could cause sending misinformation from a presidential aide's account:

Imagine the havoc someone could cause sending misinformation from the President's Twitter account! ...on second thought, not much imagination required.

Re:SubjectsSuck

[gtall]

They'd be indistinguishable.

Re:SubjectsSuck

[Oswald McWeany]

They'd be indistinguishable.

Usually, Phishing e-mails can be identified by misspellings and poor grammar. In Trump's case, if an e-mail was sent with correct spelling and grammar it almost certainly wasn't from the real President.

Re:SubjectsSuck

[Anonymous Coward]

SO if someone sent an email from one of the accounts, it would be "genuinely from the white house" and no amount of after-affect snake-oil sold by snake-oil-salesman will make a whit shit of a difference.

The "Global Cyber Alliance" is obviously a bunch of looney-tunes assholes with no idea what they are talking about! They should, the lot of them, be taken out to the back forty and shot before they spout more stupide assinine lying mistruthes and bullshit.

It's e-mail, it's never going to be 'secure'

[guruevi]

There is this checklist that pops up here on Slashdot once in a while. There is no way of making e-mail secure. Yes, I could send an e-mail from obama@whitehouse.gov from my personal e-mail server and nobody would be able to prevent it. There are ways of verifying, but all parties have to agree on the method of verification and how that is done depends on whether you're Yahoo, Microsoft or Google

Re:It's e-mail, it's never going to be 'secure'

[squiggleslash]

There are ways of verifying, but all parties have to agree on the method of verification and how that is done depends on whether you're Yahoo, Microsoft or Google

I was under the impression pretty much everyone recognizes SPF these days.

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

SPF is widespread and DKIM is pretty prevalent (at least in Linux ecosystem). Google stats show adoption to be quite high.
whitehouse.gov has an SPF record:

v=spf1 +mx include:spf.mandrillapp.com ip4:214.3.140.16/32 ip4:214.3.140.255/32 ip4:214.3.115.12/32 ip4:214.3.115.10/32 ip4:214.3.115.225/32 ip4:214.3.115.14/32 ip4:214.3.140.22/32 ~all

-so only email servers that don't check SPF would accept your fake email, which isn't as many as one would think.

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

It's never going to be secure? Have you ever heard of PGP?

Re:It's e-mail, it's never going to be 'secure'

[Thruen]

Your front door isn't truly secure, it can be knocked down. Does that mean you shouldn't lock it? Does that mean the President shouldn't lock his doors?

Personally, I feel like even if a problem can't be entirely avoided, it makes sense to put a reasonable amount of effort into reducing the chances of that problem occurring. Seems like most folks agree considering how often people lock their doors. I suspect you agree, too, but decided to throw logic out the window on this one for whatever reason. The fact that one of these domains was better protected tells us more could've been done to protect the others, and I don't think it's unreasonable to ask an administration that has stressed the importance of email security as much as this one has to put that little bit of effort in.

Re:It's e-mail, it's never going to be 'secure'

[blane.bramble]

Not strictly true - that SPF records says to treat a failed result as suspicious, not to reject it, so email servers will accept it and usually treat it as having a higher spam rating.

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

Good point, I didn't even notice that, surprised to see a .gov record having a mistake like that given all the audits.

Re:It's e-mail, it's never going to be 'secure'

[mysidia]

but all parties have to agree on the method of verification

That's why we have standards, and the applicable standard is called DMARC, which involves implementing a SPF policy in the DNS zone, DKIM message signing, and a DKIM policy in the DNS zone, and signing the DNS zone using DNSSEC.

Re:It's e-mail, it's never going to be 'secure'

[bluefoxlucid]

E-mail could use TLS between client/server and between relay servers. Authentication could use FIDO U2F for client-to-server. We could also rework the FIDO standard--and the hardware devices which use them--to include OpenPGP signing and encryption, and add Curve25519 to FIDO U2F and OpenPGP as the key exchange (i.e. your PGP key is Curve25519, instead of RSA).

The mail client would send each message to the FIDO device for signing using SHA-256 (if not encrypted) or a key-hashed message authentication code based on SHA-256 (if encrypted). Encryption would also occur to the target parties via the FIDO device, using AES-256 (the pubic key for each party encrypts a separate copy of this key) and CFB mode for the message (semi-parallelizable).

This scheme would actually never reveal the session key to any party using the FIDO/OpenPGP device. The sender encrypts the message to self, generating the session key on the FIDO device; however, the sender's private key is on the FIDO device, so the sender can't read the session key. Thus, to read the message, the sender must send the message down to the FIDO device for decryption. The device thus would decrypt the session key, read the message, validate the HMAC signature, and return the plaintext of the message and the validation results.

It is also possible to send the message down with "Also Encrypt To", so the FIDO/OpenPGP device would decrypt the session key, make an encrypted copy with the public key of an additional recipient, re-HMAC the whole thing, and send the result back. Note that because the session keys cannot be part of the symmetric-encrypted body or the signature (the hash is generated by signing, thus its value is unknown during signing), you can actually add recipients by just returning the new block of HMACs and encrypted session keys (you'll generate these encrypted keys before the hash, and they're independent of the hash, so you can include them in the signature), and not return a re-encrypted message.

This allows each user to use a hardware device paired with a mail client to authenticate themselves (private key, never leaked) and the message sent, as well as to make the message a secret to everybody but intended recipients and malware able to read the decrypted message. Note that you decrypt each message as you open it, so a bulk store of decrypted messages is not available. The security-conscious could individually encrypt each message they receive (automatically), thus avoiding a bulk store of plaintext messages in any case.

Mail server support is neither required nor useful.

Re:It's e-mail, it's never going to be 'secure'

[houghi]

If only there where some sort of General Purpose Guard or a some sort of Public Guarding Preference.

And secure does not mean secret. It means verifiable. I want to know if the email is from my bank or from a phishing site.

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

Lock YOU up.

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

The fact that one of these domains was better protected tells us more could've been done to protect the others, and I don't think it's unreasonable to ask an administration that has stressed the importance of email security as much as this one has to put that little bit of effort in.

There are several options none of which have wide support and all rely on receiving systems also implementing the same protocols in the same way. I suspect that with Trump, no matter which option is chosen you will simultaneously claim it was not the correct one and repeat the reasoning:

Your front door isn't truly secure, it can be knocked down. Does that mean you shouldn't lock it? Does that mean the President shouldn't lock his doors?

Security is about reducing risks. Residual risk is always present. There always has been and always will be a way to criticize any security system. Anything with the world "Trump" in the title many people readily criticize, regardless of merit or sense.

Re:It's e-mail, it's never going to be 'secure'

[rickb928]

Does no one remember the days of the Korean servers spoofing your mail server and sending error reports all over the globe in your server's name?

Ah, the good old days. Filling my Groupwise server volume with undeliverables in hours. The old Exchange servers just rolling over dead.

I really don't trust email I either do not expect or are new senders to me, and the White House doesn't send me anything. Neither does the IRS, except for, ready, online ID authentication and update requests. Yeah, great stuff. SSA does this also.

Really, the White House email domains are being spoofed by someone right now. It's just such a rewarding hobby for someone.

Re:It's e-mail, it's never going to be 'secure'

[Oswald McWeany]

There is this checklist that pops up here on Slashdot once in a while. There is no way of making e-mail secure. Yes, I could send an e-mail from obama@whitehouse.gov from my personal e-mail server and nobody would be able to prevent it. There are ways of verifying, but all parties have to agree on the method of verification and how that is done depends on whether you're Yahoo, Microsoft or Google

I've long enjoyed sending e-mails to my co-workers from other people by setting the from-address to various things. It's amazing how many times they've fallen for the same joke.

Re:It's e-mail, it's never going to be 'secure'

[Sloppy]

There are ways of verifying, but all parties have to agree on the method of verification and how that is done depends on whether you're Yahoo, Microsoft or Google

Or you could, I don't know, use a standard like OpenPGP which always Just Works whether some company happens to agree or not. The only people who have to agree are the users.

If the users don't agree to have email be secure, then it can't be secure. If they want it to be secure, then it's easy.

This is hard to implement to society at large (because society's "users" never agree to do anything) but within an organization, it's no problem as long as whoever's in charge wants it. "Bob, you didn't sign your email, yet again? Ok, you're fired. I'm sure we can find someone else who is willing to follow orders."

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

Found the apologist

we can't stop every case of impersonation, so let's not try to stop any

hmm, sounds a lot like the right's gun control stance

Re:It's e-mail, it's never going to be 'secure'

[guruevi]

Should the President have an unguarded wooden interior door as an entrance to the White House? You just don't use e-mail for highly secure communications. If you receive an e-mail, you should distrust it.

Re:It's e-mail, it's never going to be 'secure'

[guruevi]

But that doesn't prevent me from sending an unsigned message through a relay and unless the user has the technical chops to distinguish the two, it doesn't matter much.

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

Only if you configure it that way. You can also configure your MTA such that SPF failures are dropped in /dev/nul

Stop displaying your total ignorance of fact.

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

It is not a mistake. It is done deliberately. There are a huge number of so-called "security assholes" that configure their SPF records to permit the entire internet to relay their domain. They do this on purpose because they are too fucking cheap (and incompentent) to afford the $40/month it costs to set up and run properly secured MTA's.

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

This is not possible. EIther (a) you are making shit up or (b) you are completely totally and utterly fucking clueless.

(b) gets my vote.

Re:It's e-mail, it's never going to be 'secure'

[r2rknot]

That SPF record has a soft fail at the end though, which IMHO make it pretty pointless.

Re:It's e-mail, it's never going to be 'secure'

[hey!]

There are absolutely ways of making e-mail safe. The technology has existed for decades and has been available in some email systems.

But to run a system like that, you've got to have administrators who can manage things like cryptographic trust delegation, and not everyone is willing to pay for that kind of expertise "just for email".

Now I think that if everybody *did*, it would be a net win. There'd be no more phishing. Claims of identity would have a kind of audit trail, and you could revoke trust in certificates issued by authorities that weren't up to snuff. Communications would be routinely secured, even against bad guys with physical access to your device.

But the thing is it only works if most people are willing to put up with the hassle. It's not our technology that needs upgrading, it's *us*.

Re:It's e-mail, it's never going to be 'secure'

[greenwow]

But Trump is stupid so there's no way he could use it. He can't even fix this simple damn email problem. He is incompetent and has never succeeded in a single damn thing in his life.

Re:It's e-mail, it's never going to be 'secure'

[Spazmania]

The White House could also turn the email servers off and lock them in the closet. Like DKIM this would have a negative impact on their function, but it would provide very solid guarantee on whether the received emails were legitimate.

SPF is okay in most email configurations. DMARC and DKIM are disaster areas which break common email scenarios like mailing lists.

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

You're either misinformed or you don't know what you're doing.

Re:It's e-mail, it's never going to be 'secure'

[mysidia]

The White House could also turn the email servers off and lock them in the closet

That step is not an equivalent, And nope... turning off their servers would not stop 3rd party's mail servers spoofing their domains From: addresses.

DMARC and DKIM are disaster areas which break common email scenarios like mailing lists.

Most major mailing list software handle it just fine when posters' domain has implemented DMARC --- either change the From: address or preserve the headers so DKIM signature continues to match after forwarding.
The scenario you describe is not "common" anymore; in fact, it's so uncommon, that many major mail providers have
chosen to ignore it and implement DMARC strict enforcement with required DKIM upon their domains regardless.

Some legacy mailing list managers -- when used for discussion lists have issues with, But such mailing lists are
an exceedingly rare site these days; social media sites such as Facebook/Twitter, and Web-based forums have
all but completely replaced the concept of an E-mail based discussion list, so they've really gone the way of Usenet.

Also, enough of the SMTP servers on the internet support preemptiveTLS that some webmail providers are starting to provide visual security warnings to end users or refuse to deliver mail to servers that won't accept TLS connections.

Re: It's e-mail, it's never going to be 'secure'

[rickb928]

There's a 50-50 chance I've been managing email systems since before you were born.

Re:It's e-mail, it's never going to be 'secure'

[scdeimos]

Your example SPF record ends with "~all", aka SoftFail, meaning that receiving servers will still accept mail from other (unlisted) addresses and will likely not even flag it to recipients as being suspect.

If you want receiving servers to reject other mail, assuming they're even doing SPF checks, then the SPF record should end with "-all" instead.

Re:It's e-mail, it's never going to be 'secure'

[guruevi]

My point was that those schemes have been tried. The problem generally boils down to the fact that
a) Everyone needs to participate all at once for the plan to succeed
b) Everyone needs to agree on a plan to succeed in the first place
c) It doesn't account for anyone's privacy or personal security (eg. whistleblowers)

Re: It's e-mail, it's never going to be 'secure'

[oobayly]

SPF is ask well and good, but I've had to configure our server not to reject email that hard fails SPF (it gets flagged as spam) as the number of badly configured records is ridiculous.

I tried to explain to one colleague who had a call from a customer complaining that we were rejecting his emails, that he was doing the equivalent of posting us a letter with a big red warning that says "THIS LETTER IS NOT FROM ME, DO NOT OPEN".

Then I couldn't work out why I hadn't received a receipt from a supplier, same problem indirect hard fail. They were from a noreply address so the DSNs were never seen.

DKIM is also useful, if the MTA adds the header. The recipient doesn't know that DKIM should be expected, just to verify it if it's present. **I hope I'm wrong about that, so please let me know if I am**

Re:It's e-mail, it's never going to be 'secure'

[bluefoxlucid]

Notice how the mail client above describes that the key isn't even on the device and the end users never even know the key (i.e. the mail client doesn't have the capacity to decrypt; it's on the hardware device)?

The mail client would tell you if it's signed properly. I also overbuilt the HMAC there: you'd only generate one HMAC, not one per user (because the HMAC will use the session key, and there's only one). So "HMAC", not "HMACs". My bad.

Just look for the green light on your e-mail.

Re:It's e-mail, it's never going to be 'secure'

[chihowa]

It's not a mistake. A huge number of receiving servers don't handle SPF correctly, so you need the softfail at the end to allow delivery (totally defeating the purpose, yes).

For example, every university system that I've ever been exposed to that uses Office 365 ends up with a server somewhere in the chain checking the SPF record against itself and always failing. Without the softfail, everything gets bounced.

Re:It's e-mail, it's never going to be 'secure'

[guruevi]

Okay, except that while you're setting up the infrastructure, pretty much every e-mail is going to be orange or red as will the e-mail for everybody that doesn't join the system. Eventually (in a matter of minutes-hours) you'll condition your users to ignore the thing.

Re:It's e-mail, it's never going to be 'secure'

[Anonymous Coward]

There are ways of verifying, but all parties have to agree on the method of verification and how that is done depends on whether you're Yahoo, Microsoft or Google

So my question would be does the WH email server has any verification method (in part to the "all parties") implemented? If not, then WH is still in the wrong.

Re:It's e-mail, it's never going to be 'secure'

[bluefoxlucid]

Grey, for non-signed, no-signature-known.

Orange is for when you have no way to verify the signature (including no signature but known key), and Red when it's incorrect (e.g. different key than expected); and the e-mail client itself can fetch key and yellow you for an unknown/unsigned key. Green for soft verification (you send your public key encrypted/HMAC, they send back an encrypted/HMAC public key for themselves, and continuous exchange shows no anomalies); blue for hard verification (public CA).

Initially, everything is grey. Your friends will go green. Corporations will go blue.

The real user training problem is with the Yellow-to-Green transition and the Blue marker here. Marketing e-mails will all be Blue under the scheme I described. Non-public-CA e-mails from anyone who generates a signature will show up Yellow, and then your client can perform a likely verification to identify that the key is correct and go Green.

That only means you can trust the sender to be who you think they are.

It doesn't mean the message is safe.

In other words: all these Green or Blue e-mails can come from spammers and phishers. You can absolutely verify they're not spoofing your boss, but you can't verify that they're not trying to scam you.

I'll think up a more-complicated, less-technical scheme later, such as one that reserves the Blue level and a special decoration for long-term trust (i.e. you have a lot of conversations with a person, so they're a valid acquaintance and not just some marketing firm or 401 scammer). That goes beyond "was this message sent by the purported sender?" and into "Do I personally know and trust this person?" It's a different problem.

Re:It's e-mail, it's never going to be 'secure'

[guruevi]

Although this is a fun exercise, you have to think about the usability in security schemes. When it is more complex than red-orange-green, people will ignore it. And as I said, if you have more than 1% of grey areas, false positives or false negatives, you've conditioned your users to ignore it.

Re:It's e-mail, it's never going to be 'secure'

[bluefoxlucid]

Not really. You can have two parallel schemes and a neutral state if they're easily-differentiated and meaningful to the user (e.g. friends and people versus corporations).

The false-positive and false-negative rate is zero in signature validation. The no-information rate is non-zero.

misinformation from a presidential aide's account

[Patent Lover]

How would this be any different than normal?

Maybe e-mail servers need to be easier to setup?

[Anonymous Coward]

That's no excuse of course, you would think the IT staff at the White House of all places would be experts on security, but still... Getting an e-mail server configured on most platforms is a mess. It involves having to configure several different pieces of software to work together, each of them have to be secured individually, then you actually have to get it up and running with the outside world, probably behind a firewall and with some intrusion detection, virus scanning of incoming/outgoing messages... If you're doing this in Linux then it typically involves editing a whole lot of configuration files, if you're lucky then your distro might have some console or (if you're really lucky) some GUI tool for configuring them.

I get the sense that people want secure e-mail servers and that this was probably an oversight, but maybe we need to stop looking at people as the problem and try to design technology that's as foolproof and easy to configure as possible... Maybe there's a way of doing e-mail server setup and configuration that isn't so difficult that even a White House IT guy can screw up the finer points.

cuts both ways

[Anonymous Coward]

Or protects the white house by providing deniability for actual tirades.

Re:Maybe e-mail servers need to be easier to setup

[Anonymous Coward]

The IT staff at the White House probably consists of some alt-right bros who worked on the Trump campaign and have little real world IT experience beyong gaming.

Re:Maybe e-mail servers need to be easier to setup

[omnichad]

you would think the IT staff at the White House of all places would be experts on security

What we really need is a true military branch dedicated to cybersecurity, and actually put them in charge of some aspects of all government IT.

Tricking people isn't fixed by domain verification

[Anonymous Coward]

The underlying problem is that people can be tricked into thinking an email comes from another person. Even if you get everything working right, and both ends agree on the verification scheme, all it takes is to create another similar domain for the email to come from, and you've failed.

People are easy to fool, especially over email. This (mostly) isn't a technology problem, it's a human problem. If you want legitimate news, you need fact checking. That's something that needs to be better addressed, since many publications don't do that properly in the race to "first" to report.

Bad headline

[Anonymous Coward]

Obviously, it should be "Outgoing 'tippy-top house or building place' emails ...." Since we all know there is no name for it.

reverse Poe's Law

[cellocgw]

".... send fake tirades..."
How could anyone tell them from the real thing? I mean, unless the fake ones contained, like, real data or real science.

Re:reverse Poe's Law

[gweihir]

Simple: The Dumb is not able to email. Genuine tirades will be on Twitter.

Re:reverse Poe's Law

[BrianMarshall]

The real ones end with: SAD!

Re:Maybe e-mail servers need to be easier to setup

[turp182]

There already is, it's the NSA, but their goals are the opposite of what you describe.

Did that include Hillary's private server?

[Anonymous Coward]

Asking for a friend

Blind relay

[Anonymous Coward]

Considering how fucking stupid Trump and his staff are, I wouldn't at all be surprised if the Whitehouse is running a public-facing open SMTP relay. Not like that would be a big surprise anyway, it's not like all his tweets are SPAM to start with.

Re:Blind relay

[Oswald McWeany]

Considering how fucking stupid Trump and his staff are, I wouldn't at all be surprised if the Whitehouse is running a public-facing open SMTP relay. Not like that would be a big surprise anyway, it's not like all his tweets are SPAM to start with.

That's really not down to Trump; I wouldn't expect any President, past, present, or future, to know anything about setting up an e-mail server. That's really not part of the job description of the President. That's down to the staff hired for the job, and I have no way of determining if they are smart or otherwise.

Re:Blind relay

[Anonymous Coward]

It probably goes something like this:

President: "I want email to be secure."

Staff: "Ok, done. We installed GPG and so now you'll need to be able to sign your emails so that people will know they're really from you."

President: "Wait, they'll know for sure that I actually wrote that? I won't be able to credibly deny it later?"

Staff: "Right. No confusion will be possi--"

President: "I want email to be insecure."

Re:Blind relay

[Dragonslicer]

Considering how fucking stupid Trump and his staff are, I wouldn't at all be surprised if the Whitehouse is running a public-facing open SMTP relay. Not like that would be a big surprise anyway, it's not like all his tweets are SPAM to start with.

I'm probably being naively optimistic, but I would hope that the White House IT staff are not political appointees.

Putin will bring a USB stick.

[Anonymous Coward]

..and ask to use a terminal on his visit and then thats about it for the once great USA-Americans. LOL.

Jail!

[Anonymous Coward]

Darned Hillary. Throw her in jail! Oh, wait...

Why wasn't that done years ago?

[tomhath]

Was the security protocol implemented during the Obama administration and then backed out?

Re:Why wasn't that done years ago?

[Anonymous Coward]

Any security protocols put in place by Obama would have been canceled outright by Trumps people out of spite if nothing else. I wonder if the security of this kind of stuff is overseen by his kid. After all Trump has already stated that his kid knows more about computers than all the people is the previous administration.

Re:Maybe e-mail servers need to be easier to setup

[omnichad]

Sure, there's an agency. But I'm thinking actual military branch. It's starting to make more and more sense to treat cyberattacks as acts of war and having a civilian agency handle that just doesn't make sense anymore.

Plausible deniability?

[MiniMike]

If I had the unfortunate job of defending what comes out of the White House, I'd be keeping this as a backup plan. I would guess that the one secure domain is for lower level employees.

I got an idea

[Anonymous Coward]

Use personal servers instead. Colin Powell once warned a lady, I forgot her name, that gov't servers were crap.

Kremlin Says Fine with Us

[LifesABeach]

What? Me worry?

DURRR...DRUMPF!!!

[Anonymous Coward]

Look, Mom...I typed it again! LOLOLOLOLOLOLOL

Really Mess With Them

[Anonymous Coward]

You know what would be hilarious? Start sending out messages impersonating Big Giant Orange Head, but have the messages be traditional Republican positions for everything. I'm talking serious, professional, staid talking points we all know that BGOH would never say:

1). Trade is good, business is good, and trade wars are bad;
2). Immigration reform is important, just not important enough to do anything about;
3). Friendly nations are great, and enemy nations are Sad;
4). All trade agreements are automatically approved;
5). Personal morality is a critical ingredient for political leadership;
6). Veterans are beyond reproach, under all circumstances;
7). Lies are bad, facts are good, you can trust the White House communications staff to tell the truth;
8). The US is the leader of the Free World and will play a key role in the dissemination of freedom and democracy. America is Exceptional!;
9). The Presidency is a dignified position and so the President will not get involved in tawdry, petty disputes;

Hey, this is fun, and you can play too!

No imagination needed

[Anonymous Coward]

In the late 1800's a person by the name of Otto Bismark intercepted and forged a message from France thus causing France to declare war on the Prussian states.

I don't need to imagine what a con-artist can do.

Re:No imagination needed

[careysub]

No, this reference to the Ems Dispatch is false. Bismark intercepted and forged nothing. The Ems Dispatch was issued by Bismark's office, and described an exchange between the French Ambassador and King Wilhelm I wherein the Ambassador made an impolitic request, or demand.

A bit like the game of Chinese Whispers ("Telephone") the account of the exchange, underwent changes as it was recounted by the King to Bismark, Bismark's public dispatch about the incident, and then translated and reported by the French press, being perceived as an insult to the Ambassador in France, and leading to a really poorly considered response - the declaration of war.

DMARC does not do what they think it does.

[r2rknot]

Simply put, DMARC tells a recipient what your desired action is in the event a message fails either SPF or DKIM checks. It also does some checks on the Header and author FROM fields to see if they match.

It is up to the receiving server to do one thing or another with its received emails. If you had SPF and DKIM setup and working, its hardly a big deal to not have DMARC done correctly. But if you do not have SPF or DKIM working. DMARC will not save you at all.

Re:Maybe e-mail servers need to be easier to setup

[_Sharp'r_]

So you're saying all these domains were setup with verification before January 2017, and then Trump Administration employees changed them to no longer be setup that way? Riiight.... have you ever been involved with a government IT project?

Yeah, somehow I think you're the one smoking something.

Re:Maybe e-mail servers need to be easier to setup

[Dragonslicer]

What we really need is a true military branch dedicated to cybersecurity, and actually put them in charge of some aspects of all government IT.

It isn't a military organization, but NIST does publish standards for computer security at federal agencies.

Re:Maybe e-mail servers need to be easier to setup

[omnichad]

It's a start, but it seems that the planning phase was handled fine - they had nobody qualified to implement it.

eh..

[Anonymous Coward]

BUT her EMAILS!