On Monday, August 17, 2015 07:09:02 PM [email protected] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Domain-based Message
> Authentication, Reporting & Conformance Working Group of the IETF.
...
Comments:
Page 3, Section 1, para 3:
"... rejection policies on email flows can be significant ..."
I think this should read:
"... rejection policies on indirect email flows can be significant ..."
otherwise it makes no sense in this paragraph.
Page 4, Section 2.1, para 5:
Recommend replace this text:
SPF can provide two Authenticated Identifiers. The first one is the
RFC7208.HELO [RFC7208] based on the RFC5321.HELO/EHLO. The second
one is the RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom
[RFC5321] domain, or, if the RFC5321.MailFrom address is absent (as
in the case of "bounce" messages, on the domain found in the HELO/
EHLO SMTP command. DMARC uses only the SPF results for the
RFC7208.MAILFROM identifier for alignment (this is often true for
local policies outside of DMARC as well).
With:
The DMARC relevant Authenticated Identifiers that SPF provides is the
RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom
[RFC5321] domain, or, if the RFC5321.MailFrom address is absent (as
in the case of "bounce" messages, on the domain found in the HELO/
EHLO SMTP command.
I think it better keeps the focus on what's relevant to DMARC and is clearer.
Regarding the last sentence of the paragraph, I would strike it. I'm not
aware of anything would be particularly relevant to DMARC nor have I heard
anything about issues caused by SPF libraries that haven't been updated.
Page 6, section 2.2, second bullet point:
SPF may pass/SPF might pass
final paragraph:
DKIM must be/DKIM will be
Page 6, section 2.3, paragraph 2.
The length tag is, as far as I know, unused. I would propose replacing the
paragraph:
Although DKIM provides a length flag so that, in theory, content can be
appended without invalidating the signature, in practice, the length flag is
seldom used due to security issues (see Section 8.2 of [RFC6376] for
additional security considerations).
While I agree we ought to mention this for completeness, let's make it clear
that's all we're doing.
Page 10, section 3.2.2, para 2:
I think this paragraph is written backwards:
ReSenders introduce DMARC interoperability issues as content
modification invalidates DKIM signatures. SPF's ability to grant
authorization via alignment is removed as the new Recipient receives
the message from the Mediator rather than the initial organization.
ReSenders haven't introduced any interoperability issues. DMARC has. How
about:
The DMARC design does not cope with common ReSender functionality
such as content modifications that invalidate DKIM signatures and Mail From
rewriting to support SPF authentication of resent mail when the new
Recipient receives the message from the Mediator rather than the initial
organization.
Page 15 section 4.1.1.1, bullet 4:
o MTAs sending email on behalf of multiple domains may require
Domain Owners to provide DKIM keys to use DKIM to avoid SPF
alignment issues. Managing DKIM keys with a third party has
security risks which should be carefully managed.
This can generally be done through CNAMES or subdomain delegation. I've yet
to see anyone handle this situation by actually exchanging private keys across
an administrative boundry. I think it's worth discussion (so I don't proppose
text) since others may have different experiences.
Page 16, section 4.1.3.1, para 2:
A first option is to use the Original-From [RFC5703] (or X-Original-
From) header field for this purpose in various contexts (X- header
fields name are discouraged by [RFC6648]). However, handling of
Original-From (or X-Original-From) is not defined anywhere. It is
not currently used consistently or displayed to the user, and in any
situation where it is used, it is a new unauthenticated identifier
available for exploitation unless included within the scope of the
new DKIM signature(s).
Let's kill the bits about X-. We're past the third anniversary of the RFC
that suggests it's a bad idea. I think Original-From is fine, but if people
don't want to reuse that, then come up with something more descriptive than
X-.
Page 19, Section 6:
In 4.1.3.3 where it discusses header rewriting, it mentions that this might
undermine the effectiveness of DMARC. I think that qualifies as a security
consideration that should be addressed (even if only by moving most of the
existing text here with a pointer).
Hope that helps,
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
