On 09/03/2013 06:27 AM, Raman Gupta wrote:
Yes, I think this is a corner case in which DMARC should not impose
the additional SPF alignment check. But given that DKIM still results
in a DMARC pass, this could just be my perfectionist nature asserting
itself. Regardless, I probably will post this use case to the IETF
dmarc list.
You're describing a situation where a receiver might well have
sufficient information to infer that a message is OK, but where
standardising the making of that inference would require a change to the
underlying protocol(s). Take for example:
HELO server.spoofer.example
MAIL FROM: <>
RCPT TO:<[email protected]>
...
From: [email protected]
The mere passing of SPF clearly can't be enough reason for a DMARC pass.
DMARC's solution to date has been the alignment rules, which provide a
very widely useful heuristic even if they both (i) are incomplete and
(ii) introduce a rather unpleasant database dependency into the
specification.
If the case that you wanted to address was that the RFC5322.From domain
would have passed SPF had its domain been in the RFC5321.MailFrom then
I'd suggest that a receiver would have a solid basis for assuming
legitimacy in this case, _*but*_:
* This requires a change to SPF (the ability to determine
authentication for the RFC5322.From domain) or for DMARC to specify
an entirely new use of SPF records. Given the history with SenderID
doing almost exactly this (re-purposing SPF records in part for
RFC5322.From: assessments), this might not be as straightforward as
one would hope.
* I suspect, although I do not have solid numbers, that the
incremental benefit from this procedure would be vanishingly small,
particularly when bounce-generators who wish to pass DMARC can
already do so with existing standards and tools by simply DKIM
signing. If a typical receiver would see a substantial improvement
and if you could prove this statistically then you might be able to
get the attention of receivers, but absent this, you're not likely to.
Given these two impediments, I'd suggest that your proposed improvement
will join the (long!) list of intellectually sound but
implementationally infeasible authentication protocols.
- Roland
--
Roland Turner | Director, Labs
TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
Mobile: +65 96700022 | Skype: roland.turner
[email protected] | http://www.trustsphere.com/
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
