tonix (Antonio Nati) wrote:
At 25/07/03 25/07/03 -0400, Jesse Guardiani wrote:On Friday 25 July 2003 11:15, Jeff Hedlund wrote: > tonix (Antonio Nati) wrote: > > At 25/07/03 25/07/03 -0400, Jeff Hedlund wrote:
[...]
> > You already have an option, why cutting that possibility to other people
> > who want "true" alias and "true" forwards?
>
> I think your definition of a "true" alias is skewed.
Me too. Anyone trying to maintain "true" (in the old qmailadmin sense) aliases
on a 1000+ user system with non-staff domain administrators will agree.
Our customers usually don't understand how they work (because they do NOT work like an alias normally works on other systems), which only compounds the problem.
In addition, setting maxaliases to 0 didn't really prevent customers from
accidentally creating an alias. The 'modify alias' button allowed alias creation
even if the max number of aliases had been reached.
You've found a bug to correct :-) !
Actually, it's not a bug. The maxaliases will be going away since aliases are now merged with forwards.
Good riddance, I say!
qmailadmin and vpopmail are project used by a large number of people, so I think you cannot change common features just because your opinion is different.
If you want that current users continue to upgrade to future version, you must mantain an high level of compatibility with previous versions.
We are not speaking here about a bug, or an error, but a different way to see/use a feature.
I disagree. You are using the wrong feature, and it just happened to work up until this point due to a bug. The previous versions of qmailadmin had a bug that caused aliased accounts to not process the .qmail file. This bug was caused by writing a Maildir in the alias file.
So I appreciate and I'm willing to see new features, but I want the possibility to exclude these features if I don't like them (again, speaking about operative modes, not errors).
My users are used to work this way, and I like the possibility to chose between alias or forward.
Aliases are meant to be an alias of an account. There is nothing in the screen or documentation that says an alias is an alias of an account that skips processing.
That is the exact reason that aliases are no longer being written as /Maildir/. Even if we were to keep the concept of an alias, then we would write to the file as an address not a /Maildir/, because an alias needs to process the end users account settings (forwards, vacation, spam settings, etc).
You didn't respond to my earlier message of why you think it should be that if [EMAIL PROTECTED] wanted to forward their mail to a wireless device that they should not receive sales@ mail on that device? (because in your current setup, they would not).
And why would sales@ mail for name1@ not be subject to spam detection if the user so wanted?
According to an earlier e-mail, you're currently using aliases to bypass the processing due to vacation responses. That reason alone is not enough-- as I mentioned earlier, you can create a mailing list to achieve the same results AND the aliases are then used in their "true" form.
Jeff --
/\ /\ .. .. .. [EMAIL PROTECTED] / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com
