AW: Re: UI mock-up - Account Setup Rev.3

Claudio Luck claudio.luck at
Sun May 12 12:42:10 UTC 2019

On 11.05.19 13:46, opto at wrote:
> one of the 'fringe' cases not mentioned yet is when the mailserver sits behind an dynamic ip (e.g. hmailserver on a local Win PC). (This may happen quite often if TB users don't trust to store their imap mails in the cloud.)
> In that case (dynamic ip), it cannot send smtp because that would be automatically interpreted as spam by everybody.
> So there will be the imap server with one account setting, and outgoing the smtp server of the user at an internet provider with another account setting.
> Another note: in a situation described as above, we cannot assume that the password is identical, because of password rules created by smtp provider or mail server - they need not be identical.

Oh, and beware of side-effects of trying passwords out, this will
possibly end up with accounts being locked out (for some time) on the
SMTP and IMAP front (or the backing LDAP/Active Directory). The user is
then trapped in the setup process retrying passwords she is more and
more confident being the right ones, and still getting a nay from the UI.

This can escalate to the point that the user starts resetting the
password over some external channel (e.g. web-tool), and gets a
confirmation from there, but back to the wizard, the new copy-pasted
password, again, don't work (either because of synchronization lag, or
because the lockout is not lifted through password reset).

We know who is to blame, but this is reality in big corporations and
universities, and the thresholds are hard to get changed.

For the end-user instead, this threshold and mechanism is basically
invisible, which has led to many confused support calls in the past.

More information about the tb-planning mailing list