Re: [ietf-smtp] SMTP Retrying/Sending Strategy on 452 / 4.5.3
Hector Santos <hsantos@isdg.net> Sat, 16 February 2019 17:33 UTC
Return-Path: <hsantos@isdg.net>
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 4F289130D7A for <ietf-smtp@ietfa.amsl.com>; Sat, 16 Feb 2019 09:33:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=UaOo0FEq; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=QcLJXlEc
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 ew93QR2kiKK2 for <ietf-smtp@ietfa.amsl.com>; Sat, 16 Feb 2019 09:33:23 -0800 (PST)
Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 096C61200B3 for <ietf-smtp@ietf.org>; Sat, 16 Feb 2019 09:33:22 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4614; t=1550338399; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=1nawpmTucrgi3nN/6k2nON/WMIc=; b=UaOo0FEqPaMTG3iSANKizVY16XhgfFRQvR+ZjsLI9YG/gz9NjiywFhR5vlUoRM ASJMnWx8QouF80GRUeUxKG6OOmH3Nkgp7FZIWQOMyk9cESQzxV7EFwKJmwzcNxuh SzZvHv8W3knS26Ws2EA4oufd8MMIEkqj1drnlCtXpNIek=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for ietf-smtp@ietf.org; Sat, 16 Feb 2019 12:33:19 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 745318133.1.760; Sat, 16 Feb 2019 12:33:19 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4614; t=1550338111; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pS5pmt8 2Ck4YqJQ9u5M/lJpQBtgpxhBJPX2JJf0ok+E=; b=QcLJXlEcWLK6mVbqFEyXyun fgT+Pm0BPvOz8bkhvVObMTcuI5Ltj3SF2AwiNI712nILsmMBgs3XN47R71m5sQZC PlZ1tn0JOqjfOXxwKZIycyepMdd4Lcg5qQmUMwBReTeGDBvwlRVbp1Pmd1Cy4J3K 2I4/gNMNtP7+EDFkQL1E=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for ietf-smtp@ietf.org; Sat, 16 Feb 2019 12:28:31 -0500
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1293222268.9.326908; Sat, 16 Feb 2019 12:28:31 -0500
Message-ID: <5C684963.1040709@isdg.net>
Date: Sat, 16 Feb 2019 12:33:23 -0500
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: ietf-smtp@ietf.org
References: <20190213202732.D1239200E4847C@ary.qy> <49a6c862ffcbcf2090fa63d02c1ce569542cf6a0.camel@aegee.org>
In-Reply-To: <49a6c862ffcbcf2090fa63d02c1ce569542cf6a0.camel@aegee.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/dB71alUPRvz9hosWol0QgFAs2C0>
Subject: Re: [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: Sat, 16 Feb 2019 17:33:26 -0000
Dilyan, The SMTP-GREY extension fits with RFC5321, Section 4.5.4 "Retry Strategies." https://tools.ietf.org/html/rfc5321#section-4.5.4 Note the section 4.5.4.1 sending strategy MUST requirement for a delay and added considerations for more advanced strategies that can shorten the 30 minutes SHOULD: The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery. That is what the SMTP-GREY "retry hint" was intended to do, not get into a more complex client/server negotiated retry system where all sorts of factors are considered. The compliant SMTP client MUST delay the retry and the extension fits with the extended "sophisticated and variable strategies" consideration described above to adjust the retry interval. Beyond this, IMO, it would be a different document like a BCP or Information status, perhaps titled: "SMTP Outbound Mail Optimization Strategies" that will serve bulk mail senders in today's environment. It would apply in general for remote servers who have deployed greylisting methods for load and/or spam controls. As far as SMTP-GREY, maybe a (draft) clarification for the time-value can be appended to section 2.5 "Recommended Blocking Times:" ..... Using a time-value of zero for the reply hint may be used by the Greylisting Server in an attempt to convey to the compliant SMTP client, the server has no blocking time and the client may retry without delay or follow its normal retry schedule. Since a non-compliant SMTP client will always follow a normal retry schedule, it is recommended the Greylisting Server who wishes to reject the first attempt with little to no blocking time for the 2nd attempt to consider using a retry hint of one second for backward compatibility reasons. Using one second should effectively produce the same almost immediate retry the Greylisting server maybe looking for, while using zero seconds may not produce the desired effect of an immediate client retry and cause an undesired delay, i.e. the client could default to 30 minutes as suggested by RFC531. Thanks On 2/16/2019 9:25 AM, Дилян Палаузов wrote: > Hello Santos, > > your draft describes an existing server’s defering strategy and advices clients how to act, when this defering strategy > is in effect. One of the essential parts of your draft is writing down the idea (formalizing) for the smtp-clients to > reuse the IP address on retrying, when grey listing is in effect. Whether grey listing is in effect, does not depend on > a 250-GREYLIST or retry= information. > > I suggest you include in the draft how a client can recognize that greylisting deferring is in effect and, based on the > outcome, decide to use or not other IP addresses for subsequent/immediate retries. > > If retry=0 is (intentionaly) left undefined, then the draft shall state this, and probably suggest what clients shall do > on retry=0. (E.g. ignore). Keeping retry=0 this way, because anything else is not backward compatible with > implementations of a draft, does not necessary mean that there is a consensus. > > Your draft states: > If a SMTP server offers a "retry=time-delay" hint which results in a > wasted 2nd attempt and requires additional attempts, the SMTP client > MAY begin to ignore the server's "retry=time-delay" hint after the > 2nd wasted retry. The SMTP client implementation can decide what > limits to place on honoring "retry=time-delay" hints and wasted > attempts it provides. > > I suggested previously, and this was not tackled, that a retry is not wasted, if the remaining number of recipients has > decreased during the retry. > > Regards > Дилян > > On Wed, 2019-02-13 at 15:27 -0500, John Levine wrote: >> In article <12803.1550087591@turing-police.cc.vt.edu> you write: >>> On Wed, 13 Feb 2019 12:22:09 +0000, Дилян Палаузов said: >>> >>>> Is publishing 1024 distinct IPv6 addresses for MX on a domain a good idea >>> >>> Only if you're *really* sure that everybody who wants to talk to you supports >>> at least EDNS0 and doesn't block tcp/53 :) >> >> Let me simplify that answer: >> >> No, it is not. >> >> R's, >> John > > _______________________________________________ > ietf-smtp mailing list > ietf-smtp@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-smtp > -- HLS
- [ietf-smtp] SMTP Retrying/Sending Strategy on 452… Дилян Палаузов
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Paul Smith
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Richard Clayton
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Hector Santos
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Paul Smith
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Russ Allbery
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Hector Santos
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… valdis.kletnieks
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… valdis.kletnieks
- Re: [ietf-smtp] It's Dead, Jim John Levine
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Jeremy Harris
- Re: [ietf-smtp] It's Dead, Jim Paul Smith
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Дилян Палаузов
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Hector Santos
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… valdis.kletnieks
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… John Levine
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Mark Andrews
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Дилян Палаузов
- Re: [ietf-smtp] SMTP Retrying/Sending Strategy on… Hector Santos