Paul Wouters has entered the following ballot position for draft-ietf-dmarc-aggregate-reporting-28: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section states: If a report generator needs to re-send a report, the system MUST use the same filename as the original report. This would allow the receiver to overwrite the data from the original, or discard second instance of the report. It seems dangerous to use file names based on received strings from unknown sources, and I don't think an RFC should recommend to use such strings as filenames, unless proper warnings are in place to exclude harmful ones (eg "../../../"). While a maliciously formatted unique-id should be rejected per this specification, perhaps add a warning in the Security Considerations for this to give explicit warning to implementers. While I think "dot dot slash dot dot slash etc passwd" seems less likely to be writable by the mail user, this could be used to stuff files into the mail system (eg /var/mail or any of the outgoing mail queues) _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
