On Thu, Jan 10, 2019 at 3:44 PM Дилян Палаузов
<dilyan(_dot_)palauzov(_at_)aegee(_dot_)org>
wrote:
Hello,
On Thu, 2019-01-10 at 16:07 -0500, John Levine wrote:
In article
<13753(_dot_)1547150864(_at_)turing-police(_dot_)cc(_dot_)vt(_dot_)edu> 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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp