On 1/23/2015 6:27 PM, Anne Bennett wrote:
** 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?
Being Specific is Terrific.
Note -12 rev has no mentioning of Received-SPF. Also note, during
SPFBIS there was an attempt (Issue #10) to deprecate Received-SPF
which was shot down. Murray was concern of having two mechanisms here.
Of course, he was also the author of the Authentication-Result header.
Anyway, it depends on the type implementations and there are many
kinds. If you starting fresh, you have the luxury to do whatever you
want. For others, its can be an expensive change endeavor and for
some (like me), they will wait until its all settled. It can also
possibly be done via private meta-data when the 5322 payload is saved
for mail processing during DATA.
In all, we are talking about an integrated framework of a total
possible four or even seven components and the possible variations:
SMTP
SPF, SUBMITTER
DKIM
ADSP, ATPS
DMARC
If you are adding DMARC to an existing framework, it needs to decide
what it needs to use. DMARC is classified in DMARC as a "Super-ADSP."
See appendix A.5. Is this deprecated too?
IMO, if its not the developer of the SPF component, the better DMARC
implementation should expect 4408 operations. There are new designs
and plug and play considerations here. There is also new SMTP change
requirements too. This DMARC doc needs to be clear in the migration
path.
I believe you are concern about the HELO mostly. Historically, it was
an unreliable check. Very high overhead with little payoff. The
default is NO CHECKING, but I will recognize this is changing and
overall DNS lookup waste more feasible to handle across the board.
But in general, I always felt that would be a boolean TRUR or FALSE
output as a function of SPF and for implementations of all the SPF and
related protocols, like SENDER-ID, it included RFC4405 (SUBMITTER)
field as well as input to the CheckHost() function
SPF.Result = CheckHost(HELO, MAIL.FROM, MAIL.SUBMITTER)
despite Scott's adamant refusal to not recognize the existence and its
impact (SPFBIS issue #11). There are ESMTP clients do send the
SUBMITTER field in MAIL FROM for SPF processing.
Unless it can be very clear about it, how is is done, the order, etc,
is generally out of scope for IETF protocols. What is important is
that the end result is mostly the same.
IMO, DMARC is problematic when it looks for an alignment concept
because an -ALL at SMTP can preempt a DMARC process altogether, i.e.
the DATA payload will not be received/transferred. But DMARC also has
semantics for DELAYING SPF processing until the PAYLOAD is received.
IMO, that encourages waste, however, getting the REPORTING
requirements seems to be also important for many, still. Keep in
mind this redundancy will turn into waste, so even processing delay
options are provided, implementation needs should allow it to be
optimized (turned off).
Thats all optional implementation design decisions. I steer towards
optimized and scaled designs so the only data received for DMARC
processing would be transactions with:
SPF.Result = NONE|SOFTFAIL|NEUTRAL|PASS
In our implementation, DMARC will never see a -ALL failure since its
immediately rejected before DATA. So the alignment can alter the
DMARC result, not the SPF result.
If you think SMTP should have information about the DMARC policy
before DATA is reached, then we don't that ESMTP (Extended SMTP) idea
officially proposed yet.
Keep in mind, there was once a proposal on the table called CSV/DNA
that did allow for Reputation, Authentication and Authorization
Policies at the EHLO level.
Many DNS-based Email Policy applications have been proposed and
explored at various levels. DMARC is the latest one and its DOMAIN
anchor is the Author Domain. That piece of data is not at SMTP until
DATA is received.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
