Create models based on the incoming mail signal

[alexlovelltroy]

django-mailbox provides a signal for new mail:
http://django-mailbox.readthedocs.org/en/latest/topics/signal.html
Use it to create introductions/comments/etc...

There is an ugly example of the decision-tree in oldcode/introductions/models.py and oldcode/introductions/tasks.py

I'd like something cleaner here if possible.

[alexlovelltroy]

I'll try to add some clarity around how this part should work.

If the mail comes from one of our registered users, we examine it to figure out if it is:

• an introduction directly which connects two or more other people
• an introduction forwarded to us by a user which connects two or more other people
• an introduction forwarded by a user from another person which connects our user with one or more other people
• a reply to an introduction or comment which was sent to a private email address

In each case, we need to find the actual text content of the message and create the appropriate object or objects that relate to the introduction. In the classic application, we create objects to represent:

• each contact in an introduction
• an introduction
• a comment applied to an introduction
• a comment applied to a contact

Parsing out the people on the to:/from:/cc:/Bcc: lines has been an issue before. I hope we can find something off the shelf to do it for us, but if not, we can bring the code over.

Also, parsing the actual text of the email is a major hurdle when there are long chains to deal with. I think we might be able to take advantage of some more advanced email processing libraries.

Some notes

• We use email aliases to differentiate between different groups. Some of the existing decision tree is based on the delivered-to: header which may be:
  • my@intros.to
  • my+shortcode@intros.to To be implemented later
  • groupname@intros.to To be implemented later
• Since users may authorize as many email addresses as they like, we need to make the code that checks for a registered user more modular than a single SQL lookup.
• Dealing with each user's contacts should be independent. If two users are both introducing recipient@example.com and one knows him as Alex P. Keaton and the other knows him as Alex Proctor Keaton we need to be sure that the information doesn't leak.
• As designed, each introduction also has it's own email address in the form my+shortcode@intros.to for comments. Replies to that address from the user who owns the introduction are considered comments.
• There is also a short code for replies. Replies to that address from one of the contacts, should be considered replies to the introduction itself, and replies can be chained into conversations.

[djibon]

thanks for more details info, I'll take a look and try to see in oldcode codes

[djibon]

seems I can't find a decent email parsing, I'll try to copy the old code instead for this moment.

[djibon]

Hi,

I have some questions:

• how do we inject the shortcode from email? e.g google mail? since in the new code, there's a code that check the shortcode.
• "Since users may authorize as many email addresses as they like, we need to make the code that checks for a registered user more modular than a single SQL lookup." => can you give me more explanation?
• should we also create a Follow-up Table or just make it into a conversation?

[alexlovelltroy]

In the existing code, I believe the shortcode is stored in the Introduction model. That feels like the wrong place for it to me. Maybe we should have a table of shortcodes that relate back to other things. That way, we can do one shortcode for the intro itself and another one for the comments. And, if we want to change that later, we can do that.

In the existing code, the EmailProfile model collects EmailAddresses together as they relate to one person. The EmailProfile has an optional relation to the User table as well to say that all of these addresses belong to the same user.

There's code to verify an email address by sending them an email and asking them to click a link. So, when they bcc my@intros.to from any of their email addresses, we can associate all the intros with the right User.

I don't want to get into authorizing many users and managing that part of things yet, but we will need to.

Is that clearer?