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.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
The
NTP Project also hosts one IETF mailing list, specifically for the
NTP Working Group, for which the mailing list is located at
https://lists.ntp.org/mailman/listinfo/ntpwg and our TWiki Web is at
https://support.ntp.org/bin/view/IETF/WebHome.
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:
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:
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
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
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:
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