[ietf-smtp] Reviving PRDR

[Дилян Палаузов <[e-mail]>]

Hello,

On Thu, 2019-01-10 at 16:07 -0500, John Levine wrote:
> In article <[e-mail]> you write:
> > On Thu, 10 Jan 2019 11:55:53 -0800, John Bucy said:
> > 
> > > The MSA could call ahead/cut-through, doesn't exim do that? That might also
> > > allow for the mua to throw an error ui at the user if they fat-fingered the
> > > recipient rather than getting a bounce back later.
> > 
> > No.
> > 
> > Consider this reply.  I'm in Comcast cable territory, which means that I can
> > only do outbound port 25 to Comcast/Xfinity servers.  So my only realistic
> > way to get this mail out is to 587 it to Google's submission servers.
> > 
> > Now how do I "call ahead" for the cc: that's going to John Levine?
> 
> The theory is that you submit the whole message to Google and it
> probes the recipients before it accepts the message, but now you have
> the added issue of how to report back that receipient A can handle it
> but recipient B cannot.

PRDR (per recipient delivery response)?  Just like LMTP-after-data-per-recipient acceptance/rejection, but for SMTP,
possibly adding extra DSN codes.  PRDR solves other also problems, like stating “the first recipient accepts the
message, and the second recipient does not” (e.g. the second recipient has different spam rules).

Last time PRDR was discussed here was 2014.  Since 2013 it is integrated in Exim and back in March 2014 it was not
enabled by default.  Today in Exim enable_prdr still defaults to False in the documentation, but the
src/configure.default sets it to true.

Why isn’t enable_prdr in Exim enabled nowadays by default?

Regards
  Дилян

PRDR specification → http://www.eric-a-hall.com/specs/draft-hall-prdr-00.txt