Re: [Ilohamail-devel] multiple identities

[Ryo C. <ry...@il...>]

On 1/30/2003, "Christian Horchert" <to...@we...> wrote:

>> For the MySQL backend, there's a file called "backend.MySQL.inc" that
>> handles a lot of basic operations.  I did this to make it easier to add
>> support for other databases.  With the file-based backend, there are no
>> common functions that can be used to retreive data.  So I was thinking 
>> of
>> creating a "backend.FS.inc" file that handles the basic functionality 
>> for
>> the file-based backend.
>
>But backend.MySQL.inc is not used by all other MySQL includes. Does it
>have a special reason that read_contacts.MySQL.inc doesn't utilize this
>include?

You're right, but that will change at some point.  I'll be changing the
contacts stuff to use backend.MySQL.inc in a similar fashion as the
calendar stuff in 0.8.

>>> How the options should be configurable? Only global and/or per user,
>>> with interface or only in the backend?
>>
>> It should be a combination.  If the admin configuration (in 
>> conf/conf.inc)
>> allows users to over ride, then there should be an interface for users 
>> to
>> enable/disable this on an individual basis.  If the admin disables
>> overrides, users shouldn't even know that it exists.
>
>I first though about the admin could handle this per user in the 
>backend, but it was a stupid idea.
>
>> I wonder how often people would need to change both though.  If you 
>> could
>> specify the from field, why also specify a reply-to?
>
>Not very often, sure. But if you spoof the senders address it can be 
>useful to have a different address which refers to another mailbox.

Hm...  I'll think about that.  I have seen webmail programs (can't
remember which) that lets users specify both the "from" and "reply-to"
fields.  It's useful, but also prone to abuse (of course, the header
contains tracable information, but that won't help until after the fact).

>>> $TRUST_USER_ADDRES could be extended
>>> 1) by one flag for each option and/or
>>> 2) by one flag to allow per-user configuration
>>>
>>> where 2) is only suitable for a MySQL backend.
>>> What do you think?
>>
>> Actually, I was thinking of a combination.  In conf/conf.inc we'd add a
>> directive like
>> $ALLOW_SENDER_OVERRIDE where the possible values are {"none", "from",
>> "replyto", "both}.  If this directive is set to anything other than
>> "none", users can be presented with an interface that will allow them 
>> to enable this feature for themselves.

Ah, right.  I see what you're saying...and you're right.  It doesn't make
sense to have both directives.  So I would probably prefer to use
$ALLOW_SENDER_OVERRIDE and replace $TRUST_UESR_ADDRESS.

>That makes sense.
>But how they linked all together? At the moment, $from and $reply_to 
>are set
>by the trigger $TRUST_USER_ADDRESS. This must be extented or completely
>rewritten.
>
>> My general philosophy is "give users the option of having it as well as
>> NOT having it".
>
>I fully agree with that any way.

Ryo