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(_dot_)1550087591(_at_)turing-police(_dot_)cc(_dot_)vt(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp