Parsed headers support

[svanderbleek]

Would this be desired? It could be baked in by default or as an option to parse the headers string from Sendgrid using Mail::Header.new(email.headers). It's not hard to do it yourself if you want it, but does take some knowledge of the underlying tools, the Mail gem and it's api, to accomplish it.

[svanderbleek]

What I am doing currently to access a needed field for processing:

Mail::Header.new(email.send(:params)['headers'])['In-Reply-To']

[svanderbleek]

Only regular use case headers like Message-ID, In-Reply-To, References, Date could be exposed to go along with the API philosophy.

[calebhearth]

Generally we've used the reply-to address to determine what a message is "in reply to".

For example, discussion-1@griddler.com would be a comment on Discussion.find(1), whereas a more robust use case could be d1t2c6@griddler.com for Discussion.find(1).topic.find(2).comment.find(3) (please never write code that looks like that). You would write your EmailParser to understand the email address and route the comment accordingly.

Would something like that meet your need for the "In-Reply-To" header?

[svanderbleek]

The reason we aren't using the local part of the address is because we want end users to see a nice neat email address that they are replying to messages@example.com instead of 9e578169681f4f74b8e2b0419cf52141@example.com (we are using uuids for the robust use case), this fits nicely with sending out emails with Message-ID: <uuid@example.com> and getting back In-Reply-To: <uuid@example.com>.

[calebhearth]

Okay. I'd be fine with a pull request that exposed parsed headers for Email.

On Wed, Mar 6, 2013 at 2:21 PM, Sandy Vanderbleek notifications@github.com wrote:

The reason we aren't using the local part of the address is because we want end users to see a nice neat email address that they are replying to messages@example.com instead of 9e578169681f4f74b8e2b0419cf52141@example.com (we are using uuids for the robust use case), this fits nicely with sending out emails with Message-ID: <uuid@example.com> and getting back In-Reply-To: <uuid@example.com>.

Reply to this email directly or view it on GitHub: https://github.com/thoughtbot/griddler/issues/33#issuecomment-14532904

[svanderbleek]

Cool, I'll get on it.

[calebhearth]

One other point - You can have emails sent from messages@example.com but set the reply-to to be <messages@example.com or something more readable> 9e578169681f4f74b8e2b0419cf52141@example.com so that users probably never see the uuid emails.

[svanderbleek]

Good idea, but reply-to: <readable@example.com> uuid@example.com produced a to field of "<readable@example.com>" <uuid@example.com> in gmail for me. Tweaking it some more reply-to: Readable uuid@example.com gives "Readable" <uuid@example.com>. Looked at http://www.rfc-editor.org/rfc/rfc822.txt and not sure if there is a way to do what are thinking. Though my outbound formatting might be getting messed up since it keeps breaking up the reply-to field over multiple lines.

[calebhearth]

You may not be able to convince GMail to hide the address completely (likely for security reasons).

The displays you mentioned were only for actually composing the message, right? So users would see the more reasonable email address until actually responding. 

Well, you may be right. Still happy to look over a headers pull; just thought I'd try and save you some effort.

On Wed, Mar 6, 2013 at 5:19 PM, Sandy Vanderbleek notifications@github.com wrote:

Good idea, but reply-to: <readable@example.com> uuid@example.com produced a to field of "<readable@example.com>" <uuid@example.com> in gmail for me. Tweaking it some more reply-to: Readable uuid@example.com gives "Readable" <uuid@example.com>. Looked at http://www.rfc-editor.org/rfc/rfc822.txt and not sure if there is a way to do what are thinking. Though my outbound formatting might be getting messed up since it keeps breaking up the reply-to field over multiple lines.

Reply to this email directly or view it on GitHub: https://github.com/thoughtbot/griddler/issues/33#issuecomment-14539257

[calebhearth]

Will be resolved with #34