Use SPF softfail, not (hard) fail

Could be useful, but a successful attack on BIMI would require: - Getting access to the DNS of the domain (in which case the null record will simply be replaced) - Obtaining a VMC for the domain, which should not be possible due to the extended validation requirement for a VMC (such as: phone validation) - Spending ~$800 on a VMC

> especially if one is going to use soft-fail.

As explained in the article, if DMARC is deployed then softfail is equal to (hard) fail. With DMARC anything that is not an SPF pass, is not aligned, thus a fail.

The only exception here would be a very old legacy email system that doesn't support DMARC. But those will also not support BIMI anyway.

> Or maybe a malware symbol.

BIMI should always require a VMC. It should be impossible to obtain a VMC with a 'malware symbol'. Unless of course you are willing to pay a lot to get it registered as your company logo at your trademark office.

How do you propose that you "rewrite" headers without breaking DKIM? Any header included in the message's DKIM "h=to:from:... " stanza cannot be changed; they're included in the DKIM signature.

You can simply textually include the entire original email in a completely NEW email message, that is DKIM-signed by your intermediate (forwarding) MTA -- but that's not "forwarding", at all -- that's just "sending an email".

Is this what you're describing?

This is how DMARC is designed, I can't change that. You can have an SPF fail but aligned DKIM, the email will be accepted. You can have SPF alignment without a DKIM signature, and still be accepted. If you have neither, the email will be rejected.

This was all designed with backwards compatibility in mind. This was back in the days that not every email service was capable of signing with DKIM, so for those you could still use SPF. However, it was already widely accepted back then that SPF was very much broken by design, and you should use DKIM instead (but keep SPF for backwards compatibility).

DKIM is much better in terms of security (it uses actual cryptography) and reliability (much less likely to break beyond your control). If your email services support DKIM, you should use that.

> If SPF is configured to disallow, then DKIM shouldn't disagree with that. If you expect DKIM to "win", then you're doing it wrong.

DKIM is able to disagree with SPF, that's how DMARC is designed. If you an email has a valid signature, but not valid SPF, your email should still be accepted.

> Or I'm missing something. Please explain how "SPF can fail beyond your control" in either scenario: one, where you control your own SPF and you're concerned about outgoing email, or two, where you control your policy for enforcing SPF and you decide to block SPF with -all.

It think you are missing something. You can set a '-all' policy, but then you risk making you own perfectly authentic and DKIM signed email undeliverable. You cannot rely on SPF to pass, even if you have the sender set up correctly in the SPF policy. This has all been fixed with DKIM and DMARC, but setting '-all' may prevent this from working.

> Also, your comments about DMARC still don't explain why it's somehow OK to NOT configure SPF properly in the first place.

Because SPF is broken by design, and DKIM and DMARC have solved this. You are not going to get 'better' security with -all, since SPF does not provide any real security.

To simplify: SPF is broken by design. DMARC is better, but '-all' is not compatible with DMARC. So, the article discusses that the actual proper configuration of SPF is ~all, since you do not want to rely on SPF anyway.

Sure, it's probably silly. But, SMTP is what it is, and you're not going to change it by complaining

SPF's design just ... forgot about this, which happens all the time for email.

Every MTA -- literally every forwarding MTA -- does this all day long, and every receiving MTA (which looks at the "Return-Path: <originaladdress>" to lookup the SPF TXT record), gets your fancy "v=spf1 ... nothing w/ forwarding MTA in it ... -all" record, and summarily executes the email w/ SPF: FAIL?

It's just wrong. SPF can only serve as one (strong) hint that an email might be correct, if it passes. If it fails, all your MTA can assume is: "well, the email was very likely forwarded"; what else does it have going for it?

If its "DKIM-Signature: ..." header is valid, that it's almost certainly A-OK! So, why do you want all your domain's nicely DKIM-signed emails dropped, just because some recipient decided to use a "forwarding" email address?

That seems silly.

Just like how regular developers shouldn't be able to push work in to a cloud that'll end up costing tens or hundreds of thousands of dollars without deliberate, thought out reasoning, random people in a company should not be able to set up outgoing email using a company's domain without good reasoning.

If a person or a group were responsible for outgoing email, then nobody would be allowed, nor should they be able, to send without going through that person / group. Problem solved!

But if you think it's OK for any random person at an organization to just set up whatever kind of outgoing email they want, well, you get what you expect.

In fact, I would argue that you MUST assume that at least some non-trivial percentage of those other organizations are actually fucked up with regards to one or more of these areas.

So, therefore, you must be even more conservative than you might otherwise have been. Even if everyone on the planet is a CMM-5 level organization, you're still going to lose the odd space shuttle or two. And maybe also some rockets.

The forwarding problem has been with us since Internet e-mail was first created, and I don't see that problem going away. Ever.

All you can do is decide how you're going to handle that for your own accounts where you set up forwarding, which may very well break e-mail coming from domains that don't fully understand the problem.