I seem to have wandered into a bit of a minefield. :-/
Obviously I like Murray's proposed changes, since they're
based on mine :-), but I see that he has added "typically"
in a couple of places... and I begin to understand why it's
necessary to waffle somewhat.
** What is interoperability in this context? **
Interestingly, Murray explains that changes "will be limited to
correcting serious problems that would prevent current DMARC
implementations from interacting properly". If I may be a
bit pedantic for a moment, it doesn't look as though DMARC
implementations interact (with each other) at all. Rather,
as mail receivers, they "interact" with values published in
the DNS by mail senders.
In that light, one could argue that a problem which prevents
a sending domain from predicting what "pass/fail/none" result
a DMARC-compliant receiver will assign to its messages, is a
problem which "prevents proper interaction".
Unfortunately, since this effort is one to document what's out
there now, and since (it's slowly becoming clear to me) not
all DMARC implementations produce the same evaluation results,
it's impossible to define the DMARC mechanism unambiguously.
Murray would like the "goal posts [to] sit still for a while",
but I think the goal posts are behaving more like waves than
like particles!
** A technical problem: how many results from SPF? **
[SPF] defines a test which is recommended to be applied to
two separate identifiers (HELO and MAIL FROM), where the receiver
can consider the results of each test independently. (However,
I can publish only one SPF record for a name - that is, I cannot
say "my policy is *this* if the name is used for HELO, but my
policy is *that* if it is used in MAIL FROM". But that's not a
topic for this list.)
Along comes DMARC, which expects to receive *one* result from
"the SPF test", but there are *two* possible SPF tests. Scott
takes the position that this doesn't much matter, and for all
I know he may be right in practice, but from the point of view
of the poor sod trying to figure out what will happen when she
publishes SPF and DMARC records, it sure makes life difficult.
I doubt we're going to be able to do much better than the
proposed "-13" (or something very similar) with respect to HELO,
but at least it raises the issue instead of leaving people like
me perplexed, and it admits that there's more than one way a
DMARC implementation could choose to use (or ignore!) the two
SPF results.
** A "political" issue: how is receiver policy determined? **
Scott points out, with respect to the SPF RFCs, that the results
of each SPF check are unambiguous, that "The almost complete
lack of receiver policy specification in RFC 4408 (and RFC 7208)
is not an oversight. It was a deliberate design choice", and
that "[Franck's] mistake [is] to insist that there be one and
only one defined way to deal with SPF results from both HELO
and Mail From and there isn't".
All of this is fair enough and true, but some of it is
tautological: the receiver can do as it pleases, and no one can
stuff an unwanted e-mail message down someone else's throat.
I suspect I can choose to refuse all mail on Tuesdays if I want
to, so certainly I can do whatever I wish with SPF results.
I think that discussion about who determines the receiver's
policy misses the point. The current draft even states that
"Final disposition of a message is always a matter of local
policy".
The point, IMHO, is that when I publish DMARC and SPF and
DKIM records, I should be able to reliably predict whether
a given message will result in a DMARC pass, fail, or none,
quite regardless of what the receiver will choose to do based
on that result.
It looks as though that won't happen in this go-round, no
matter what. :-(
** 4408 vs 7208 - does it matter? **
Hector points out that SPF implementations using the "obsoleted"
RFC 4408 will be around for some time, and expresses
the concern (if I understand him correctly) that if DMARC
references the newer 7208, there may be an implication that the
5322.Authentication-Result header will be expected to be present
so DMARC can "consume" it. But there's no mention of the use
of these headers in the current draft (except, in passing,
"Original-Authentication-Results"). The draft mentions using
the *results* of the SPF and DKIM tests, but not how they are
obtained, and I think that may be the right approach.
Or, Hector, are you concerned that DMARC implementations
will be expected to *provide* one or both those headers,
and if so, that this should be explicitly stated?
** The word "contradiction" **
Murray proposed this text for 4.1, based on my suggestion:
[SPF], which authenticates the domain found in an [SMTP]
MAIL command, or the domain found in the HELO/EHLO command if
the MAIL command has a null path. Note that in contradiction
to [SPF], in the context of DMARC, this latter identity is
typically only used in the case of a MAIL null path.
Franck objects to the word "contradiction", and suggests:
[SPF], which authenticates the HELO identity and the MAIL
FROM identity: the domain found in an [SMTP] MAIL command,
or the domain found in the HELO/EHLO command if the MAIL
command has a null path. Note that in the context of DMARC,
this later identity is only used.
Hmm. How about this:
[SPF], which authenticates:
- the domain found in an [SMTP] HELO or EHLO command
(the "HELO result"), and/or
- the domain found in an [SMTP] MAIL command, or the domain
found in the HELO/EHLO command if the MAIL command has a
null path (the "MAIL FROM" result).
It is not specified whether DMARC uses the "HELO result"
or the "MAIL FROM result"; implementations differ.
It certainly exposes the ugly truth. ;-)
But speaking of ugly truths, the document already allows for
differences; in section 6.7 we have:
-12> DMARC-compliant Mail Receivers typically disregard any mail handling
-12> directive discovered as part of an authentication mechanism (e.g.,
-12> ADSP, SPF) where a DMARC record is also discovered that specifies a
-12> policy other than "none". Deviating from this practice introduces
-12> inconsistency among DMARC operators in terms of handling of the
-12> message. However, such deviation is not proscribed.
** A tiny rant **
Necessary as this flexibility is if this document is to be
finished any time soon, it causes problems for a person trying
to create SPF and DMARC records in a way that will not cause
more problems than it solves! While it's tempting to stay away
from this stuff until it all settles down, that's becoming more
difficult, and not only because my parent domain at work might
be poised to publish a DMARC record which could interfere with
my domain's outgoing mail. Even at home, a few months ago,
Gmail started tagging my outgoing mail as spam, and when I
tried to troubleshoot this, their "why is this spam" web page
essentially insisted that I publish an SPF record before going
any further!
(end of rant)
It's only fair to admit that despite my frustration, I'm
grateful for all the work being done on these issues, both to
combat spam, and to document what on earth is going on.
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
[email protected] +1 514 848-2424 x2285
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
