NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

Please see the NTP Security Notice for vulnerability and mitigation details.

---

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

However, there are a number of documents which appear to be more or less relevant to the topic of governing what policies and procedures may be applied to official IETF mailing lists, and it is difficult to know whether or not we have found them all. Here's the list of documents we've found so far:

• RFCs
  • RFC 2026 - The Internet Standards Process -- Revision 3
  • RFC 2418 - IETF Working Group Guidelines and Procedures
  • RFC 3005 - IETF Discussion List Charter
  • RFC 3683 - A Practice for Revoking Posting Rights to IETF Mailing Lists
  • RFC 3933 - A Model for IETF Process Experiments
  • RFC 3934 - Updates to RFC 2418 Regarding the Management of IETF Mailing Lists
  • RFC 4633 - Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists
• IESG Statements
  • Guidance for spam control on IETF mailing lists
    • Older version at https://www.ietf.org/IESG/STATEMENTS/mail-submit-policy-20020313.txt
  • IESG guidance on the moderation of IETF Working Group Mailing Lists
  • IESG Statement on disruptive posting

We have reviewed all known guidelines and requirements for operating an official IETF mailing list, and we believe that we are in compliance with the minimum required standards, as well as implementing many of the more stringent "recommended" practices.

The two most current and relevant documents appear to be Guidance for spam control on IETF mailing lists and IESG guidance on the moderation of IETF Working Group Mailing Lists. Let's go through these two documents:

Guidance for spam control on IETF mailing lists.

We do use automated anti-spam mechanisms, so the first section that is relevant for us reads:

   If an automated spam detector is used, it should take several factors
   into account.  These include, in decreasing order of importance:

   a.  Whether or not the purported sender is a subscriber to the
       mailing list.  This alone SHOULD NOT be relied upon as evidence
       that a message isn't spam, given the prevalence of "joe jobs"
       (spam that impersonates real users) and spam-sending worms.  Note
       that the following addresses MUST always be considered to be
       subscribers for this purpose: internet-drafts@ietf.org,
       rfc-editor@rfc-editor.org, iesg-secretary@ietf.org,
       chair@ietf.org, iana@iana.org.  It should also be possible for a
       subscriber to provide one or more alternate addresses, to be
       treated the same as their subscription address for this purpose.

       It is not accepable to simply drop messages from non-subscribers.

   b.  The likelihood that the message is spam, based on textual
       evidence, statistical filters, and the like.  Note the danger
       here of false positives;

   c.  Past behavior by that particular sending IP address;

• Item "a" appears to be primarily a statement regarding white lists and whether or not the sender is subscribed to the mailing list, which specific IETF addresses must always be allowed to post to any official IETF mailing list, etc....
  • We have white listed the above addresses
  • We do not reject messages from non-subscribers
    • Instead, they are put into the moderation queue and dealt with manually (see below)
• Item "b" appears to be about the use of statistical and rule-based automated processing systems, which we do use
  • We are very conservative overall with our settings on these tools, so as to try to guarantee that we avoid the "false positive" problem site-wide
• Item "c" may be about the use of dynamic or static black lists, which are created based on past "spam" behaviour of the sending IP address
  • We do use some black lists, but we are very conservative in choosing which black lists to use, and we try to be as accomodating as possible when someone reports to us a problem with one of the black lists we consult
    • We are in the process of building a new mail system which will allow us to apply "scores" to many different black lists, so that we can consult a wider variety of potentially useful information sources while avoiding making a binary decision based on a single source

   In other cases, it MUST be possible for the sender of a legitimate
   message, whether a mailing list subscriber or not, to determine if it
   is has been dropped as apparent spam.  This can be done in several
   ways; all of these have their advantages and disadvantages.

   a.  Provide a Web-accessible archive of postings rejected in the past
       few days.  Few, if any, current mailing list packages currently
       do this, though some spam filters can easily be configured to do
       so.  One tool written with this problem in mind is available at
       <https://www.hactrn.net/hacks/spamtools/spamindex.pl>.  This
       alternative is RECOMMENDED.

   b.  Provide an up-to-date archive of accepted postings.
       Unfortunately, while this can show dropped messages, it doesn't
       help if the email is merely delayed, nor does it say why a
       message was dropped.  This MAY be used.

   c.  Have the receiving MTA scan the message and send a 500-class
       rejection to the DATA command.  This can lead to mailer timeouts
       and retransmissions.  This MAY be used, but (b) is a better
       alternative.

   d.  Email back a rejection message.  In the event of forged spam --
       and there's a lot of it -- this can lead to denial of service
       attacks on the purported sender.  This SHOULD NOT be done.

