[Chandler-dev] Re: Decoupling "from" from "send as" in email, and related issues

[Brian Kirsch]

Hi Bryan,
See comments inline.


On Jan 30, 2007, at 2:59 PM, Bryan Stearns wrote:

> I took over this small-sounding bug from Reid:
>
> https://bugzilla.osafoundation.org/show_bug.cgi?id=7764
> Add From: field to Detail View
>
> The reporter didn't realize that "From:" (with the account-picker  
> popup) turned into "Send as", and that the rest of the  
> implementation of the byline mechanism hasn't been implemented yet.  
> While investigating what "the rest of the implementation" might be,  
> I ended up also taking these related bugs:
>
> https://bugzilla.osafoundation.org/show_bug.cgi?id=7430
> Decouple from/to from email
>
> https://bugzilla.osafoundation.org/show_bug.cgi?id=7424
> Implement "sent by/edited by" and "send via" widgets
>
> https://bugzilla.osafoundation.org/show_bug.cgi?id=7765
> Addressing fields should preserve non-email addresses
>
> https://bugzilla.osafoundation.org/show_bug.cgi?id=7701
> Left-align byline with Title and Location fields
>
> https://bugzilla.osafoundation.org/show_bug.cgi?id=7620
> Byline shouldn't be editable
>
> In IRC, Brian suggested he'd like to hear more about my strategy  
> for fixing this stuff, so here goes:
>
> First, bug 7430: "Decouple from/to from email". There are separate  
> issues here: First, "from".... the design calls for a  
> Communications stamp "From" field that's distinct from both the  
> "From" and "Reply-To" headers on the message. I'm intending to  
> rename the EmailStamp.fromAddress attribute to sendAsAddress; the  
> mail service layer will use this attribute to make the From: header  
> on the outgoing message. Once I've verified that nothing broke,  
> I'll add a new attribute, fromAddresses, that's a list of addresses  
> for the "From" field, and I'll add another X-Chandler-From header  
> to pass it between Chandlers in the message.

Ideally, we would refactor MailStamp to be a Generic  
CommunicationStamp that could have a Mail annotation or a pointer to  
a MailItem. That way we could preserve the separation of
Chandler types from traditional mail types. However, given the time  
to Preview refactoring the fromAddress to sendAsAddress would work.

I would like to hear more about the use of the X-Chandler-From  
header. Why would this be needed? I would have thought the Chandler  
"non-email address" from info would be contained in the
EIML records attached to the mail message. Since no other clients  
understand the X-Chandler-From I am not sure what the benefit is.


>
> As for decoupling "to", I think that just indicates that we may  
> need to be flexible as we translate the addressing fields between  
> layers (either between mail-service message and the the EmailStamp  
> addressing fields, or between the EmailStamp fields and the UI),  
> because we (re-)use one item for all communications in a  
> conversation: an item you send may be updated by an email you later  
> receive. (I need to study the spec more here...)

Can you talk more here about how the implementation of 'to' could be  
more flexible. What specifically would you change?
For Preview the 'to' would still contain email addresses although the  
number of email addresses can grow or shrink through a conversation.
I.e. the list of who is participating in an Edit / Update workflow  
(the to field) can change by adding or removing 'to' email addresses.

Also one thing that has not been mentioned is the cc and bcc. Do  
these fields need to be 'decoupled' as well?

Again I would like to hear your thoughts more on the term 'flexible'  
as it relates to an implementation. Perhaps, we should chat on IRC or  
Skype.


>
> Bug 7765 ("Addressing fields should preserve non-email addresses")  
> turns out to be more complex than it looks. Currently, our model  
> for an email address is an email address (eg, stuff, followed by  
> "@", followed by some definition of "a domain name" like foo.com),  
> and optionally a "full name". We sometimes try to parse these  
> things from a single string, and if we get rid of the requirement  
> for a well-formatted email address, we won't be as able to tell  
> what's "email address" and what's "full name". The strategy I want  
> to start with is: change EmailAddress's parsing code to treat a  
> string with no "@" as a valid email address with no "full  
> name" (this way, when we format it, it'll come out as it went in,  
> and round-tripping will work).
>

When you say come out as it went in I am a bit confused. If the  
emailAddress field does not contain a valid address then it won't go  
out cause the SMTP server will reject it.

However, you are correct that the only time a email address really  
needs to be valid is the moment before a send. We could refactor so  
that right before
calling the mail service to send the item the detail view checks  
validity via the  EmailAddress.isValidEmailAddress on each string  
token in the 'to' field (cc? bcc?).


The mail service as I mentioned on IRC is more flexible with the  
validity of mail addresses. Mail coming in from a POP or IMAP server
may contain an invalidly formated email address but we still need to  
capture that address to show to the user.

If one uses the EmailAddress.getEmailAddress method it contains the  
validation and me translation logic and is currently quite inflexible.

In the mail service I use:

# Do we already have a EmailAddress item for this email address
address = EmailAddress.findEmailAddress(view, addr)

#Nope manually create a new one bypassing validation logic and me
# address translation
if address is None:
         address = EmailAddress(itsView=view,
                                emailAddress=addr, fullName=name)





> Bug 7764 ("Add From: field to detail view") will be easy once the  
> underlying fromAddress/sendAsAddress attribute confusion is worked  
> out.
>
> Bug 7424 ("Implement 'sent by/edited by' and 'send via' widgets")  
> really means "finish the byline work" - most of the cases are  
> already implemented, but need work around visibility or labeling  
> changes.
>
> Bug 7701 ("Left-align byline..") and bug 7620 ("Byline shouldn't be  
> editable") are small detail-view-blocks cleanups.
>
> ...Bryan
>