UBC_Webmail Accounts

Added by Amos Gouaux, last edited by Jason Shao on Dec 16, 2004  (view change)

Not sure where this could go, but just sticking in this stuff because I've already had to dig through e-mail to remember it before. Perhaps something to consider for 3.1....

George Lindholm would like the ability to set the Reply-To mail header. Paul Gazda is interested in the multiple account aspect since "we have a request to have different From addresses and signatures depending on which account a user is logged into." I, Amos Gouaux, am interested in something similar, using the terminology "roles" or "identities". Since we use a Cyrus server with a lot of shared folders, I'm thinking it'd be rather handy to be able to "tie" such a role to a folder, making that role the default when in that folder.

Anyway, here's some notes on a possible UBCWEBMAIL_ACCOUNTS table to support this stuff:

Column Description
USER_ID Obvious what this is for....
FULL_NAME In an address like "Amos Gouaux" <amos@utdallas.edu>, this field would be what's in between the double quotes above.
FROM_ADDR In the same example address above, this would be the portion in between the angle brackets. This could vary to something else, like <jasig-portal@utdallas.edu>. This would be used to set both the From: message header and the envelope sender (the real sender of the message.)
EMAIL_ADDR This would be USER_ID + @ + CURRENT_IMAP_SERVER. Perhaps the name of this field is too vague, but it represents the user's account. So for all my identities, for me this would always be <amos@inbox.utdallas.edu>. When FROM_ADDR was set to something other than <amos@DEFAULT_DOMAIN>, then this value should be used to set a X-Sender message header that would be added to the message.
REPLY_TO This would be used to add a Reply-To message header, if it is defined.
SIGNATURE This message signature we'd like associated with this identity.
ASSOC_FOLDER This would probably be of more benefit to environments with shared IMAP folders, but generally would be null. The idea is this: if this value is set, it would be set to the shared folder. Consequently, when this shared folder was open, this particular account would show up as the default in a pick list that appears where the sender's name is currently displayed when composing a message. Typically the default for this pick list would be the user's primary account (maybe we need a flag for that?), but when we were in this folder, this account would instead be the default.
An example: When I am in Shared_Folders.postmaster, the account I have for postmaster@utdallas.edu would be the default value in the sender pick list when I go to compose a message. So while I was in that folder, I have taken on the role of this account.

If there's only one row in this table for that user, then no sender pick list but, if there's more than one row, the sender pick list would be presented so the user could choose the sender to use when composing a message.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (2)

 

  1. Feb 08, 2005

    Aaron Hamid says:

    I think that the webmail channel needs an overhaul of the authentication and acc...

    I think that the webmail channel needs an overhaul of the authentication and account/profiles system. Currently there are several facilities of varying abstractions and application that overlap each other but do not provide a coherent and flexible framework.

    There are a couple of distinct stages involved:

    1) discovering or choosing (may require custom view) the correct "account", which includes an IMAP and SMTP server
    2) obtaining credentials and authenticating to IMAP and SMTP server, based on whatever form of authentication each server requires (may require custom view); obtaining and decorating javamail session and store objects as necessary
    3) optionally, possibly maintaining separate preferences per-account

    The pipeline I envision looks something like:

    instantiate <account discoverer>
discover accounts for (uPortal) user
if number of accounts is greater than 1
  if <account discoverer> provides custom view
    execute custom view to choose account
  else
    execute default view with drop down and submit button
  endif
else
  select the only account found
endif
lookup and instantiate authentication type for account
if <authentication type> provides custom login page
  execute custom <authentication type> login page to obtain opaque credentials
endif
call a method to ensure the authentication type has completed any authentication necessary

...

When obtaining a new Store or Session connection:

call methods on <authentication type> to provide or decorate Store or Session object.
decoration may involve supplying a custom Store class, or modifying the Session with an appropriate JavaMail Authenticator.
These JavaMail Authenticator implementations should be orthogonalized from core CWebmail codebase.
The <authentication type> and Authenticator need to arrange to provide and read, respectively, agreed upon parameters.
For instance if an Authenticator requires a username/password,
the <authentication type> should be responsible for converting whatever internal credential it has into username/password form.
That will allow JavaMail Authenticators to be independent and reusable.

    If anything, at least the concept of accounts should be designed from the start to be abstract and not database-dependent. Some of us have existing systems that provide this information and we cannot replicate everything in one-off uPortal-specific tables.

    1. Mar 08, 2005

      Amos Gouaux says:

      Yeah, one thing I've noticed is that if our test server is idle for a day or two...

      Yeah, one thing I've noticed is that if our test server is idle for a day or two, when I try to login, UBC_Webmail blows up. Not entirely sure yet, but I think it may be in the code that looks up the user's mail box location in LDAP. I think something isn't being re-instantiated properly, but haven't dug much further into that yet.