wording tweaks

SECURITY.md

@@ -30,27 +30,34 @@ issue to only the reporter and the project's security team.
 
 ### Reporting Requirements
 
-1. The report must have a detailed description of the issue so the security
-   team members can understand the issue.
-2. The report should have a valid minimal test case to reproduce the issue.
+1. The reporter should take great care in ensuring the security vulnerability
+   report is valid and accurate.  The reporter must understand reviewing
+   security vulnerability reports is a time consuming process and the c-ares
+   security team are volunteers.  A vast majority of vulnerability reports
+   we receive are invalid.  Please don't waste their time.
+2. The report must have a detailed description of the issue or issues.
+3. The report should have a valid minimal test case to reproduce the issue.
   a. Any code in a test case that isn't relevant to reproducing the issue
      ***must*** be removed.
-  b. The test case must compile cleanly with warnings enabled, for clang/gcc
-     at a minimum, `-Wall -W`.
-  c. The reporter must validate the API being called is being used in an
-     appropriate manner, in accordance with common C practices. e.g.:
+  b. The test case ***must*** compile cleanly with warnings enabled, for
+     clang/gcc at a minimum, `-Wall -W`, or `/W3` for MSVC.
+  c. The reporter ***must*** validate the API being called is being used in an
+     appropriate manner, in accordance with common C best practices and
+     requirements. e.g.:
     i.   If an API takes a C string, that means the input must be a valid C
          string (e.g. NULL terminated).
     ii.  Must not cast incompatible data types to silence compiler warnings
-         (likely generated by 2b above) as this will cause undefined behavior.
-         Use the right data types. (e.g. `struct ares_txt_reply *` can't be cast
-         to `ares_dns_record_t *`, they are different types).
+         (possibly generated by complying with 3b above) as this will cause
+         undefined behavior.  Use the right data types. (e.g.
+         `struct ares_txt_reply *` can't be cast to `ares_dns_record_t *`, they
+         are different types).
     iii. Make sure to free/destroy any c-ares generated objects using the
          correct function as documented in the man page of the function that
          generated the object (e.g. use `ares_free_hostent()` to free
-         a `struct hostent *`, not `ares_data_free()`).
-3. The report should include a stacktrace/backtrace of the issue.
-4. Include this statement in the email text when submiting a report:
+         a `struct hostent *` created by `ares_parse_ptr_reply()`, not
+         `ares_free_data()`).
+4. The report should include a stacktrace/backtrace of the issue if possible.
+5. Include this statement in the email text when submiting a report:
 ```
 I acknowledge I have read and complied with the security reporting requirements
 as described in https://c-ares.org/security.html