Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

["John Levine" <[e-mail]>]

>> bigbank.com txt "v=spf1 +ip4:22.22.22.22 ?ip4:157.55.158.0/23 
>> ?ip4:157.55.234.0/24 ?ip4:157.56.112.0/24 ~all"
>
>example.com ------------+
>                        |
>BigBank.com ------------+----> Microsoft Forefront IPs ----> Internet
>                        |
>Learning.edu            |
> [e-mail] --+
>
>Case 1 - Mail comes from 22.22.22.22 -> Forefront scans it

Oh, no, I had in mind customers who send mail through Forefront, but
also send some of their own mail directly from 22.22.22.22.  If it all
goes through Forefront, it all gets Forefront's ?ip SPF rules.

>Case 2 - Mail comes from 1.2.3.4 (Learning.edu malicious spoof) -> Forefront scans it and it SPF fails -> Relays to Internet (e.g.,
>Hotmail) who scans it and it is Neutral
>
>But real mail from BigBank.com would have a DKIM header and so therefore it would DMARC pass at the Hotmail side.
>
>Is that right?

Right.

>But wouldn't it mean that a 3rd party who didn't validate DKIM or DMARC would always get SPF Neutral in the case of a legitimate message?

Right.  Since we know the same IP can emit both real and bogus
messages and SPF can't tell the difference, what other result could
you honestly provide?  Is it really a good idea to return an SPF pass
for a message that might be a phish?

>> Or you can sign all your mail with DKIM, publish no SPF at all, and use DMARC p=reject.
>
>I've thought of that, too. I think that would be a good solution if DMARC compliance was more widespread than it is

>From a security point of view, it's really the same as what you have
now, since you can't count on the bounce address as an identifier nor
SPF to tell you whether a message is authorized.

>I've thought of that, too. But I heard ADSP was basically dead and superseded by DMARC.

ADSP is kaput.  No great loss.

It seems to me that you have an opportunity here for some client
behavior modification that can be applied incrementally.

If you don't know what domains a client uses, you can't make any
meaningful path authorization assertions.  (I don't want to think
about who gets the blame when you send those SPF approved phishes.)

But when a client gives you their list of domains, you can then filter
their mail to only allow those domains in their mailstream, and more
important, filter all your other clients' mail to forbid them.  Now
you have your paths back under control, and you can publish SPF
records for that client that provide pass results.  That's a feature
that adds customer value or whatever it's called these days.

R's,
John