tonix (Antonio Nati) wrote:
At 25/07/03 25/07/03 -0400, Jeff Hedlund wrote: 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.
I see. You decide what's good and what's bad, and you decide for all. And despite this package has a very large diffusion, you want to break any compatibility. Good.
No, _I_ don't decide what's good what's bad. The community has been deciding this.
During the requests and discussion of merging of aliases and forwards, no one argued about it then.
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.
There is nothing in the documentation that says the opposite as well.
There *is* though. When people who have worked with email systems, they have come to know that an alias delivers mail to a "local" user and processes the "local" user's settings.
Take a look at http://cr.yp.to/qmail/pictures/PIC.local2alias Note the ending: "Forward message to john" ^^^^^^^
That means, deliver to john but follow .qmail processing in ~john/.qmail.
It's what people have come to expect with an alias.
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 decide for yourself, not for the world.
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).
Whatever we need, we are able to do it with actual qmailadmin, without problems, don't worry for us.
Strange, I've the feeling you want to decide for us what we have to do.
No, I'm trying to understand why you are viewing it as a "feature", when everyone else saw it as a "bug".
And why would sales@ mail for name1@ not be subject to spam detection if the user so wanted?
If he wants SPAM checking, we use forward; if he does not want, we use aliases.
Out of curiosity, how would you create this forward and what would it do?
I'm just thinking to TMDA. With your way "alias" will ALWAYS declare to the world the real "user" under the alias. No way to chose! Wonderful!
What? That's not true. How is it declaring to the world anything about the real user under the alias?
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.
I've dozen of reasons, included the fact we're working since years with this configuration (without any Maildir problems), and we don't want to switch just because an opinion.
Unuseful to continue, I stop here.
Sorry I did bother you, time to start another branch, this qmailadmin is dead.
Hey- I'm not the only one deciding the fate of qmailadmin. It's a community driven project.
There was not one argument against having aliases process the end-user's qmail file, in fact, you are the only one who is arguing for it.
Is there anyone else using aliases in this manner, please speak up!
I'm not meaning to come off as attacking you. This type of discussion is good for the development of qmailadmin. I am trying to show you why it was removed and why it was viewed as a bug.
Does anyone else have any comments?
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
