John Levine wrote in
<20220115180055(_dot_)E4C0634FF1B1(_at_)ary(_dot_)qy>:
|It appears that Steffen Nurpmeso <steffen(_at_)sdaoden(_dot_)eu> said:
|>I think the idea of a retry=[MIN:]SEC member in the deferral
|>response is interesting, even though i do not know how MTAs manage
|>their queues .. but likely they could adapt to this easily.
|
|This is not a new suggestion, and nobody I know has ever implemented it
|other than as small scale experiments. The point of greylisting is to
|test the retry logic that every real MTA already has, not to invent
|yet another hack on the client side.
I think that "Free at last! Free at last!" is still current, yes.
|MTAs run their own retry schedules and it would generally not be easy
|to have special schedules for specific messages.
Well like i said, i do not know. Every MTA needs to have
a per-cache-entry notion and likely a per-receiver one, too.
It should thus naturally be capable to skip over one or multiple
deliveries, if the retry= suggests that it is useless to try
earlier. Noone said it must try exactly after the "retry"
duration, only that it does not make sense to try earlier.
So if that would be implemented, why not?
Of course admins may then decide to greylist multiple times
nonetheless.
And it all does not help to be able to "exactly" identify
a message in order to perform real greylisting.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp