On Mon, 2003-07-21 at 15:47, Serge Knystautas wrote: > Danny Angus wrote: > > Everytime someone turns it on they learn why they had to, because an M$ > > product doesn't comply with the RFC's, and we've provided the workaround as > > a service to our users, not because we condone M$'s transgression. > > In the real world we have to accept non-compliance by others, why not take > > the opportunity to name and shame them? > > I just can't get behind making a sysadmin's life difficult like this. > These problems are hard to diagnose, get dealt with during off-hours, > involve users getting very upset and having it happen numerous times > before the sysadmin realizes he needs to flip some non-compliance flag > in it's mail server. I just think this would be a way to kill James' > marketshare.
what about having 1 global option saying "support non standard features"? Enabling this would enable all derival from the standard, such as this one. This option would be mentionned in the README so that every sys admin would not be able to miss it at install time. If you want your users to miss it, but still want them to see that they enabled them, what about NOT defining a default value for that global option, and make james fail with a meaningful message stating this option has to be set. Then the person who installs james, even if he misses to set it at installation is obliged to go in the config, obliged to read the note saying that james support non standard features such as those, but that you don't like it, and forces the person who installs it to see that. Like that, everybody's happy. Comments? J. -- CoffeeBreaks - Jerome Lacoste [EMAIL PROTECTED] - http://www.CoffeeBreaks.org
signature.asc
Description: This is a digitally signed message part
