ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Per-Recipient Data Responses

2014-03-06 14:42:18
On 06/03/2014 20:27, Ned Freed wrote:
Yes, this is what I was really trying to say.  The functionality of PRDR
depends so critically on everyone else having it that it's basically impossible
to justify implementation without everybody else on board.  Think of it as the
IPv6 of SMTP extensions, if you like. :)
Except that isn't true. As I pointed out previously, there's substantial
benefit and limited downside to implementing a user filter option with "reject
at SMTP time if possible, otherwise discard" semantics. Given the existence of
that option, server side implementation of PRDR becomes a win, and given that
so does client side implementation.T
The problem is that we can't do that. Content filters aren't 100% reliable, so we won't just discard messages or we would have hell to pay from our customers. We either quarantine or reject. Users will complain if they have chosen to reject, and we quarantine. They won't understand the intricacies of why that is so, they'll just want it to work.

So, if we support PRDR we have to reject or send a bounce when the sender doesn't support it. That causes backscatter which isn't nice. Since we should be trying to cut down backscatter, I can't see that a standard which potentially causes more backscatter is a good idea. If everyone (or at least a large majority) supported PRDR, then it would be acceptable; when a minority support it, it's not worth it (IMHO).





-


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp