[Design] [Proposal] Decoupling In/Outbound mail accounts

[Alec Flett]

I think we could decouple this stuff pretty easily... its done this way 
in the Thunderbird backend, though the UI was only recently exposed in 
1.5 - there is a concept of an "Identity", (similar to a "contact" as we 
define it, but more mail-specific) and "Account" and an "Incoming 
Server" (or "Inbox")

The basic idea is that an Account consists of one Incoming Server, and 
one or more Identities. The "Account" is just a container, and has very 
few attributes of its own.

Account
    +---IncomingServer
    +---Identity
        Identity
        etc...

 Further, an Identity could stand alone without an account.. If an 
account is associated with an identity (think bidi-references) then the 
mail composer library would use the data in the account/incoming server 
to determine things like what "Sent" folder to use, etc.

Reply-To is an attribute of the identity, not the Incoming Server. So to 
answer Morgen's question, I think that rather than think of the Reply-To 
as somehow connected to the account on the IMAP/POP server, think of it 
as a detail of the Contact.

In our world, Reply-To is really an annotation of the contact by the 
mail code. that would be pretty easy:

class MailContactInfo(schema.Annotation):
    schema.kindInfo(annotates=pim.Contact)
    replyTo = schema.One(schema.Text)

Alec


Mimi Yin wrote:
> Is there a Reply-to field right now for Incoming mail? I think the 
> Reply-to value in the Outgoing mail account settings could override 
> whatever email address was entered for Incoming mail. In most cases, 
> it will probably be the same email address.
>
> This solution is just appealing because it requires the least amount 
> of change. See more below about the unified account approach.
>
> On Feb 8, 2006, at 4:38 PM, Morgen Sagen wrote:
>
>>
>> On Feb 8, 2006, at 4:16 PM, Mimi Yin wrote:
>>
>>> We want to allow people to easily send out invitations in 0.7 
>>> without having to:
>>> + fill out incoming mail account information, thereby
>>> + sending Chandler into the throes of trying to download your email 
>>> into the repository.
>>>
>>> Currently, if you fill out the SMTP account information, you have to 
>>> fill out Incoming mail account information as well (so that there's 
>>> a reply-to email address for outbound mail.)
>>>
>>> Here are a couple of proposals for how we might de-couple incoming 
>>> and outgoing mail accounts in 0.7:
>>>
>>> + Add a "Reply to:" field to the SMTP account form. Allow users to 
>>> send email by just filling out Outbound mail information without an 
>>> Incoming mail account. AND/OR
>>
>> At first this one appealed to me, but then what happens if you create 
>> an SMTP account (filling in a reply-to address), and then create an 
>> IMAP account (also filling in a reply-to address).  When you send 
>> mail, which reply-to does the mail framework use?  You could follow 
>> the rule that if the IMAP/POP account you're using to "send from" has 
>> a reply-to address filled in then use it, overriding what's in the 
>> SMTP account.
>>
>>> + Unify Inbound and Outbound mail account info into a single Mail 
>>> account. Users can optionally fill out the incoming mail server. AND/OR
>>> + Add a checkbox to the mail account form that is un-checked by 
>>> default: Sync automatically.
>>
>> Actually, unifying Inbound and Outbound into a single Mail account is 
>> rather appealing; the account edit dialog could have an account-type 
>> listbox with three choices: IMAP, POP, or  "Outbound only", and a 
>> single reply-to field for the whole "account".  The only downside is 
>> that two Inbound accounts couldn't share the same Outbound account, 
>> but that's probably not a big deal.   This also means the awkward 
>> "use as default 'from' account" radio button gets replaced by the 
>> more natural "use as default mail account".  So +1 to the 
>> unification, but I don't think we need the "sync automatically" 
>> checkbox if we have the 3-way account-type listbox I described 
>> (unless you include that checkbox in addition to the listbox).
>
> I think this approach is ultimately more usable, since people think 
> about email accounts as both Inbound and Outbound. In the future we 
> can have something that stores SMTP accounts so that you can reuse 
> them across multiple accounts, but for now, having users enter the 
> same info a few times is probably okay.
>
> Do you think we need an Outbound only? We could just make the Inbound 
> mail server info optional and force the user to Sync it manually. 
> Otherwise, I think the first approach is cleaner.
>
>>
>> ~morgen
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design