Ian Eiloart wrote:
>
> --On 6 October 2008 20:19:08 -0700 Claus Assmann <exim@???> wrote:
>
>> Why not add support for PRDR? Take a look at the (unfortunately
>> expired) internet draft from Eric A. Hall:
>
> This one?
> <http://home.claranet.de/xyzzy/home/test/draft-hall-prdr-00.txt>
>
>> SMTP Service Extension for Per-Recipient Data Responses (PRDR)
>
> It differs like this:
>
> With PRDR, the server can give a single response if all the responses would
> be the same. There's a slight efficiency there.
>
> When giving a full response, the format is like LMTP except that it starts
> with a "353" response, eg "353 content analysis has started".
>
> So, this is more like LMTP, but is a bit more efficient.
>
> Furthermore, PRDR requires strict adherence to timeout specifications,
Fat chance of that.
The latest smtp RFC timeout specs are not even real-world relevant, let
alone seen in common use. Add up the mandated times. quarter-speed
telex was faster than that.
> and
> requires use of pipelining, in order to reduce the chances of losing
> responses.
I don't see the connection there. Pipelining potentially saves time, but
it *adds* failure modes.
> That all seems like an improvement on both XEXDATA and XLMTP,
> and therefore worthwhile.
>
Only if you assume pipelining will be permitted (not on our boxes) and
timing will fit yet-another particular set of parameters.
Am I the Lone Ranger in wanting to tilt toward an implementation ten
years in use vs one not yet even dry?
If so, WHY so?
Bill
