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

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

>Extending DMARC this way lets brands/domains protect their outbound reputation behind a shared service without worrying
>whether or not some other customer will spoof them.
>
>Make sense?

Well, no.

Your problem as I understand it is that you have a shared
infrastructure accessed by untrusted clients, and you want to defend
against the threat that one client sends mail impersonating another.

The DKIM signatures are secure, a client can only sign for itself, but
there's no way to map an IP address to a particular sender.

The solution here is quite simple: adjust the SPF records to reflect
what's actually going on.  An SPF pass means, approximately, yes this
message is really from the alleged sender.  But you can't say that,
you can only say that it might be or it might not be.  So an
appropriate SPF record would be something like this (using a handful
of the of Frontbridge IP ranges as an example):

bigbank.com txt "v=spf1 ?ip4:157.55.158.0/23 ?ip4:157.55.234.0/24 ?ip4:157.56.112.0/24 ~all"

Those question marks in the record on the Frontbridge ranges make them
neutral rather than pass, which is appropriate in this case.  Since
all of the real mail the client sends through your system will have a
DKIM signature, it will still pass DMARC.

If the bank has its own private ranges for its non-bulk mail, those
could go in as SPF pass, e.g.

bigbank.comm 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"

Remember that a major point of DKIM is to attach an identity to mail
that is independent of the mail's path.  DKIM currently works just
great for the usual kinds of forwarded mail.  If you insist on both
SPF and DKIM, you lose the path independence and break the forwarding
while gaining nothing, since the DKIM signature still tells you what
you need to know.  If the bank sends its own unsigned mail through its
own mail servers, the SPF record reflects that, and it'll pass DMARC,
too (give or take the known SPF forwarding issues.)

Bonus advantage of this approach: existing software supports it now,
no upgrades needed.

R's,
John