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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp