On 04/10/2018 01:04 AM, Brandon Long wrote: > We've also seen various banks and other large companies who seem to > specifically only > use SPF with DMARC, as a way of disallowing forwarding, I guess. > > With ARC, you can actually "pass" the SPF pass through the forwarder. > > Not that there's anywhere near wide enough acceptance of ARC to make > that your default.
Hmm, I seem to remember even Google (who IIRC pushed for ARC, but you know better than me) doesn't open ARC to third-party forwarders? Also, ARC requires a relationship of trust between the forwarder and the forwarded-to, if I remember correctly? So that couldn't reasonably work for us, as we redirect to a few thousands different domains, so something that requires explicit agreement with each forwarded-party would likely never work. > Rewriting or rejecting. I tend to favor rewriting, but arguments can be > made both ways. Assuming the > forwarding service is something set up by the receiver, than they almost > certainly would prefer to > get the mail. > > As for whether DMARC should have allowed SPF, there were several policy > proposals based > on DKIM directly that failed. DMARC added three things to those, From > header alignment, reportting > and SPF. Which of those made it more successful than the previous > attempts, or was it just the parties > involved in creating it, the timing, the need getting big enough... who > knows. Well, reporting and From header alignment make a lot of sense, I just don't get why SPF. The aim of DMARC is to ensure a message originated where it originated from, so what's the point in SPF when DKIM's available? The only reason I could think of would be protection against replay attacks, but that's taken care of by Message-Id and de-duplication filters. Well, anyway, that's wishful thinking on my part, unless there's a DMARC v2 that disallows SPF-only and some major email provider drops support for DMARC v1 in favor of v2 only there won't be any change, and that's not really likely to happen any time soon, so… > Brandon > > On Mon, Apr 9, 2018 at 3:35 PM Leo Gaspard via mailop <mailop@mailop.org > <mailto:mailop@mailop.org>> wrote: > > On 04/09/2018 08:45 PM, Jesse Thompson wrote:> Kinda, yes. Anyone > running a non-compliant list server should look to > > how other list servers are making themselves compliant. Could be... > > 1) rewrite headers > > 2) not break DKIM > > 3) ARC? > > I don't want to be overly prescriptive (no one in academia likes to be > > told what to do) but rather to let people know that (a) change is > coming > > and it isn't scary, and (b) here are some possible changes you can > make > Slight topic change: We've seen email sent from email servers using > DMARC p=reject but with broken DKIM (basically relaying through sendgrid > but with some error in the DKIM DNS configuration, as far as I can > remember). > > We handle an email forwarder that, usually, doesn't break DKIM, so DMARC > should be fine. Except when the source mail is DKIM-invalid and the only > thing that makes all the mail not to be rejected is SPF alignment, which > we cannot fix on our side. > > What is there, as an email forwarder, that we could do to be compliant? > Currently our only guess is to rewrite headers when the email comes with > broken DKIM yet valid SPF, but even though it's OK for lists that's > unexpected from the user's point of view from forwarding services… > > Or should we just reject these mails and tell the sender to do the > things properly? doesn't work well with the end users… > > Sometimes I'm thinking DMARC should have enforced DKIM, and not allowed > to have only a match in {SPF, DKIM}, because it leads to issues like > broken-DKIM working-SPF domains not noticing things are wrong even > though they *are*… > > _______________________________________________ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
