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

Thanks for the responses, everyone. I am going to respond to them one at a time but combine multiple email responses.

John Levine:

> 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"

BigBank.com puts both Frontbridge/Forefront's IPs into its SPF records as well as its own IPs. We validate BigBank.com's IPs when it hits us the first time, and then 3rd parties validate our IPs when it hits them. 

But yes, I think you understand our issue (I think).

> 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.)

You are correct that you lose the path independence. But it is incorrect to say you gain nothing - you gain the ability to say "Nobody else can spoof me." Shouldn't it be the choice of the sender whether or not they want to make this assertion and subsequent trade-off?

-- Terry

-----Original Message-----
From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of John Levine
Sent: Monday, April 01, 2013 4:02 PM
To: dmarc@ietf.org
Cc: dcrocker@gmail.com
Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

>If I understand your note correctly, the problem that you cite with 
>this is that Forefront doesn't know all of the acceptable domains for a 
>given customer.  Wouldn't it make more sense to fix this issue, rather 
>than change the public standard and burden all recipients with the 
>added complexity in software and operations?

That's also a good idea.  

It'd make sense to change the SPF records now, then if they can fix the internal systems so that they have the domains on injected mail under control, they could change the SPF back to make stronger assertions.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc