Subject: [dmarc-ietf] DMARC spec feedback

From: Arvel Hathcock <[email-masked]>
Date: Sat, 24 May 2014 17:46:19 -0500

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.