• Item "a" appears to indicate certain methods of operation regarding the mailing list manager and the MTA which is not commonly found in any modern mailing list manager we know of
  • Due to lack of technical feasibility, we do not do this
• Item "b" seems to reference public archives, which are kept up-to-date
  • We already do this
    • Our understanding is that all official IETF mailing lists must have public archives which are kept up-to-date, and therefore this item would seem to be redundant in this context
• Item "c" appears to reference doing the anti-spam scanning while the sending MTA is held open and refusing the message interactively
  • We do this
    • To the ability that is possible within our automated anti-spam processing tools that are integrated into the MTA
      • We cannot do this from within Mailman itself, due to the only method of integration with the MTA that is supported by Mailman
• Item "d" is in reference to rejecting the message after it has been received
  • We do not generally do this, but the final decision rests with the moderator of the mailing list
    • In certain cases, it may appear that the message was otherwise legitimate but had to be rejected due to excessive size, or being off-topic, etc... and this is left to the discretion of the moderator

IESG guidance on the moderation of IETF Working Group Mailing Lists

We use moderation extensively on our mailing lists, so this document is relevant to us. We do not believe it is necessary to include selections of the text from this document, because it is shorter and less complex than the previous document we have examined here

• Item "1" says that the ADs must approve any mailing list that is to be completely moderated
  • This list is only partially moderated -- we do not attempt to moderate all posts
    • We make every attempt to check the moderation queue of each mailing list on a "timely" basis
      • Usually at least once a day
      • Frequently at least twice per day
    • Posts from non-subscribers will be moderated
    • Posts from new subscribers will be moderated
      • Until such time as they demonstrate that they are a real human being and that they are capable of posting messages that are at least minimally on-topic, then their "moderated" bit will be cleared
    • Posts that have been marked by the automated anti-spam mechanisms as being suspicious in nature may be moderated
      • If the system was pretty sure that the message was spam, it would have been refused before the message got to the mailing list
• Item "2" says that the WG should be kept up-to-date regarding the moderation policy of the list
  • We include information in the initial "welcome" message that is sent to new subscribers, and we also maintain central web pages where this information is located
  • We also include this information in the "listinfo" page for this mailing list at https://lists.ntp.org/mailman/listinfo/ntpwg
    • If the IETF desires, we can also arrange for a monthly message to be sent out to all subscribers
• Item "3" says that all messages must be accepted or rejected as a whole and cannot be edited for content
  • We do this
    • We make no attempt to edit for content within a message
• Item "4" says that if a message is rejected then a short rejection notice should be sent to the poster
  • We do this
    • We leave the exact content of the rejection notice up to the moderator
• Item "5" says that rejected notes should be saved for a reasonable period of time, in case of dispute
  • We do this

There are also other documents which are relevant to the content posted on the mailing lists, specifically with regard to the Intellectual Property Rights, and before joining the Working Group, all posters must acknowledge that their messages (and other input) complies with these requirements:

• RFC 3669 - Guidelines for Working Groups on Intellectual Property Issues
• RFC 3979 - Intellectual Property Rights in IETF Technology

We make no claims that the content posted to this mailing list is in compliance with these requirements -- that is the responsibility of the poster. However, we do make this information available here so that the WG members and prospective WG members can see these documents and ensure that they are in compliance.

-- BradKnowles - 26 Dec 2007