Improving mail accounts

[kilburn]

Quote:ok, smtpauth with a different user is possible but if you have some sort of business customers then you may understand that it can happen that they don't want to tell others their mail password or they don't want to create an account just for sending... so this is a second motivation for the password...

I'm sorry but I don't get it. All my users are "business customers". They don't need to tell anyone their passwords. The "different account for sending" thing is client-specific (look at how Thunderbird handles this). What I mean is that they only need "identities" (the ability to choose the from address), because they can send through the same smtp server (and user and pass). To clarify:

Code:

Identity (mail from): sales@customer.tld
Identity (mail from): john@customer.tld
Both sent from:
server: smtp.customer.tld
user: john@customer.tld
pass: whatever

Quote:forward vs alias - there are some slightly differences:

All this differences are just artificial restrictions you're imposing on these "forward" vs "alias" concept. Let's review them...

Quote:- forwardings are one to one-or-more, aliases are only another one to the same account.

They're stored exactly the same on postfix configuration, so this is obviously an artificial restriction made by you.

Quote:- aliases are handled more easily (just add some other names in your mail account) by the customer, you don't need a virtual-mail folder for the address etc etc.

Virtual mail folders are not created by the panel. They are created by the virtual delivery agent when delivering the first mail for this maildir. Therefore, no mail folder would be created for ANY user which hasn't ever received a mail (including "forwarding" accounts that don't store mails locally. The handling of both situations is exactly the same from the panel view...

Quote:- the autoresponder maybe implemented differently with aliases (no problem: all addresses are automatically responded) than with forwardings (the autoreply needs to do severall db queries to get the target address and see what message it has set - or forwarding addresses just are not responded at all...). - I see some advantages with this two possibilities. Even if postfix handles them the same way: with aliases the domain-internal address handling may be simplified.

Address translation and autoreplying are tightly coupled. Imagine we have these accounts:

Code:

user@customer.tld     | Store:     yes
                      | Forward:   no
                      | Autoreply: yes
alias@customer.tld    | Store:     no
                      | Forward:   user@customer.tld
                      | Autoreply: yes
forward@customer2.tld | Store:     no
                      | Forward:   user@customer.tld
                      | Autoreply: yes

Now, let's see what happens when these addresses receive a mail:

Code:

user@customer.tld     | Deliver to: /var/mail/virtual/customer.tld/user
                      | Redir to: user@arpl.customer.tld
alias@customer.tld    | Redir to: alias@arpl.customer.tld
                      | Redir to: user@customer.tld
                      | Deliver to: /var/mail/virtual/customer.tld/user
                      | Redir to: user@arpl.customer.tld
forward@customer2.tld | Redir to: forward@arpl.customer2.tld
                      | Redir to: user@customer.tld
                      | Deliver to: /var/mail/virtual/customer.tld/user
                      | Redir to: user@arpl.customer.tld

Redirections to "*@arpl.*" spawn an autoreply process, which then may use any info (mail headers, db connections, etc.). Our autoreply looks for the "autoreply" field corresponding to the destination address of the e-mail (the "redir to:" above without the arpl subdomain). Then it gets the text stored there and uses it as body for the response.

As you can see, there is no difference in how the alias and the forward are handled. Therefore, why should we artificially handle them as if they were different things?

Quote:- a forwarding address may have a password (also to change the target address) - an alias address does not need anything.

Forwardings/aliases are "customer account managed objects", just like ftp or db accounts, because we have limits on them, etc. Therefore, they must be created/removed through the control panel.

Now you may argue that aliases (as defined by you) shouldn't count as mailboxes, because they generate no new server load. Thus, any any mail user can create an arbitrary number of aliases through the webmail. This is not ok for two reasons:

1. (Technical) Creating an alias means editing postfix configuration. You know, backend call and all this
2. (Administrative) The owner/admin of each customer must be able to control which mails/aliases their users have. Letting users create aliases by themselves destroys this "power chain".

Finally, as the underlying system (postfix) handles aliases and forwards the same way, any attempt to simply "alias handling" will effectively increase the complexity of our software. To illustrate this, just tell me which of this options entails higher complexity:

1. Complex (but exactly the same) handling for both "aliases" and "forwards"
2. Complex handling for "forwards", somewhat simplified (different) handling for "aliases"

Cheers!