> There is no good reason to penalize the user because the vendor made a
> mistake.
If you penalise the user, then presumably the user will do one or more of:
(A) complain to the vendor of the broken product, (B) switch to a
non-broken product, or (C) complain to you. If you can prove (by
reference to the specs) that the product is broken, then hopefully that
will encourage the user to do A or B rather than to persist with C. I
claim that that all the above is useful.
If you don't penalise the user, then presumably the user will not have
much incentive to complain to the vendor of the broken product. Lack of
complaints is likely to lead to the product not getting fixed. I claim
that that is bad.
In my opinion, the "be liberal in what you accept and conservative in what
you send" robustness principle should be interpreted as a guide for what
to do when the specs are ambiguous. If the specs are not ambiguous, I
believe that refusing to talk to non-conforming implementations is
usually useful.
--apb (Alan Barrett)
--
* This is sent by the exim-users mailing list. To unsubscribe send a
mail with subject "unsubscribe" to exim-users-request@???
* Exim information can be found at http://www.exim.org/
