Re: [RFC] send mails and identity

["M . Thielker" <balsa t-data com>]

On 2001.08.14 16:04 christophe barbé wrote:
> Defaults settings are not default user settings.

ACK

> But I believe that all ID settings should have a default value.
> And then I'm convinced that we should use a identity structure to save
> this
> default settings. This settings would not be displayed by the ID dialog
> box
> but in the preferences dialog box. (This answer to the original question
> of
> Riccardo).

ACK - so far

> We need to add a "Multi-Identity support" checkbox in the preferences
> DBox.
> This box should be unchecked in 1.2 and this feature considered incomplete
> in 1.2.
> The main reason to disable it by default in 1.2 is that the duplicated
> mails in this mailing list are caused by this feature. This is an
> indication that we need to work it a little more.

How does that cause duplicates?

> Evidently when unchecked, all GUI references to ID should be hidden. This
> is why default settings need to be in the preferences DBox. 
> 
> To get a full-featured multi-ID support, We need to add a dialog box to
> set
> custom rules to guess dynamically ID to use.
> In case of ambiguity, user will be asked.

ACK

> Setting the default SMTP server empty will (optionnaly) ensure that a ID
> has been choosen with the rules.

NAK!
It cannot be assumed, that a user who wants to be asked every time an
identitiy is to be chosen is willing to enter (and possibly change) the SMTP
server on ever identity record, in case his SMTP server changes.. Setting a
default should not rob the user of the choice to be prompted for
confirmation on a background action.

My suggestion: [x] Always confirm automgically chosen identity
               [x] Always confirm selected identity on send   [x] Exclude
explicit rules

and keep the default SMTP server as it is. Unovious side effects of existing
settings should be avoided at all cost. We cannot let function follow form
and refrain from GUI changes at the expense of usablity. In all of the
discussions here i see a pervasive hesitancy to change GUI aspects of Balsa.
Whether that is just because hardcoded gtk is not for everyone or some
people think prefs are something bad, I don't know.
What is being written here is a complex email client, supporting many
mailbox formats and aiming to support tons of options like filtering,
multiple identities, multiple servers and so on. You can't seriously believe
that this can be done with just a handful of prefs options!? We don't need
M$-bloat, but as simplitic an interface as we have now will be too simple
for the task at hand. Side effects, buried deeply in the docs or, even
worse, undocumented will only lead to confusion.

There must be a default SMTP server, and it must be in prefs.
There should be no side effects associated with changing from no identity
support to identity support or from one default identity to another
There should be an error message if the default SMTP server is left blank,
unless not built for SMTP
As a compile time option, builds for non-SMTP should not have SMTP server
entry fields.
A different SMTP server should be selectable for each identity. This should
have no side effects, either.


> Rules could be based on mailbox (in case of reply) and/or header fields.

ACK

> Rules will be used during compose window creation and rechecked when
> headers field are modified.

ACK

Looks good so far. I would add an option to learn associations. In my
particular case, the identity needed for a reply is _always_ determined by
the _sender_ (or from) header.
When "Always confirm selected identity on send" and "Exclude explicit rules"
are both set, the confirmation dialog would only pop up when I am mailing to
someone I have not written to before. So, if a checkbox "[x] Remember this
selection as a rule" is added to that dialog, Balsa could, at the user's
discretion, learn such associations.
Reasonable defaults for the mtach field would be the From or Sender field of
the original message in the case of replies, or the To: address on freshly
composed email.
This new rule should be offered for editing in the same dialog used to edit
manually entered rules, to insure consistency.

The sequence would be thus:
Click "Send"
Confirm Identity dialog pops up
Click "Remember..."
Add Rule dialog pops up, filled in with defaults.
Edit, then click OK

Clicking Cancel in any of these dialogs should cances the entire send
(bacuase that's intuitive) and return to the compose window with the message
intact.

Melanie