Hi all! Long time no talk :) I'm using base-04 and BCP-03 for the
following feedback.
I just finished my DMARC implementation for the next major rev of our
mail server/list server and took some notes along the way to pass back
to the community. Having just looked at this for the first time very
recently (mostly due to Yahoo p=reject) I want to say that this was a
treat to code and I thought the spec was well written. I had a lot of
fun with this (yes, I'm a nerd). The BCP doc was also extremely helpful
in explaining many of the XML nodes and providing guidance. Please
don't give up on that as old programmers like me need to understand with
as many examples as possible what proper XML construction should look
like as validation that the more formal schema (like Appendix C of the
base document) has been understood correctly.
I've looked over the archive but forgive me if I'm dredging up old
issues already resolved.
1. Sec 2.4 - This section states "This first version of DMARC supports
only a single reporting format." But DMARC has XML, AFRF, and IODEF.
Aren't these all reporting formats?
2. Sec 4 - This section talks about domain owners who don't want (for
example) to have SPF results considered as part of a DMARC check. "If
the results of path authorization checks ought not be considered...then
the Domain Owner does not publish an SPF policy record that can produce
an SPF pass result." Since it would be silly (I assume but maybe not?)
to publish an SPF record that intentionally fails this amounts to saying
"just don't use SPF" doesn't it? Is that OK and what you want to say?
Why doesn't DMARC have its own tag/value to indicate that SPF results
should not be considered?
3. Sec 7.1 - This section has a SHOULD that must be changed to a MUST
IMO :) Otherwise there's an abuse vector there. The mechanism
described in this section works as far as I can tell so I don't get why
this is a SHOULD.
4. Sec 7.1 - OK this is somewhat a personal preference. I wish that
step 8 would add some text to state that a new rua= / ruf= must have
only one URI in it. It makes sense to me to replace a single old URI
with a single new URI. But to replace a single old URI with multiple
new ones is more complicated for implementers (who cares I know :) In
the case of mailto URI's anyway a single email address can reference a
mailing list and get as many as you want that way. But, I would like to
hear what others think on this (besides the fact that I'm a lazy
programmer ha ha).
5. Sec 11.2.1 - This section states "In the case of a "mailto" URI, the
Mail Receiver MUST communicate reports using the method described in
[STARTTLS] whenever it is offered by a Report Receiver. I think this
should be a SHOULD because just as Report Receivers might not offer
STARTTLS, some Mail Receivers might not support it either and for the
same reasons. And its not enforceable. If the Report Receiver offers
STARTTLS and the Mail Receiver ignores it what is the Report Receiver
supposed to do? Refuse the reports? And is the Mail Receiver supposed
to drop the connection when it sees a STARTTLS to which it knows it can
not (for whatever reason) comply? Just something to think about.
6. Sec 11.2.1 - "...or "xml.gz" for an XML file compressed using GZIP"
- in practice nobody that I've seen so far is doing this. So far, of
all the reports I've received the filename is nearly always just ".ZIP"
and the media type also varies. In fact the only one I've not seen is
"application/gzip" which the spec calls for. Being as this is all over
the map maybe we should at least reduce the MUST to a SHOULD for the
extension.
7. 14.1 - Just to point out - the aggregate reports contain IP
addresses and during my implementation and before I white-listed
internal IP ranges some of my management team saw sample reports which
included local internal IP addresses and assumed that these would be
sent outside the org. Unfortunately, many suffer from the Earth-Sea
Trilogy syndrome that Ned talked about in which its believed that
knowing the name of a thing somehow confers power over the thing
named. Many believe (I don't know if its true so I don't fight back on
it) that publishing internal IP topography to those outside your org is
dangerous. Anyway, I don't know if something needs to be mentioned on
that or not. What is best advice on this? There's a single line in BCP
section 12 which just says "IP Addresses in reports."
8. Sec 16.1 (or likely the BCP) should explain better how
Authentication-Results is used with plenty of use-case examples. I'm
still not sure I'm doing it right. For example, what does an AR look
like when the pct= causes a sampled_out situation? Does AR need to
indicate anything along the lines of policyoverrides like the aggregate
report does? Basically, I'm not crystal clear on what this is
documenting/communicating so I'm unsure that I have it right.
9. Appendix C - it looks like the "fo" tag is required by my reading
there. But I don't think this is necessary. The type of reporting to
which that tag is related is entirely optional. So this reduces to just
a check to make sure your parser pulled out the correct value. I know
there are other optional tags which are required by the schema but each
of those have more relevance. Its fine to require it but it will always
just be the default if the DMARC record publisher fails to specify
otherwise or a value that means nothing if the report generator ignores
ruf= type of reports. I'm not sure I'm understanding this point correctly.
Thanks for reading and please don't blast me now that my ignorance is on
full display - anyway, that's my wife's job.
Would be nice to see you all and catch up :) Hope everyone is well.
Arvel
Alt-N Technologies, Ltd
http://www.altn.com
Disclaimer: This transmission (including any attachments) may contain
confidential information, privileged material (including material protected by
the solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
