[Git][debian-proftpd-team/proftpd][upstream] New upstream version 1.3.7a+dfsg
Francesco Paolo Lovergine
frankie at debian.org
Thu Dec 10 21:03:52 GMT 2020
Francesco Paolo Lovergine pushed to branch upstream at Debian ProFTPD Team / proftpd
Commits:
b57a967d by Francesco Paolo Lovergine at 2020-12-10T19:36:50+01:00
New upstream version 1.3.7a+dfsg
- - - - -
4 changed files:
- − doc/rfc/draft-bonachea-sftp-00.txt
- − doc/rfc/draft-ietf-ftpext-mlst-15.txt
- − doc/rfc/draft-ietf-ftpext-sec-consider-02.txt
- − doc/rfc/rfc0959.txt
Changes:
=====================================
doc/rfc/draft-bonachea-sftp-00.txt deleted
=====================================
@@ -1,276 +0,0 @@
-Network Working Group D. Bonachea
-<draft-bonachea-sftp-00.txt> S. McPeak
-Updates: RFC 2228
-Internet-Draft
-Expires in January, 2000 June, 1999
-
- Protocol Negotiation Extensions to Secure FTP
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
-
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Abstract
-
- This document presents refinements to RFC 2228, "FTP Security
- Extensions" (October 1997) [1]. It lends support for more efficient
- and secure protocol negotiation in the presence of multiple protocol
- possibilities, by adding one new optional command and several new
- reply codes.
-
- The following new optional command is introduced in this
- specification:
-
- DIGT (Protocol Negotiation Digest)
-
- This document also seeks to solidify several issues that were left
- underspecified in RFC 2228. Specifically, it adds additional reply
- codes to cover cases not mentioned in the original specification and
- it defines a legal naming convention for security mechanisms.
-
-
-
-
-Bonachea & McPeak [Page 1]
-
-INTERNET DRAFT Extensions to Secure FTP June 18, 1999
-
-
-1. Introduction
-
- Recently, the authors implemented the RFC 2228 protocol, FTP Security
- Extensions [1]. This protocol extends the basic File Transfer
- Protocol (FTP) specified in RFC 959 [2], adding security services
- including authentication and privacy. We assume the reader is
- familiar with RFC 2228.
-
- During the implementation of RFC 2228 we found it necessary and
- useful to make several changes to the protocol. This memo details
- those changes.
-
- Section 2 describes changes which extend RFC 2228, to improve
- security and efficiency. Section 3 closes specification holes in RFC
- 2228 itself. Section 4 lifts a RFC 959 restriction, thereby improving
- total system security.
-
-2. Protocol Negotiation Improvements
-
- DIGT (Protocol Negotiation Digest) command
-
- This new command provides a way for a client to verify that an
- attacker didn't interfere with the protocol negotiation sequence.
- This is important because a client that supports multiple security
- mechanisms might be "tricked" into using its weakest security
- mechanism by an attacker who interferes with protocol negotiation
- (i.e. by modifying the appropriate mechanism acceptance replies to
- look like refusals). The client may issue this optional command at
- any time after authentication is complete, and the server will reply
- with a secure hash digest computed over the entire protocol
- negotiation exchange. The client can then compare this digest to the
- locally computed digest to verify that both server and client
- experienced the same protocol negotiation sequence (i.e. there was no
- outside interference). The hash function is Sha1, and is computed
- over the entire negotiation sequence from the first character in the
- first client command (usually an AUTH), to the last character in the
- server reply which indicates the security data exchange is complete
- (the LF character on a 234 or 235 reply). The form of the server
- reply to DIGT will be:
-
- 211 DIGT=base64data
- ; base64data is a placeholder for the actual digest block,
- ; which must be encoded using the base64 format, as
- ; described in RFC 2228 (see [1] for details).
-
- The server may also send a 502 response if the DIGT command is not
- implemented.
-
-
-
-
-Bonachea & McPeak [Page 2]
-
-INTERNET DRAFT Extensions to Secure FTP June 18, 1999
-
-
- Note the efficacy of this security measure depends on the client
- asking for the digest faster than an attacker can compromise the
- current (weaker) security mechanism and substitute a modified digest.
-
- Efficiency improvements to protocol negotiation
-
- RFC 2228 allows for the possibility of clients and servers that
- implement a large number of security mechanisms, yet it provides no
- efficient means for the client to discover and request a supported
- mechanism. Under the RFC 2228 specification, the client repeatedly
- issues AUTH commands for each security mechanism it supports (in
- order of preference) until finding one the server will accept. For
- clients that implement a large number of mechanisms, this could
- potentially lead to an unreasonably large number of network round
- trips in order to complete the protocol negotiation sequence. In
- order to alleviate this problem, this specification adds two new
- optional server reply codes that allow the server to reveal a list of
- acceptable security mechanisms in a single reply. This enables the
- client to perform the search locally and select an acceptable
- mechanism in a single network roundtrip.
-
- The new reply codes to the AUTH command are:
-
- 504 Security mechanism unrecognized. [LIST=mechlist]
- 504 Security mechanism unrecognized. [ILST=mechlist]
-
- Here, mechlist is a space-delimited list of security mechanisms that
- the server understands and might accept from this client. The keyword
- LIST indicates that mechlist is a complete list of acceptable
- security mechanisms, and any mechanisms not listed will be refused.
- The keyword ILST indicates that mechlist is an incomplete list of
- acceptable security mechanisms, and that other acceptable unlisted
- security mechanisms might exist. The square brackets are not to be
- included in the actual reply, but indicate that the mechanism list is
- optional.
-
-3. Amendments to RFC 2228
-
- New server replies
-
- This section presents several new server reply codes which were
- missing in the original specification.
-
- 234 Security data exchange complete. [ADAT=base64data]
- ; This reply to AUTH indicates the security data exchange
- ; completed successfully. The square brackets are not to be
- ; included in the reply, but indicate that security data in
- ; the reply is optional.
-
-
-
-Bonachea & McPeak [Page 3]
-
-INTERNET DRAFT Extensions to Secure FTP June 18, 1999
-
-
- This reply code existed in RFC 2228, but did not allow for the
- possibility of the server sending security data (for protocols where
- the only data exchange necessary is for the server to send a block to
- the client).
-
- 503 Reauthentication is prohibited.
- ; This reply code to an AUTH indicates that a successful
- ; security data exchange has completed, and this server is
- ; unwilling to begin a new authentication session (the
- ; client must "hang up" and reconnect)
-
- RFC 2228 specifies that a server may prohibit the client from
- reissuing the AUTH command in order to establish new authentication,
- but provides no reply code to communicate this.
-
- PBSZ Negotiation
-
- During PBSZ (Protocol Buffer Size) negotiation, the client proposes a
- buffer size, and the server may accept this size, reply with a
- smaller size, or give an error. The size agreed upon is subsequently
- used during data transfers as a maximum bound on the size of each
- encrypted block. However, some protocol mechanisms have a minimum
- encrypted block size, and RFC 2228 doesn't provide a way for the
- server to indicate that the proposed block size is too small. To
- remedy this, this specification adds a new reply code:
-
- 538 PBSZ too small. [PBSZmin=numBytes]
- ; This reply to PBSZ indicates the proposed buffer size is
- ; unacceptably small. The server may also include an optional
- ; string of the form PBSZmin=numBytes to indicate the smallest
- ; buffer size it will accept. The square brackets are not to be
- ; included in the reply, but indicate that the PBSZmin argument
- ; in the reply is optional.
-
- Protocol Mechanism Naming Specification
-
- The guidelines provided by RFC 2228 for the naming of new protocol
- mechanisms are somewhat vague, and as such are insufficient for the
- purposes of successful protocol negotiation as described in section
- 2. Following is a revised, more rigorous specification for the
- naming of protocol mechanisms:
-
- The protocol mechanism name must not exceed 255 characters, and may
- only contain the characters with codes 33...126 in the USASCII
- character set. Names are case-insensitive. All names must be
- registered with the IANA, except names beginning with "X-", which are
- reserved for local use.
-
-
-
-
-Bonachea & McPeak [Page 4]
-
-INTERNET DRAFT Extensions to Secure FTP June 18, 1999
-
-
-4. Miscellaneous changes to RFC 2228
-
- Port 20 restriction for outgoing server data connections:
-
- RFC 2228 is a superset specification of RFC 959 [2], which defines
- the basic FTP protocol. RFC 959 requires that while in active mode,
- all outgoing data connections from the FTP server must be bound to
- port 20, as a weak form of authentication. However, most FTP clients
- fail to enforce this port restriction (i.e. they don't check).
- However, implementation experience has shown that the port
- restriction is also the only hindrance to running a legitimate RFC
- 2228 server as an entirely user-level proxy (which augments overall
- system security). Because RFC 2228 provides more comprehensive
- support for strong, cryptographic authentication mechanisms, it has
- made the port 20 restriction for outgoing server data connections
- obsolete, and the restriction is hereby lifted.
-
-5. Security Considerations
-
- This entire memo is about security mechanisms.
-
-6. References
-
- [1] - M. Horowitz and S. J. Lunt. FTP Security Extensions.
- RFC 2228, October, 1997
-
- [2] - J. Postel and J. Reynolds. File Transfer Protocol (FTP).
- RFC 959, October, 1985
-
-7. Authors' Addresses
-
- Dan Bonachea
- Computer Science Division
- 566 Soda Hall
- Berkeley, CA 94720 USA
- Phone: +1 510 642-8493
- Email: bonachea at cs.berkeley.edu
-
-
- Scott McPeak
- Computer Science Division
- 566 Soda Hall
- Berkeley, CA 94720 USA
- Phone: +1 510 642-8493
- Email: smcpeak at cs.berkeley.edu
-
-
-
-
-
-
-Bonachea & McPeak [Page 5]
=====================================
doc/rfc/draft-ietf-ftpext-mlst-15.txt deleted
=====================================
The diff for this file was not included because it is too large.
=====================================
doc/rfc/draft-ietf-ftpext-sec-consider-02.txt deleted
=====================================
@@ -1,415 +0,0 @@
-
-
-
-FTPEXT Working Group Mark Allman
-Internet Draft NASA Lewis/Sterling Software
-Expires: October, 1998 Shawn Ostermann
- Ohio University
- April, 1999
-
-
- FTP Security Considerations
- <draft-ietf-ftpext-sec-consider-02.txt>
-
-
-Status of this Memo
-
- This document is an Internet-Draft. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its areas,
- and its working groups. Note that other groups may also distribute
- working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet-Drafts as
- reference material or to cite them other than as ``work in
- progress.''
-
- To learn the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet- Drafts
- Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
- ftp.isi.edu (US West Coast).
-
- Distribution of this document is unlimited. Please send comments
- to the FTP Extension working group (FTPEXT-WG) of the Internet
- Engineering Task Force (IETF) at <ftp-wg at hethmon.com>.
- Subscription address is <ftp-wg-request at hethmon.com>.
- Discussions of the group are archived at
- <URL:http://w3.hethmon.com/ftpext/>.
-
-Abstract
-
- The specification for the File Transfer Protocol contains a number
- of mechanisms that can be used to compromise network security. The
- FTP specification allows a client to instruct a server to transfer
- files to a third machine. This third-party mechanism, known as
- proxy FTP, causes a well known security problem. The FTP
- specification also allows an unlimited number of attempts at
- entering a user's password. This allows brute force "password
- guessing" attacks. This document provides suggestions for system
- administrators and those implementing FTP servers that will decrease
- the security problems associated with FTP.
-
-1 Introduction
-
- The File Transfer Protocol specification [PR85] provides a mechanism
- that allows a client to establish an FTP control connection and
- transfer a file between two FTP servers. This "proxy FTP" mechanism
-
-Expires: April, 1999 [Page 1]
-
-draft-ietf-ftpext-sec-consider-02.txt October 1998
-
- can be used to decrease the amount of traffic on the network; the
- client instructs one server to transfer a file to another server,
- rather than transferring the file from the first server to the
- client and then from the client to the second server. This is
- particularly useful when the client connects to the network using a
- slow link (e.g., a modem). While useful, proxy FTP provides a
- security problem known as a "bounce attack" [CERT97:27]. In
- addition to the bounce attack, FTP servers can be used by attackers
- to guess passwords using brute force.
-
- This document does not contain a discussion of FTP when used in
- conjunction with strong security protocols, such as IP Security.
- These security concerns should be documented, however they are out
- of the scope of this document.
-
- This paper provides information for FTP server implementers and
- system administrators, as follows. Section 2 describes the FTP
- "bounce attack". Section 3 provides suggestions for minimizing the
- bounce attack. Section 4 provides suggestions for servers which
- limit access based on network address. Section 5 provides
- recommendations for limiting brute force "password guessing" by
- clients. Next, section 6 provides a brief discussion of mechanisms
- to improve privacy. Section 7 provides a mechanism to prevent user
- identity guessing. Section 8 discusses the practice of port
- stealing. Finally, section 9 provides an overview of other FTP
- security issues related to software bugs rather than protocol
- issues.
-
-2 The Bounce Attack
-
- The version of FTP specified in the standard [PR85] provides a
- method for attacking well known network servers, while making the
- perpetrators difficult to track down. The attack involves sending
- an FTP "PORT" command to an FTP server containing the network
- address and the port number of the machine and service being
- attacked. At this point, the original client can instruct the FTP
- server to send a file to the service being attacked. Such a file
- would contain commands relevant to the service being attacked (SMTP,
- NNTP, etc.). Instructing a third party to connect to the service,
- rather than connecting directly, makes tracking down the perpetrator
- difficult and can circumvent network-address-based access
- restrictions.
-
- As an example, a client uploads a file containing SMTP commands to
- an FTP server. Then, using an appropriate PORT command, the client
- instructs the server to open a connection to a third machine's SMTP
- port. Finally, the client instructs the server to transfer the
- uploaded file containing SMTP commands to the third machine. This
- may allow the client to forge mail on the third machine without
- making a direct connection. This makes it difficult to track
- attackers.
-
-
-
-
-Expires: April, 1999 [Page 2]
-
-draft-ietf-ftpext-sec-consider-02.txt October 1998
-
-3 Protecting Against the Bounce Attack
-
- The original FTP specification [PR85] assumes that data connections
- will be made using the Transmission Control Protocol (TCP) [Pos81].
- TCP port numbers in the range 0 - 1023 are reserved for well known
- services such as mail, network news and FTP control connections
- [RP94]. The FTP specification makes no restrictions on the TCP port
- number used for the data connection. Therefore, using proxy FTP,
- clients have the ability to tell the server to attack a well known
- service on any machine.
-
- To avoid such bounce attacks, it is suggested that servers not open
- data connections to TCP ports less than 1024. If a server receives
- a PORT command containing a TCP port number less than 1024, the
- suggested response is 504 (defined as "Command not implemented for
- that parameter" by [PR85]). Note that this still leaves non-well
- known servers (those running on ports greater than 1023) vulnerable
- to bounce attacks.
-
- Several proposals (e.g., [AOM98] and [Pis94]) provide a mechanism
- that would allow data connections to be made using a transport
- protocol other than TCP. Similar precautions should be taken to
- protect well known services when using these protocols.
-
- Also note that the bounce attack generally requires that a
- perpetrator be able to upload a file to an FTP server and later
- download it to the service being attacked. Using proper file
- protections will prevent this behavior. However, attackers can also
- attack services by sending random data from a remote FTP server
- which may cause problems for some services.
-
- Disabling the PORT command is also an option for protecting against
- the bounce attack. Most file transfers can be made using only the
- PASV command [Bel94]. The disadvantage of disabling the PORT
- command is that one loses the ability to use proxy FTP, but proxy
- FTP may not be necessary in a particular environment.
-
-4 Restricted Access
-
- For some FTP servers, it is desirable to restrict access based on
- network address. For example, a server might want to restrict
- access to certain files from certain places (e.g., a certain file
- should not be transferred out of an organization). In such a
- situation, the server should confirm that the network address of the
- remote hosts on both the control connection and the data connection
- are within the organization before sending a restricted file. By
- checking both connections, a server is protected against the case
- when the control connection is established with a trusted host and
- the data connection is not. Likewise, the client should verify the
- IP address of the remote host after accepting a connection on a port
- opened in listen mode to verify that the connection was made by the
- expected server.
-
-
-
-Expires: April, 1999 [Page 3]
-
-draft-ietf-ftpext-sec-consider-02.txt October 1998
-
- Note that restricting access based on network address leaves the FTP
- server vulnerable to "spoof" attacks. In a spoof attack, for
- example, an attacking machine could assume the host address of
- another machine inside an organization and download files that are
- not accessible from outside the organization. Whenever possible,
- secure authentication mechanisms should be used, such as those
- outlined in [HL97].
-
-5 Protecting Passwords
-
- To minimize the risk of brute force password guessing through the
- FTP server, it is suggested that servers limit the number of
- attempts that can be made at sending a correct password. After a
- small number of attempts (3-5), the server should close the control
- connection with the client. Before closing the control connection
- the server must send a return code of 421 ("Service not available,
- closing control connection." [PR85]) to the client. In addition, it
- is suggested that the server impose a 5 second delay before replying
- to an invalid "PASS" command to diminish the efficiency of a brute
- force attack. If available, mechanisms already provided by the
- target operating system should be used to implement the above
- suggestions.
-
- An intruder can subvert the above mechanisms by establishing
- multiple, parallel control connections to a server. To combat the
- use of multiple concurrent connections, the server could either
- limit the total number of control connections possible or attempt to
- detect suspicious activity across sessions and refuse further
- connections from the site. However, both of these mechanisms open
- the door to "denial of service" attacks, in which an attacker
- purposely initiates the attack to disable access by a valid user.
-
- Standard FTP [PR85] sends passwords in clear text using the "PASS"
- command. It is suggested that FTP clients and servers use alternate
- authentication mechanisms that are not subject to eavesdropping
- (such as the mechanisms being developed by the IETF Common
- Authentication Technology Working Group [HL97]).
-
-6 Privacy
-
- All data and control information (including passwords) is sent
- across the network in unencrypted form by standard FTP [PR85]. To
- guarantee the privacy of the information FTP transmits, a strong
- encryption scheme should be used whenever possible. One such
- mechanism is defined in [HL97].
-
-7 Protecting Usernames
-
- Standard FTP [PR85] specifies a 530 response to the USER command
- when the username is rejected. If the username is valid and a
- password is required FTP returns a 331 response instead. In order
- to prevent a malicious client from determining valid usernames on a
- server, it is suggested that a server always return 331 to the USER
-
-
-Expires: April, 1999 [Page 4]
-
-draft-ietf-ftpext-sec-consider-02.txt October 1998
-
- command and then reject the combination of username and password for
- an invalid username.
-
-8 Port Stealing
-
- Many operating systems assign dynamic port numbers in increasing
- order. By making a legitimate transfer, an attacker can observe the
- current port number allocated by the server and ``guess'' the next
- one that will be used. The attacker can make a connection to this
- port, thus denying another legimate client the ability to make a
- transfer. Alternativly, the attacker can steal a file meant for a
- legitimate user. In addition, an attacker can insert a forged file
- into a data stream thought to come from an authenticated client.
- This problem can be mitigated by making FTP clients and servers use
- random local port numbers for data connections, either by requesting
- random ports from the operating system or using system dependent
- mechanisms.
-
-
-9 Software-Base Security Problems
-
- The emphasis in this document is on protocol-related security
- issues. There are a number of documented FTP security-related
- problems that are due to poor implementation as well. Although the
- details of these types of problems are beyond the scope of this
- document, it should be pointed out that the following FTP features
- has been abused in the past and should be treated with great care by
- future implementers:
-
- Anonymous FTP
-
- Anonymous FTP refers to the ability of a client to connect to an
- FTP server with minimal authentication and gain access to public
- files. Security problems arise when such a user can read all
- files on the system or can create files. [CERT92:09] [CERT93:06]
-
- Remote Command Execution
-
- An optional FTP extension, "SITE EXEC", allows clients to
- execute arbitrary commands on the server. This feature should
- obviously be implemented with great care. There are several
- documented cases of the FTP "SITE EXEC" command being used to
- subvert server security [CERT94:08] [CERT95:16]
-
- Debug Code
-
- Several previous security compromises related to FTP can be
- attributed to software that was installed with debugging
- features enabled [CERT88:01].
-
- This document recommends that implementors of FTP servers with these
- capabilities review all of the CERT advisories for attacks on these
- or similar mechanisms before releasing their software.
-
-
-Expires: April, 1999 [Page 5]
-
-draft-ietf-ftpext-sec-consider-02.txt October 1998
-
-10 Conclusion
-
- Using the above suggestions can decrease the security problems
- associated with FTP servers without eliminating functionality.
-
-Acknowledgments
-
- We would like to thank Alex Belits, Jim Bound, William Curtin,
- Robert Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their
- helpful comments on this paper. Also, we thank the FTPEXT WG
- members who gave many useful suggestions at the Memphis IETF
- meeting.
-
-References
-
- [AOM98] Mark Allman, Shawn Ostermann, Craig Metz. FTP Extensions
- for IPv6 and NATs, September 1998. RFC 2428.
-
- [Bel94] Steve Bellovin. Firewall-Friendly FTP, February 1994. RFC
- 1579.
-
- [CERT88:01] CERT Advisory CA-88:01. ftpd Vulnerability. December,
- 1988 ftp://info.cert.org/pub/cert_advisories/
-
- [CERT92:09] CERT Advisory CA-92:09. AIX Anonymous FTP Vulnerability.
- April 27, 1992. ftp://info.cert.org/pub/cert_advisories/
-
- [CERT93:06] CERT Advisory CA-93:06. Wuarchive ftpd Vulnerability.
- September 19,1997 ftp://info.cert.org/pub/cert_advisories/
-
- [CERT94:08] CERT Advisory CA-94:08. ftpd Vulnerabilities. September
- 23, 1997. ftp://info.cert.org/pub/cert_advisories/
-
- [CERT95:16] CERT Advisory CA-95:16. wu-ftpd Misconfiguration
- Vulnerability. September 23, 1997
- ftp://info.cert.org/pub/cert_advisories/
-
- [CERT97:27] CERT Advisory CA-97.27. FTP Bounce. January 8,
- 1998. ftp://info.cert.org/pub/cert_advisories/
-
- [HL97] M. Horowitz and S. J. Lunt. FTP Security Extensions,
- October 1997. RFC 2228.
-
- [Pis94] D. Piscitello. FTP Operation Over Big Address Records
- (FOOBAR), June 1994. RFC 1639.
-
- [Pos81] J. Postel. Transmission Control Protocol, September 1981.
- RFC 793.
-
- [PR85] J. Postel and J. Reynolds. File Transfer Protocol (FTP),
- October 1985. RFC 959.
-
- [RP94] J. Reynolds and J. Postel. Assigned Numbers, October 1994.
- RFC 1700. http://www.iana.org.
-
-Expires: April, 1999 [Page 6]
-
-draft-ietf-ftpext-sec-consider-02.txt October 1998
-
-
-Author's Addresses:
-
- Mark Allman
- NASA Lewis Research Center/Sterling Software
- 21000 Brookpark Rd. MS 54-2
- Cleveland, OH 44135
- mallman at lerc.nasa.gov
-
- Shawn Ostermann
- School of Electrical Engineering and Computer Science
- Ohio University
- 416 Morton Hall
- Athens, OH 45701
- ostermann at cs.ohiou.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires: April, 1999 [Page 7]
-
=====================================
doc/rfc/rfc0959.txt deleted
=====================================
The diff for this file was not included because it is too large.
View it on GitLab: https://salsa.debian.org/debian-proftpd-team/proftpd/-/commit/b57a967de6ea4c3651983287264733c848d196e1
--
View it on GitLab: https://salsa.debian.org/debian-proftpd-team/proftpd/-/commit/b57a967de6ea4c3651983287264733c848d196e1
You're receiving this email because of your account on salsa.debian.org.
More information about the Pkg-proftpd-maintainers
mailing list