Hello John,
the problem with bounces is, that they can lead to blacklisting the server,
that generated them.
What I drafted, which has nothing to do with grey listing, is not necessary
non-standard and avoids the problem with backscatters. The “retry=” hint
mitigates the side effect of delayed arrival.
Strictly speaking the delivery for all recipients does not have to be delayed.
The server can deliver promptly the messages to all deserving recipients,
memorize the Message-Id and the per recipient response, and in subsequent
transactions communicate the status per recipient. The only side effect is
then the “Mail not delivered within four hours” status message returned to the
sender.
The proposals with separate responses per recipient after data (PRDR) are stuck
in a sitation, where there is hardly any software capable on deciding on
rejection per recipient. (vicious circle)
Regards
Дилян
On February 7, 2019 8:09:08 PM GMT+01:00, John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
In article <1BE49204-C741-4A2A-A3BD-1D70A0E6A876(_at_)aegee(_dot_)org> you
write:
imagine a mail with an empty Subject: for two recipients. The first
recipient does not want to receive
emails without subject, the second recipient has no problem with this.
This issue, separate rejections after DATA, has come up many many
times before. I've seen proposals to add new status codes after
the data with per-address reports, but they never went anywhere.
The only standard compliant way to accept some addresses and reject
others is to accept the message and send a bounce about the addresses
that didn't work. Trying to do that with greylisting could never work
very well because you cannot reliably tell when a later message is the
same one you greylisted before. In particular, they often come from
different IPs.
We realize that in the current cruddy mail environment it is fairly
likely
that the bounce address is a fake and a bounce will go back to soemone
who didn't send the message, but that's another issue we've been
looking
at without much progress.
R's,
John
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp