Re: [ftpext] Question about draft-bryan-ftp-hash-07

Anthony Bryan <> Thu, 16 September 2010 05:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95C7D3A67E1 for <>; Wed, 15 Sep 2010 22:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.14
X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=-0.955, BAYES_40=-0.185]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mMALYoC3pgsl for <>; Wed, 15 Sep 2010 22:27:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E9F0F3A6AF6 for <>; Wed, 15 Sep 2010 22:27:51 -0700 (PDT)
Received: by iwn3 with SMTP id 3so881023iwn.31 for <>; Wed, 15 Sep 2010 22:28:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OgtvMw6/QsHwYGZexmiJrZe0XU8NYV1QeguHoPOkiz4=; b=BNgCiTh0pR/8RPDalm5y/rtE1uXUdUIJlS7IlCBNvZdXsrojfAEzpPMtuhmy3FncyZ YJkI4fXX9TUW41GWPnBlRf+dXW1omcET46G4UkpM7l5Xk/a/+S3RW/ywugLO/yZQIY7E 5K5FHb2b0uAEvmWLlzX0Y9OcUkzrbbuX2siME=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qtDagRkpmrP8rCj2/sobl++01V+gltvO/JgcDUcTnBPSqT85lRq57t/SUcu8jJL8PI Yxfpi8DXhuAvn3VAnc7US7dBXo2l8ntvlvd6hDY0EjxEBdZfnzXH+42IrDhwhkAjqmUw FwjHkgFpqoBLpOr51t3vqjpf7ylaJG2AYEDdI=
MIME-Version: 1.0
Received: by with SMTP id cg6mr2737840ibb.197.1284614896720; Wed, 15 Sep 2010 22:28:16 -0700 (PDT)
Received: by with HTTP; Wed, 15 Sep 2010 22:28:16 -0700 (PDT)
In-Reply-To: <>
References: <ActAsz/cDiAopKTASBWkx2ZFdKuoeA==> <>
Date: Thu, 16 Sep 2010 01:28:16 -0400
Message-ID: <>
From: Anthony Bryan <>
To: Robert McMurray <>,
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [ftpext] Question about draft-bryan-ftp-hash-07
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Sep 2010 05:27:53 -0000

On Fri, Aug 20, 2010 at 6:01 PM, Robert McMurray <> wrote:
> With that in mind, I've been thinking through implementation scenarios in the wake of the denial-of-service discussion that took place before IETF 78. More specifically, I've thinking about a scenario where the maximum file size could be configured at the server, so HASH commands could be prevented from stealing too many server resources when larger files are involved. This is purely a server implementation detail that has nothing to do with the draft with the exception of considering which reply code to return.
> Looking at section "3.4. HASH Command Errors" in the draft it would seem that none of the 5yz errors that are listed would apply, but returning a 504 reply might seem to make sense in this scenario. If so, would it be worthwhile to add a statement like the following to the draft?
>   The server-PI SHOULD reply with a 504 reply if the HASH command is
>   used on a file that cannot be processed for policy reasons. (For
>   example, the file size exceeds the server's hashing policy.)
> Or would a 4yz reply be better since this is a configurable option at the server? Perhaps a 452 reply?

revisiting this, Mathias Berchtold is an implementer (ProFTPD module
mod_digest, ) of
the alternate non-standard commands (XCRC, XMD5, XSHA1, SHA256) that
HASH is trying to standardize.

mod_digest uses 550 reply code for the case that Robert mentioned of a
file not being allowed to be hashed because of a policy.

"The DigestMaxSize directive configures the maximum number of bytes a
single hash command is allowed to read from a file. If the number of
bytes to be read from the file is greater than the configured limit
the server will return an error. If no DigestMaxSize directive is
configured, then there is no limit. It is stronly recommended to set
an upper limit."

R_550, "%s: Length (%zu) greater than " CONFIG_DIGEST_MAXSIZE " (%zu)
config value", cmd->arg, lLength, lMaxSize);

Mathias, any suggestions as an implementer?

we use 550 already for file not found.

      550 Requested action not taken.
          File unavailable (e.g., file not found, no access).

we don't seem to have a specific reply code that fits this case currently.
should we mint a new reply code (55z since it's permanent & deals with
file system) or use another existing code that isn't an exact fit?

(( Anthony Bryan ... Metalink [ ]
  )) Easier, More Reliable, Self Healing Downloads