Improving mail accounts

[joximu]

Hi

I'd like to propose some improvements I realized during communication with customers...

Today (ispcp 1.0) it's like this:
- you either create a mail account (with optional forwarding) or a mail forwarding.

I also have a webmail (horde) where the customers can change password and enable/disable/edit the autoresponder (I can provide the changes in the passwd and vacation module sometime).

This brings some problems...
- forwarding all the mails prevent having an autoresponder managed by the customer itself (since no password is given).
- with an forwarding only address you cannot use the SMTP-Auth - because of the same reason (no password).

The only way: delete the forwarding address and add a real account (inkl. forwarding), but then you have to log into webmail from time to time to delete the messages.

Another thing:
the handling of real aliases (not exactly forwarding) is very practical here (can only be done with forwarding addresses).

So I wish :-):
when defining a mail address you should be able to (some may depend on each other):
- add a password
- enable/disable the use of Smtp Auth for this address (is a sender-address)
- enable/disable a storage of the mails
- enable/disable a forwarding
- enable/disable an autoresponder
- add a list of aliases (mails to an alias address just go into this account)
- maybe more (or less - maybe with aliases you dont' need the smtp-auth checkbox...), but maybe more when including spam and virusfilter into ispcp.

with this, you don't have to delete an address just to change from postbox to forwarding address.


... can be improved....

/Joxi

[kilburn]

I see most of your points, but fail on others.

1. The motivation of "add a password" is just that they can login through the webmail?
2. In my systems (and in ispcp as default), a user@domain.tld can set it's sender-address to anyuser@domain.tld, so there's no need for "smtp auth (is a sender address)".
3. I totally agree on the "do not store mails" switch
4. Which is the difference between a forwarded address and an alias address? AFAIK, postfix makes no distinctions among them.
5. Also totally agree on the enable/disable autoresponder for any address. By the way, this may create confusion (double replies when sending to aliased accounts where both the alias and user have autoreply).
6. (see 3)

[joximu]

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...

forward vs alias - there are some slightly differences:
- forwardings are one to one-or-more, aliases are only another one to the same account.
- 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.
- 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.
- a forwarding address may have a password (also to change the target address) - an alias address does not need anything.

... not a very clear report but some thoughts that come together... :-)

/J

[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!

[joximu]

Hi killburn
it's getting long... :-)

I don't say that the two functions forward and alias are handled differently by postfix - I only see that there may be a difference in th handling for the customer.
Maybe the difference is more clear if we'd enable the older .forward files - then a mail account owner can forward his mails to other addresses.

If an employee (e@company.com, on ispcp) has his mails forwarded to a foreign account (e@schrottmail.com) but needs to send mails with the company.com account and (because of spf) needs to use the ispcp server - then he'd need a mail address, with password and smtp-auth but without mailspace... :-)
This is maybe not a very usual example - but there are customers who are organized in a very special way...

Virtual mail folders are created by ispcp!
see ispcp-mbox-mngr - sub mbox_add_mta_file_data ...
I wondered since long time why all the forwarding addresses have full maildir folders... - they never get mails inside.

Your example with the forwarded mails to austoresponded mails dows not work (in ispcp you cannot create an autoresponder to forwarded-addresses only). The forwarding mechanism in the arpl-engine is deactivated/not finished since feb 2009 (it was included but now is deactivated). And if you make complex forwardings (e2 -> e1, e1 -> e0, e0 has autoresponder) then the arpl-engine cannot resolve this correctly because of complexibility...

I still see forwardings as a "mail user" related thing, aliases would be a domain-owner/manager thing. So aliases should not be managed by mail users but I (as a mail user only) should be able to configure what I need: forwarding y/n, storage y/n, smtp-auth y/n, password change, autoresponder y/n/change.

Or another point of view on this:
an address is something which belongs to a user - he can decide if he want's fill forwarding (which means redirect?) to one or more addresses (like the .forward mechanism) with or without local copy. etc etc
An alias address is like a second address for an existing account (if my name is often written false, then I'd prefer an alias).

Technically (for postfix-config) the aliases are one sort of the forwards, but they need only an entry in the aliases files - the forwarding configuration need to set different entries (in the aliases, in the virtual, in the transport, the smtp-user-db etc etc)