[Top] [All Lists]

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

2014-03-07 03:18:02

On 07/03/2014 09:02, Tony Finch wrote:
Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:

Users will complain if they have chosen to reject, and we quarantine.
Isn't this a matter of setting expectations? The options are essentially
reject-or-quarantine, reject-or-discard, and reject-or-bounce. I admit
that it is hard to write a rubric explaining what "reject" means and why
it is not always possible :-)

Yes. The question is, is it simpler from the users' PoV to have two options 'quarantine or accept', or three options, 'quarantine, accept or reject-or-quarantine'?

If the 'reject-or-quarantine' will reject 75% of the time and quarantine 25% of the time, it's probably worth it. If it rejects 5% of the time and quarantines 95% of the time, it's probably not worth it. I can guarantee that people will complain that our software is broken if it hardly ever rejects relevant messages.

We actually get very few requests for rejection at this level. (Sometimes we even have a hard time persuading people that rejecting messages because the recipient address is unknown is a good idea). Our users don't want to risk losing messages, so they seem to prefer quarantine to reject.

I can see that if we had already offered people 'reject-or-quarantine', and could currently only reject if the message was sent only to one recipient, then adding PRDR support would be worthwhile, but since we don't currently offer that option, I'm not feeling the pressure to add PRDR support and make it more complicated for users.

I suspect we may add PRDR 'support' in the server component (advertise and understand it, but don't use it - which is allowed, and trivial to do), and monitor other servers' support of it in the client component, to see if it's worth adding there.


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

ietf-smtp mailing list