[ietf-smtp] SMTP Retrying/Sending Strategy on 452 / 4.5.3

Дилян Палаузов <dilyan.palauzov@aegee.org> Mon, 11 February 2019 08:15 UTC

Return-Path: <dilyan.palauzov@aegee.org>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038CF131023 for <ietf-smtp@ietfa.amsl.com>; Mon, 11 Feb 2019 00:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8-XJ-gXAc2T for <ietf-smtp@ietfa.amsl.com>; Mon, 11 Feb 2019 00:15:30 -0800 (PST)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E37128BCC for <ietf-smtp@ietf.org>; Mon, 11 Feb 2019 00:15:28 -0800 (PST)
Authentication-Results: mail.aegee.org/x1B8F80b029812; auth=pass (PLAIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1549872919; i=dkim+MSA-tls@aegee.org; r=y; bh=cQOVJr115kyfk2J3n6Hiw2VheToAjQnmtxo3WJ1w1Cc=; h=Subject:From:To:Date; b=DIxVmCnhp8mhTu+PJpFAUApxh6N06wDimFN+T+eV4vfezBQSckAgQCnbQlVaK5Ghj cIHrhgzDMuAGNDknvlbWK+28Sf5OvFgmF4YEdVbLqUyAEgt5Tg7YwiUr3H7MVF+vGc w9Y6y9sT6UBnij4O/yLz2GOSHKWSYMQn52hg97LYniEyctxrt+Fxc8ZHje1vdHrQqb eKbPIOJKhsQ+BiHYeQMZvbp3cq+oXcpYUxS9tVTDYNzW6nptiorX7BvV0Z7hSRV8Ve +KDheUE/9kj2OldfygZ9KVpGyRnfRKLR1jMW1uShzQjbmt8RiMM3IYDUeSYK6CKEY+ Wa2rZyyclgsDB3WGSe6g46jpC090eYSo71UaXxTOQcIv7mCfaYDTv0X07OuluSNndY RCZRyKF1SNpTN0jyojtxEGleEmdeniJv2HoKwF3vIZzz83vJmVgVPTG6RnaZH2esQZ 7UUVfh6ubv6BnBj6a2ymylFsgpPBOEmXZfnIMw8uealK238CbdyZNQXsZHkta4FY/O ozhyL4tCKnhbmD4ioXUFgGBQwgZP35pDj0A7QNiCABhLoemfnof69ImDTqBj7bOufp 3IAlz/XfKznWAd6E7HNTnh7mC2swcvfliyyIUAhtGOfBh9U2qEpV93uQE+EI86LYMf xC6iLqYwUKcDIYhpKovtOXwQ=
Authentication-Results: mail.aegee.org/x1B8F80b029812; dkim=none
Received: from Tylan (dslb-088-066-133-073.088.066.pools.vodafone-ip.de [88.66.133.73]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x1B8F80b029812 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <ietf-smtp@ietf.org>; Mon, 11 Feb 2019 08:15:08 GMT
Message-ID: <5299217143f3f6f906dc3b2e357e9a4741a9b17a.camel@aegee.org>
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
To: ietf-smtp@ietf.org
Date: Mon, 11 Feb 2019 08:15:07 +0000
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.31.91
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/76ynus8fmoFAq3vkMzRYZMHWtYs>
Subject: [ietf-smtp] SMTP Retrying/Sending Strategy on 452 / 4.5.3
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 08:15:32 -0000

Hello,

RFC3463 Enhanced Mail System Status Codes defines in 3.6 Mail Delivery Protocol Status:

  X.5.3   Too many recipients

     More recipients were specified for the message than could have
     been delivered by the protocol.  This error should normally
     result in the segmentation of the message into two, the
     remainder of the recipients to be delivered on a subsequent
     delivery attempt.  It is included in this list in the event
     that such segmentation is not possible.


RFC5321 Simple Mail Transfer Protocol says:

4.2.3.  Reply Codes in Numeric Order

  452  Requested action not taken: insufficient system storage


4.5.3.1.8.  Recipients Buffer

   The minimum total number of recipients that MUST be buffered is 100
   recipients.  Rejection of messages (for excessive recipients) with
   fewer than 100 RCPT commands is a violation of this specification.
   The general principle that relaying SMTP server MUST NOT, and
   delivery SMTP servers SHOULD NOT, perform validation tests on message
   header fields suggests that messages SHOULD NOT be rejected based on
   the total number of recipients shown in header fields.  A server that
   imposes a limit on the number of recipients MUST behave in an orderly
   fashion, such as rejecting additional addresses over its limit rather
   than silently discarding addresses previously accepted.  A client
   that needs to deliver a message containing over 100 RCPT commands
   SHOULD be prepared to transmit in 100-recipient "chunks" if the
   server declines to accept more than 100 recipients in a single
   message.



4.5.3.1.9.  Treatment When Limits Exceeded

  452 Too many recipients (see below)


4.5.4.  Retry Strategies
4.5.4.1.  Sending Strategy

  contains: … the retry interval SHOULD be at least 30 minutes…
  and says nothing about 452 or 4.5.3


Is the number 100 randomly choosen?  Obviously, a site can accept 120 RCPTs per iteration, and for the 121st RCPT reply
with “452 4.5.3 Retry immediately after DATA”.

Are clients supposed to retry immediately after receiving 452 4.5.3?

What is the difference between „452” and „451 4.5.3”?  
https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml says 4.5.3 can be combined
only with 451.

Does „452 Requested action not taken: insufficient system storage” mean in 30 minutes there might be more storage, as
opposed to 4.5.3?

What will happen, if a site has one (1) as a minimum total number of recipients that are buffered?

What is the sending strategy after the total number of recipient per MAIL FROM:<..>... DATA . is exceeded?

How are 452 and 451 4.5.3 supposed to be different than the retry=0 hint?

Regards
  Дилян