Re: [ietf-smtp] Reviving PRDR

[John Bucy <[e-mail]>]

On Thu, Jan 10, 2019 at 3:44 PM Дилян Палаузов <[e-mail]>
wrote:

> 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).
>
>
I would like to see PRDR happen but I don't think it's actually required in
this case; you know it's binary (or eai) at MAIL time so RCPT could fail
for that.